Udgivelser og udgivelsesstyring er en vigtig del af vores arbejde. Når vi udgiver det rigtige produkt til kunderne, bliver de tilfredse. Når vi gennemfører en problemfri udgivelse, bliver vi, der er involveret i udgivelsen, tilfredse.
Hvordan kan vi opnå en problemfri udgivelse?
Efter at have deltaget i et stort antal af dem kan jeg sige, at der er nogle få vigtige punkter, som kan hjælpe med at opnå en vellykket udgivelsesstyring.
Lad mig fortælle dig, hvad de er.
En vellykket udgivelse begynder under udviklingen.
Identifikation af testtilfælde
God udgivelsesstyring begynder længe før selve udgivelsesdagen, fra det tidspunkt hvor den funktion, der skal udgives, er i udviklingsfasen. I denne periode skal funktionen godkendes af QA. Det betyder, at vi skal teste alle de mulige scenarier, vi kan komme i tanke om, som giver mening for den pågældende funktion, for at validere, at funktionen fungerer i henhold til kravene. Nogle af disse scenarier vil blive testet af automatiserede tests, mens det for andre enten er for vanskeligt eller ikke umagen værd at oprette automatisering.
Når vi identificerer den type test, vi skal udføre for den pågældende funktion, bør vi overveje følgende: Første gang denne funktion kommer i produktion, skal vi teste den fuldt ud. Vi skal sikre, at kunderne ikke finder kritiske problemer. Vi skal validere kravene. Og vi skal sikre, at funktionen fungerer effektivt.
Forsinkelser og problemer under test kan påvirke tidsplanerne alvorligt, når man forbereder softwareudgivelser. Implementering af effektive metoder til udgivelsesstyring hjælper med at sikre, at test og implementering forbliver pålidelige og forudsigelige.
Men når funktionen først er gået i drift, behøver vi, medmindre der kræves opdateringer til den, ikke teste den lige så grundigt ved hver fremtidig udgivelse af den samme kodebase. Funktionens adfærd vil kun ændre sig, hvis enten den underliggende kode er blevet ændret, eller hvis der er sket en ekstern ændring i nogle af de afhængigheder, den bruger. Resten af tiden vil en rimelighedstest af funktionen være tilstrækkelig, hvor rimelighed naturligvis omfatter de vigtigste testtilfælde.
Når det er sagt, skal du, mens funktionen er under udvikling, sørge for at vurdere: hvor mange testtilfælde du har brug for at teste; hvor meget tid du har til rådighed til test; hvilke af testtilfældene der er kritiske; hvilke af testtilfældene du vil køre ved hver udgivelse.
På denne måde kan du identificere, hvilke testtilfælde du vil automatisere. Fokuser på at få mindst den kritiske funktionalitet dækket af automatisering. For resten af testene bør du oprette skriftlige testtilfælde, enten i dit projekthåndteringssystem (f.eks. Jira) eller i det teststyringsværktøj, du bruger. På denne måde bliver de ikke væk eller glemt, og de kan køres, når en udgivelse kræver det.
Have an account? Log In
Kørsel af testene i CI
Når du har de automatiserede tests, bør du begynde at køre dem gennem CI i udviklingsmiljøerne med jævne mellemrum. Da andre funktioner udvikles, før udgivelsen finder sted, er det en god idé at sikre, at den funktion, du vil udgive, stadig fungerer korrekt, især hvis du allerede har godkendt den under sprintet. Hvis du for eksempel kører testene for den funktion, du er interesseret i, dagligt, får du hurtig tilbagemelding om eventuelle rettelser, der skal anvendes på funktionen, for fejl, der skyldes andre ændringer i systemet.
Tidlig registrering af potentielle fejl i den funktion, der skal udgives, giver god tid til at anvende rettelserne og teste funktionen igen uden stresset ved at skulle gøre det inden for den begrænsede tid, du har i udgivelsesfasen. Jo større dækning af kravene du har i dine automatiserede tests, desto større er sandsynligheden for, at du kun finder et lille antal fejl i udgivelsesfasen.
Førproduktion er vigtig og bør have en indbygget buffer.
Tidsrammer
Udgivelsesfasen består normalt af en periode, der er afsat til test i et integrationsmiljø før produktion, ud over selve produktionsudgivelsesdagen eller -perioden. Som tester, der er involveret i udgivelsen, sørger jeg altid for at bede om passende tidsintervaller til udgivelsen på en sådan måde, at førproduktionsfasen giver mig mulighed for at teste de funktioner, der skal udgives, ordentligt.
Jeg afsætter også altid tid til en buffer, fordi jeg forventer, at uforudsete problemer kan opstå i udgivelsesstyringsprocessen, uanset om det er fejl i de funktioner, der skal udgives, eller eksterne faktorer. For blot at nævne én af disse faktorer: Førproduktionsmiljøer er testmiljøer, og de er tilbøjelige til ikke at være så pålidelige, som de burde være. Mange gange fungerer de enten meget langsomt eller bliver utilgængelige i en periode, netop når udgivelsestesten finder sted.
Det er altid en god idé at have ekstra buffertid, og selv hvis du ikke bruger den ekstra tid, er det helt fint. Du kan give din godkendelse, før den afsatte testtid er udløbet, eftersom du kan bruge resten af tiden på at arbejde med noget andet. Det er værre ikke at have buffertid og få brug for den, for i så fald bliver du nødt til på en eller anden måde at få al den nødvendige testning til at passe ind i et kortere tidsrum. Det kan føre til, at nogle testtilfælde ikke bliver kørt, hvilket igen kan føre til, at nogle fejl først bliver opdaget direkte i produktionen.
Omfang
Et andet vigtigt aspekt ved en præproduktionsrelease er efter min mening at have en dedikeret koordinator for releasehåndtering. For mig betyder det en person, der tager sig af bestemte aspekter, hvor det første er at kontrollere releasens omfang. Før testeren begynder at teste en release, skal vedkommende vide, hvad der skal testes. Det handler i bund og grund om releasens omfang.
Produktfolk, også kaldet PO'er eller BA'er, forventer, at bestemte funktioner kommer med i releasen, og dette aftales, når udviklingen begynder. Den kode, der kommer med i releasen, dækker dog ikke altid præcis det omfang, som produktteamet forventer. Nogle gange glemmer folk at skubbe kode til den gren, som releasebygget oprettes fra. Eller endnu værre: De skubber kode til denne gren, som ikke burde skubbes. Det kan være funktioner, der endnu ikke er færdige og godkendt af QA, eller funktioner, der ikke er en del af det aktuelle omfang.
For at sikre, at omfanget bliver opnået, bør releasekoordinatoren sammenligne det forventede omfang med det faktiske. Det forventede omfang bør komme fra produktfolkene og være tydeligt beskrevet i en form for dokumenter (og måske i din kvalitetssikringsplan). Du har for eksempel måske en eller anden form for planlægningsdokumenter, som viser projektets milepæle, og hvad der er inkluderet i hver milepæl.
For det faktiske omfang bør der udtrækkes en ændringslog fra det VCS (Versionsstyringssystem, f.eks. Git), som projektet anvender. Ændringsloggen afspejler alle commit-meddelelser, der er foretaget under udviklingsfasen, til den gren, som genererer releasebygget. Hvis du arbejder organiseret, har hver commit-meddelelse forhåbentlig en beskrivelse, der henviser til et Jira-element, som koden vedrører. På den måde kan du se, hvilke Jira-elementer der har tilsvarende kode, som kommer med i releasebygget, og hvilke af disse elementer der ikke burde have været inkluderet i dette byggeri. Hvis du naturligvis finder ud af, at disse commit-meddelelser vedrører nødvendige fejlrettelser, er det helt i orden. Det, du ikke ønsker, er, at disse commit-meddelelser repræsenterer ufærdigt funktionsarbejde eller arbejde relateret til funktioner, der ikke bør komme i produktion med den aktuelle release.
Når du dykker ned i avancerede teknikker til releasehåndtering, vil du opdage, at integration af dine processer med testhåndteringsløsninger designet til Jira kan tilbyde en mere sammenhængende og effektiv arbejdsgang
Når der konstateres en uoverensstemmelse mellem det forventede og det faktiske omfang, bør releasekoordinatoren samarbejde med produktteamet og udviklingsteamets ledere for at identificere den bedste fremgangsmåde. Hvis de commit-meddelelser, der viser sig ikke at være en del af omfanget, repræsenterer ufærdigt funktionsarbejde, er det bedst at fjerne dem. Det skyldes, at du allerede er i præproduktionsfasen, og at du ikke vil risikere at tillade, at den resterende kode bliver skrevet og testet i hast, blot for at den kan nå med i releasen. Det er risikabelt, da denne hast kan føre til, at testtilfælde bliver glemt og ikke kørt, og at kritiske fejl slipper ud i produktionen. I dette tilfælde er det bedst at lade det resterende arbejde på disse funktioner blive udført ordentligt til en fremtidig release.
Testningen
Når omfanget er klart, bør testfasen begynde. Under præproduktionstestfasen skal du validere hele den funktion, du releaser, igen. Du bør forestille dig, at det er første gang, du ser på den, og teste alle de scenarier, du testede under udviklingsfasen. Kør de automatiserede tests, du allerede har skrevet, men i præproduktionsmiljøet, og glem ikke de ikke-automatiserede scenarier. Udfør en fuld regressionstest af denne funktion, ganske enkelt fordi der, når du er i denne releasehåndteringsfase og i præproduktionsmiljøet, sandsynligvis er andre teams, der skal release inden for samme tidsramme som dig. Det er grundlæggende første gang, at alle afhængigheder samles med produktionsklar kode i det samme miljø. Og dette er i teorien den konfiguration, der vil køre i produktionen fra og med releasen.
Det gælder naturligvis kun, medmindre der opdages problemer under testningen, og der kræves rettelser. Hvis det sker, skal du overveje, hvad der skal testes igen. Uanset om rettelsen er i din kode eller i koden fra en ekstern afhængighed, skal du overveje endnu en testrunde, hvis ændringerne påvirker din funktion på nogen måde. Sørg for som minimum at teste funktionens kritiske funktionalitet igen.
Det kan virke kedeligt, især hvis der opstår mange rettelser under denne fase. Du kan dog ikke forudsige præcist, hvilken indvirkning rettelserne kan have på forskellige dele af din funktion.
Små ændringer kan forårsage store følgevirkninger, så det er bedre at kede sig, men være sikker på, at den kritiske funktionalitet stadig fungerer korrekt, end at fortryde, at man ikke har testet tilstrækkeligt.
Og hvis en fejl, der opdages under denne testfase, naturligvis er mindre, skal du ikke besvære dig med at rette den under denne fase. Igen ønsker du ikke at forcere en implementering eller testning af en ellers perfekt fungerende funktion og dermed risikere at ødelægge den.
Under udgivelsen er kommunikation og testning afgørende.
Når funktionen er blevet godkendt i præproduktionsmiljøet, er den klar til at blive sendt til produktionsmiljøet.
Kommunikation
Når det kommer til udgivelsen i produktionsmiljøet, har udgivelseskoordinatoren nogle få opgaver, der skal udføres. Først og fremmest bør datoen og tidspunktet for udgivelsen fastsættes korrekt på forhånd og kommunikeres til alle involverede parter. Jeg oplever, at det er meget nyttigt for udgivelsesstyringen at have datoen og tidspunktet for udgivelsen oprettet som et møde i deltagernes kalendere, så deltagerne kan planlægge deres dag – en opgave, som koordinatoren kan udføre.
På dagen for udgivelsen bør koordinatoren minde alle involverede om tidsplanen for udgivelsen. Ideelt set bør kommunikationen foregå på en kanal, som alle bruger, f.eks. Slack. En dedikeret Slack-kanal, hvor alle vigtige aspekter kommunikeres, sikrer, at alle involverede har den samme forståelse af, hvilket trin i udgivelsen der er udført hvornår, hvad omfanget er, hvilke problemer der er blevet opdaget, og hvem der kan hjælpe med disse problemer. En sådan kommunikation sikrer, at en person, der har brug for at kende bestemte aspekter af udgivelsen, får disse oplysninger at se, i modsætning til mundtlig kommunikation (hvor personen måske er fraværende, uden at den, der kommunikerer oplysningerne, opdager, at personen mangler).
Udgivelseskoordinatoren bør holde styr på og annoncere milepælene for udgivelsen på denne kanal, f.eks. hvornår udgivelsen starter, og hvornår udgivelsen er blevet godkendt. Desuden bør alle involverede parter via denne kanal meddele, at de udfører deres tildelte trin, så alle andre er bekendt med status for og fremskridtet i udgivelsen. Hvis en part, der er nødvendig på et tidspunkt i udgivelsen, ikke er tilgængelig, bør udgivelseskoordinatoren kontakte de relevante personer for at sikre, at alt forløber problemfrit.
More Articles
Testningen
Under udgivelsen til produktionsmiljøet bør den nye funktion igen testes fuldstændigt. Det skyldes, at selv om funktionen er blevet godkendt i andre testmiljøer, er disse miljøer ikke 100 % identiske med produktionsmiljøerne med hensyn til opsætning og ressourcer.
For at forhindre uforudsete problemer med den udgivne funktion er det vigtigt at køre alle tilgængelige automatiserede test sammen med de ikke-automatiserede dele, som du har skrevet testcases til. Godkend aldrig en funktion i produktion uden at have testet den.
At gå ud fra, at funktionen virker i produktion, betyder ikke, at den faktisk gør det.
Sørg for, at den virker – test den.
Efter udgivelsen
Så er udgivelsen færdig. Men det kræver mere arbejde at sikre, at funktionen fungerer korrekt, end blot at teste den i udgivelsesfasen.
Når du er færdig med det, skal du sørge for, at dine automatiserede test kører i CI for produktionen. Dette vil opfange uønsket adfærd, der skyldes eksterne ændringer, som du ikke er bekendt med.
Overvåg løbende funktionens ydeevne for at sikre, at belastningen i produktionen og kundernes brug ikke forårsager en forringelse af ydeevnen. Sørg også for at holde øje med eventuelle problemrapporter fra dine kunder. De kan pege på områder, der ikke fungerer korrekt, så du hurtigt kan planlægge en fremtidig opdatering, hvis det er nødvendigt.
Hvis udgivelsen ikke forløb som forventet, skal du sørge for at afholde et retrospektivt møde efter udgivelsen. Her kan du gennemgå alle de problemer, der opstod i styringsprocessen for udgivelsen, og tildele de relevante personer opgaver, så enhver fremtidig udgivelse forløber problemfrit og succesfuldt.
