Utgivelser og utgivelsesstyring er en viktig del av arbeidet vårt. Å lansere riktig produkt til kundene vil gjøre dem fornøyde. Å gjennomføre en smidig utgivelse vil gjøre oss som er involvert i utgivelsen, fornøyde.
Hvordan kan vi oppnå en smidig utgivelse?
Etter å ha deltatt i et stort antall slike prosesser kan jeg si at det finnes noen viktige punkter som kan bidra til en vellykket utgivelsesstyring.
La meg fortelle deg hva de er.
En vellykket utgivelse starter under utviklingen.
Identifisering av testtilfeller
God utgivelsesstyring starter lenge før utgivelsesdagen, fra det tidspunktet funksjonen som skal lanseres, er i utviklingsfasen. I denne perioden må funksjonen godkjennes av QA. Det betyr at vi må teste alle mulige scenarioer vi kan tenke oss, som er relevante for den aktuelle funksjonen, for å validere at funksjonen fungerer i henhold til kravene. Noen av disse scenarioene vil bli testet med automatiserte tester, mens det for andre enten er for vanskelig eller ikke verdt innsatsen å lage automatisering.
Når vi identifiserer hvilken type testing vi må utføre for den aktuelle funksjonen, bør vi ta hensyn til følgende: Første gang denne funksjonen settes i produksjon, må vi teste den grundig. Vi må forsikre oss om at kundene ikke oppdager kritiske problemer. Vi må validere kravene. Og vi må sikre at funksjonen har god ytelse.
Forsinkelser og problemer under testingen kan få stor innvirkning på tidsplanene når man forbereder programvareutgivelser. Ved å innarbeide effektive metoder for utgivelsesstyring blir det enklere å sikre at testing og utrulling forblir pålitelige og forutsigbare.
Men når funksjonen først er satt i produksjon, trenger vi ikke å teste den like grundig ved hver fremtidige utgivelse av den samme kodebasen, med mindre det kreves oppdateringer for den. Funksjonens oppførsel vil bare endres dersom den underliggende koden er endret, eller dersom det har skjedd en ekstern endring i noen av avhengighetene den bruker. Resten av tiden vil det være tilstrekkelig med en enkel funksjonstest, der en slik test selvsagt inkluderer de viktigste testtilfellene.
Når det er sagt, bør du sørge for å vurdere følgende mens funksjonen er under utvikling: hvor mange testtilfeller du trenger å teste; hvor mye tid du har tilgjengelig til testing; hvilke av testtilfellene som er kritiske; hvilke av testtilfellene du vil kjøre ved hver utgivelse.
På denne måten kan du identifisere hvilke testtilfeller du skal automatisere. Fokuser på å dekke minst den kritiske funksjonaliteten med automatisering. For resten av testene bør du opprette skriftlige testtilfeller, enten i systemet for prosjektoppfølging (for eksempel Jira) eller i teststyringsverktøyet du bruker. På denne måten vil de ikke bli borte eller glemt, og de kan kjøres når en utgivelse krever det.
Have an account? Log In
Kjøre testene i CI
Når du har de automatiserte testene på plass, bør du begynne å kjøre dem gjennom CI i utviklingsmiljøene med jevne mellomrom. Etter hvert som andre funksjoner utvikles før utgivelsen finner sted, er det lurt å forsikre seg om at funksjonen du ønsker å lansere, fortsatt fungerer som den skal, spesielt hvis du allerede har godkjent den under sprinter. Hvis du for eksempel kjører testene for funksjonen du er interessert i, daglig, får du rask tilbakemelding om eventuelle rettelser som må gjøres i funksjonen på grunn av feil som skyldes andre endringer i systemet.
Tidlig oppdagelse av mulige feil i funksjonen som skal lanseres, gir god tid til å gjennomføre rettelsene og teste funksjonen på nytt, uten stresset det medfører å gjøre dette i den begrensede tiden du har i utgivelsesfasen. Jo større dekning av kravene du har i de automatiserte testene, desto større er sannsynligheten for at du bare vil finne et lite antall feil i utgivelsesfasen.
Preproduksjon er viktig og bør ha en innebygd buffer.
Tidsrammer
Utgivelsesfasen består vanligvis av en periode som er satt av til testing i et integrasjonsmiljø før produksjon, i tillegg til selve dagen eller perioden for produksjonsutgivelsen. Som tester involvert i utgivelsen sørger jeg alltid for å be om passende tidsluker for utgivelsen, slik at preproduksjonsfasen gir meg mulighet til å teste funksjonene som skal lanseres, på riktig måte.
Jeg beregner også alltid tid til en buffer, fordi jeg forventer at uforutsette problemer kan oppstå i prosessen for utgivelsesstyring, enten dette er feil i funksjonene som skal lanseres, eller eksterne faktorer. For å nevne én av disse faktorene: Preproduksjonsmiljøer er testmiljøer, og de har en tendens til å ikke være så pålitelige som de burde være. Mange ganger fungerer de enten svært sakte eller blir utilgjengelige en stund, akkurat når utgivelsestestingen pågår.
Det er alltid lurt å legge inn litt ekstra buffer, og selv om du ikke bruker denne ekstra tiden, går det helt fint. Du kan gi godkjenningen din før den avsatte testtiden er over, siden du kan bruke resten av tiden på å jobbe med noe annet. Det er verre å ikke ha en buffer og så trenge den, for da må du på en eller annen måte få plass til all testingen som trengs på kortere tid. Dette kan føre til at enkelte testtilfeller ikke blir kjørt, noe som igjen kan føre til at noen feil først blir oppdaget direkte i produksjon.
Omfang
Et annet viktig aspekt ved pre-produksjonsutgivelsen, sett fra mitt perspektiv, er å ha en dedikert koordinator for utgivelsesstyring. For meg betyr dette noen som tar seg av bestemte aspekter, hvor det første er å kontrollere omfanget av utgivelsen. Før testingen av en utgivelse starter, må testeren vite hva som skal testes. Dette koker ned til utgivelsens omfang.
Produktfolk, altså PO-ene eller BA-ene, forventer at bestemte funksjoner skal inn i utgivelsen, og dette avtales når utviklingen begynner. Koden som inngår i utgivelsen, dekker imidlertid ikke alltid nøyaktig det omfanget produktteamet forventer. Noen ganger glemmer folk å pushe kode til grenen som utgivelsesbygget opprettes fra. Eller verre: De kan pushe kode til denne grenen som ikke burde pushes. Dette kan være funksjoner som ennå ikke er ferdige og godkjent av QA, eller funksjoner som ikke inngår i det nåværende omfanget.
For å sikre at omfanget blir oppnådd, bør utgivelseskoordinatoren sammenligne det forventede omfanget med det faktiske. Det forventede omfanget bør komme fra produktfolkene og være tydelig angitt i en eller annen form for dokumentasjon (og kanskje i planen for kvalitetssikring). Det kan for eksempel hende at dere har en form for planleggingsdokumenter som viser prosjektmilepælene og hva som inngår i hver milepæl.
Når det gjelder det faktiske omfanget, bør det hentes ut en endringslogg fra VCS (versjonskontrollsystemet, for eksempel Git) som prosjektet bruker. Endringsloggen vil gjenspeile alle commitene som er gjort i utviklingsfasen på grenen som skal generere utgivelsesbygget. Forhåpentligvis vil hver commit, hvis dere arbeider på en organisert måte, ha en beskrivelse som peker til et Jira-element koden refererer til. På denne måten kan dere se hvilke Jira-elementer som har tilhørende kode på vei inn i utgivelsesbygget, og hvilke av disse elementene som ikke burde ha vært inkludert i dette bygget. Hvis dere oppdager at disse commitene gjelder nødvendige feilrettinger, er det selvfølgelig helt i orden. Det dere ikke ønsker, er at disse commitene representerer uferdig funksjonsarbeid eller arbeid knyttet til funksjoner som ikke skal inn i produksjon med den nåværende utgivelsen.
Når du setter deg inn i avanserte teknikker for utgivelsesstyring, vil du oppdage at integrering av prosessene dine med teststyringsløsninger utviklet for Jira kan gi en mer helhetlig og effektiv arbeidsflyt
Hver gang det oppdages et avvik mellom det forventede og det faktiske omfanget, bør koordinatoren for utgivelsesstyring samarbeide med produktteamet og lederne for utviklingsteamene for å finne ut hva som er den beste fremgangsmåten. Hvis commitene som viser seg å ikke inngå i omfanget, representerer uferdig funksjonsarbeid, er det best å fjerne dem. Dette skyldes at dere allerede er i pre-produksjonsfasen, og at dere ikke vil risikere å tillate at den gjenværende koden skrives og testes i all hast, bare for å få den med i utgivelsen. Det er risikabelt, ettersom dette hastverket kan føre til at testtilfeller blir glemt og ikke kjørt, og at kritiske feil slipper inn i produksjon. I dette tilfellet er det best å la resten av arbeidet med disse funksjonene bli gjort skikkelig til en fremtidig utgivelse.
Testingen
Når omfanget er klart, bør testfasen begynne. I testfasen før produksjon må du validere hele funksjonen som skal utgis på nytt. Du bør se for deg at dette er første gang du ser på den, og teste alle scenariene du testet i utviklingsfasen. Kjør de automatiserte testene du allerede har skrevet, men i pre-produksjonsmiljøet, og ikke glem de ikke-automatiserte scenariene. Utfør en full regresjonstest av denne funksjonen, ganske enkelt fordi det, når du er i denne fasen av utgivelsesstyringen og i pre-produksjonsmiljøet, sannsynligvis finnes andre team som må gjøre en utgivelse i samme tidsrom som deg. Dette er i praksis første gang alle avhengighetene samles, med produksjonsklar kode, i det samme miljøet. Og dette er i teorien konfigurasjonen som vil kjøre i produksjon fra og med utgivelsen.
Det gjelder med mindre det oppdages problemer under testingen og det er nødvendig med feilrettinger. Hvis det skjer, må du vurdere hva som må testes på nytt. Uansett om rettingen er i koden din eller i koden til en ekstern avhengighet, må du vurdere en ny testrunde hvis endringene påvirker funksjonen din på noen måte. Sørg for at du tester minst den kritiske funksjonaliteten til funksjonen på nytt.
Dette kan virke kjedelig, særlig hvis det oppstår mange feilrettinger i denne fasen. Du kan imidlertid ikke forutsi nøyaktig hvilken innvirkning rettingene kan ha på ulike deler av funksjonen din.
Små endringer kan føre til store bieffekter, så det er bedre å kjede seg, men være trygg på at den kritiske funksjonaliteten fortsatt fungerer som den skal, enn å angre på at du ikke testet grundig nok.
Og selvfølgelig: Hvis en feil som oppdages i denne testfasen, er ubetydelig, bør du ikke bry deg med å rette den i denne fasen. Igjen vil du ikke forhaste deg med implementering eller testing av en ellers velfungerende funksjon, slik at du risikerer å ødelegge den.
Under lanseringen er kommunikasjon og testing avgjørende.
Når funksjonaliteten er godkjent i forhåndsproduksjonsmiljøet, er den klar til å tas i bruk i produksjonsmiljøet.
Kommunikasjon
Når det gjelder lanseringen i produksjonsmiljøet, har koordinatoren for lanseringsstyring noen oppgaver som må gjennomføres. Først og fremst bør dato og klokkeslett for lanseringen fastsettes og kommuniseres til alle involverte parter i god tid. Jeg synes det er svært nyttig for lanseringsstyringen å legge inn dato og klokkeslett for lanseringen som et møte i deltakernes kalendere, slik at deltakerne kan organisere dagen sin. Dette er en oppgave koordinatoren kan utføre.
På lanseringsdagen bør koordinatoren minne alle involverte på tidsplanen for lanseringen. Ideelt sett bør kommunikasjonen foregå i en kanal som alle bruker, for eksempel Slack. En egen Slack-kanal der alle viktige forhold kommuniseres, sikrer at alle involverte har samme forståelse av hvilket trinn i lanseringen som er fullført og når, hva omfanget er, hvilke problemer som er avdekket, og hvem som kan hjelpe med disse problemene. Slik kommunikasjon sikrer at alle som trenger å kjenne til bestemte sider ved lanseringen, ser denne informasjonen, i motsetning til muntlig kommunikasjon (der personen kan være fraværende uten at den som kommuniserer informasjonen, oppdager det).
Koordinatoren for lanseringsstyring bør følge med på og kunngjøre milepælene for lanseringen i denne kanalen, for eksempel når lanseringen starter, og når lanseringen er godkjent. Alle involverte parter bør også kommunisere i denne kanalen når de utfører de tildelte trinnene sine, slik at alle andre er klar over statusen og fremdriften i lanseringen. Hvis en part som trengs på et tidspunkt under lanseringen, ikke er tilgjengelig, bør lanseringskoordinatoren ta kontakt med de rette personene for å sikre at alt går smidig.
More Articles
Testingen
Under lanseringen i produksjonsmiljøet bør den nye funksjonaliteten testes på nytt i sin helhet. Dette skyldes at selv om funksjonaliteten ble godkjent i andre testmiljøer, er ikke disse miljøene 100 % identiske med produksjonsmiljøene når det gjelder oppsett og ressurser.
For å forhindre uforutsett dårlig oppførsel fra funksjonaliteten som lanseres, er det viktig å kjøre alle tilgjengelige automatiserte tester, sammen med de ikke-automatiserte delene du har skrevet testtilfeller for. Godkjenn aldri en funksjonalitet i produksjonsmiljøet uten å ha testet den.
Det at du bare antar at funksjonaliteten fungerer i produksjonsmiljøet, betyr ikke at den faktisk gjør det.
Forsikre deg om at den fungerer – test den.
Etter lanseringen
Lanseringen er altså ferdig. Men å forsikre seg om at funksjonaliteten fungerer som den skal, krever mer arbeid enn bare å teste den i lanseringsfasen.
Når du er ferdig med dette, må du sørge for at de automatiserte testene kjøres i CI for produksjonsmiljøet. Dette vil fange opp uønsket oppførsel som skyldes eksterne endringer du ikke kjenner til.
Overvåk kontinuerlig funksjonalitetens ytelse for å sikre at belastningen i produksjonsmiljøet og kundenes bruk ikke fører til redusert ytelse. Sørg også for å følge med på eventuelle problemrapporter fra kundene dine. De kan avdekke områder som ikke fungerer som de skal, slik at du raskt kan planlegge en fremtidig oppdatering dersom det skulle være nødvendig.
Hvis lanseringen ikke gikk som forventet, må du sørge for å ha et evalueringsmøte etter lanseringen. Der kan du ta opp alle problemene som oppsto i styringsprosessen for lanseringen, og tildele oppgaver til de relevante personene, slik at fremtidige lanseringer går smidig og vellykket.
