Utførelse av Scrum-utgivelsen – fra innholdsforberedelse til distribusjon

Når det kommer til scrumlevering, forventer folk vanligvis en utgivelsesutførelse etter slutten av en sprint. Dette betyr rett etter en vellykket demopresentasjon til klienten.

Men jeg har alltid lurt på hvordan dette kunne være en så automatisk forventning. Spesielt hvis du vurderer følgende mulige aktiviteter som må skje før eller ved siden av.

• Utvikle og fullfør alle historier innenfor sprinten. Noen vil kanskje bli fullført tidligere, men som oftest er historiene ferdige rett før slutten av spurten. Kanskje til og med etter demopresentasjonen, for å være åpen her.
• Utfør alle planlagte tester over sprintinnholdet for å sikre at koden som skal utgis er produksjonsklar.
• Få med deg oppdagede feil og fiks dem i tide før utgivelsen skjer.
• Sørg for at distribusjonspipelinen er oppdatert med det nyeste innholdet, og at selve pipelinen er pålitelig å utføre.
• Kjør rørledningen på alle relevante miljøer for å bringe dem inn i den nyeste tilstanden fra kode- og dataperspektiv.
• Forbered utgivelsesnotater og kommuniser med klienten virkningen av utgivelsen og hva som vil endre seg etterpå.
• Hvis det er relevant, synkroniser med andre parallelle scrum-team for å sikre at det avhengige innholdet blir utgitt samtidig. Ingenting bør mangle for å sikre at utgivelsesinnholdet ditt fungerer som forventet.
• På toppen av alt dette, gå gjennom alle scrum-seremoniene. Ikke bare relatert til gjeldende sprint, men også de som er målrettet for neste sprint (f.eks. historieforedlingsøkter).

Tenk deg nå at sprinten har to uker.

Slipp aktiviteter av seg selv tar tid og folk å fullføre. Men det kan ikke ta for mye. Like etter siste sprintdag kommer den første dagen i neste sprint, og sirkelen skal begynne på nytt.

Ser forventningen om utgivelse etter hver sprint fortsatt så automatisk ut?

Slipp innholdsbehandling

Hvis alle prosesser innenfor sprinten er automatiserte, er det en mulighet for å bare «trykke på avtrekkeren» og installere den nyeste kodeversjonen i produksjon på slutten av hver sprint. Problemet er at jeg aldri har opplevd en så perfekt tilstand av scrum-teamet.

Hvis det faktisk er slik i enkelte småskala private virksomheter, misunner jeg dem virkelig. Men realiteten i bedriftsverdenen er at et scrum-team ikke vil oppnå det nivået av modenhet. Tvert imot er utgivelsesprosesser vanligvis forbundet med tidkrevende aktiviteter som når mesteparten av den påfølgende spurten, og påvirker den spurten fra innholds- og alle metriske perspektiver. Utgivelsen er bare en stressende handling ingen på laget er glade for å gå gjennom.

Så jeg var etter å ha oppdaget det nest beste scenariet for å håndtere utgivelser.

Konklusjonen var å gjøre annenhver sprint til Release Sprint. Her er hva det betyr.

Separat kodeversjon for neste utgivelse

Dette handler om å håndtere separate grener i GIT-depotet. Det er mange måter å nærme seg det samme problemet på, og alle kan lykkes. Men for formålet med denne artikkelen skal jeg holde ting enkelt for å demonstrere tilnærmingen og dens virkning.

For å påvirke de pågående utviklingsaktivitetene så lavt som mulig, er det viktig å skille innholdet for neste utgivelse i en egen gren. La oss kalle det Release Branch. Med dette vil følgende løses:

• Utviklingsteamet kan fortsette i aktiviteter og smelte sammen i hovedgrenens nye historier uten forstyrrelser.
• Det er ingen risiko for at utgivelsesinnholdet vil bli påvirket av uventede kodeendringer fra scrum-teamet.
• Testaktiviteter kan utføres i et isolert rom. Her vil kun endringer som er nødvendige for å løse testingen bli innført.
• Siden utgivelsespipelinen bare vil distribuere innholdet fra utgivelsesgrenen til produksjon, har vi en klar prosess og full kontroll over innholdet som skal utgis. Det kan ikke skje at en eller annen uventet forpliktelse i Git-grenen vil bryte allerede testet kode.

Så bare hold neste utgivelsesinnhold til side og la det avsluttes til en stabil tilstand, klar for utgivelse.

Tid utgivelsene slik at de fungerer gjentatte ganger

Jeg ga opp ambisjonen om å gjøre utgivelsen etter hver eneste sprint var fullført. Det var veldig tydelig at dette ikke ville ha noen sjanse til å fungere. I hvert fall ikke med slike bivirkninger som:

• påvirke innholdet i neste sprintutvikling,
• være ute av stand til å stabilisere utgivelsesinnholdet,
• fange opp med alle nødvendige testaktiviteter osv.

Så målet var å gjennomføre utgivelsen ved slutten av annenhver sprint. Det vil innebære følgende:

• En utgivelse vil alltid inneholde historier fra de to siste allerede fullførte spurtene. Siden utgivelsen utføres innenfor gjeldende (aktiv sprint), er ikke dette sprintinnholdet inkludert i utgivelsen ennå.
• Det er en hel en-sprint tid for nødvendige testaktiviteter og feilrettinger som skal fullføres.
• Utgivelseseieren har nok tid til å samle utgivelsesrelevant informasjon (testsaker, utgivelsesnotater osv.) med sprinten uten utgivelse. På denne måten kan de operere i utgangspunktet frittstående og holde resten av utviklingsteamet i gang med nye historier.
• I tilfelle feil oppdages, kan utgivelseseieren raskt koble seg til betongutvikleren for å fikse problemet og gå tilbake til gjeldende sprintinnhold. Så det bør alltid være en viss prosentvis tid tildelt fra teamets kapasitet for å støtte denne feilrettingen. Hvor mye nøyaktig kan oppdages over tid.

Det er klart at brukerne ikke får det siste sprintinnholdet i den siste utgivelsen. Men over tid vil dette bli irrelevant. De vil uansett få to sprints med innhold med hver neste utgivelse, etter hver andre sprint.

Dette ser ut som et godt kompromiss mellom rask leveringstilfredshet og å holde tritt med scrum-aktivitetene uten vesentlige forstyrrelser.

Utfør utgivelsesimplementeringen

Når testing, feilretting og rørledningsberedskapsaktiviteter er fullført, er det en ganske enkel prosess å utføre produksjonsrørledningen og fullføre utgivelsen til produksjon.

Siden den er distribuert fra en frittstående gren, kan dette i utgangspunktet være en ubemerket og usynlig aktivitet. Ingen trenger å vite det. Hvis det er tilfelle, er det den best mulige implementeringen av utgivelsesdistribusjonen.

En forutsetning for det er å ha laget en solid automatisert DevOps-pipeline. Ikke bare brukt til å distribuere til produksjonsmiljøet, men også til alle andre miljøer på lavere nivå. Dette kan inkludere dev, sandbox, test, kvalitetssikring, ytelsesmiljø osv. Dette skal være ett klikk for å distribuere alle løsninger for hvert enkelt miljø.

Frigjøringen skal ikke være et smertepunkt eller stress. Eller et mareritt alle frykter og fortsetter å forberede seg på den dagen i en uke. Nei – i stedet, hvis ingen legger merke til dette i det hele tatt, er dette det beste tegnet på en vellykket utgivelse.

Slå sammen utgivelsesgrenen tilbake til utviklingsgrenen

Release Branch inneholder nå noe spesielt innhold som ikke finnes i den vanlige pågående utviklingsgrenen. Det er relatert til alle rettelsene som ble implementert i løpet av testperioden. Dette innholdet må slås sammen tilbake til utviklingsgrenen for å sikre at rettelsene vil forbli der selv etter neste utgivelse.

På det tidspunktet fungerer den siste utgivelsesgrenen som en nødproduksjonskode klar til å omdistribuere. Hvis et presserende høyt prioritert problem må løses kort tid etter produksjonsdistribusjon, kan den bruke denne grenen. Det er enkelt å ta denne koden og implementere rettelsen på innsiden. Dette er fortsatt den nøyaktige kopien av gjeldende produksjonskode uten noe nytt uutgitt innhold.

Til slutt, når den nye testperioden starter, kan den forrige utgivelsesgrenen slettes og erstattes med en ny. Den nye er igjen opprettet som en kopi fra den nåværende utviklingsgrenen.

Etabler regelmessige utgivelser

Og nå har vi det 😀—en solid prosess for å nærme oss utgivelsen. Det eneste som mangler er å forplikte seg til å holde det regelmessig. I dette tilfellet etter annenhver sprint.

Ved å holde det regelmessig setter vi faktisk grunnlaget for å gjøre det enklere å oppnå, hovedsakelig fordi:

• Hvis utgivelsen er etter ikke altfor lang tid, er det ikke så mye nytt innhold å installere til produksjon. Tilveksten er liten og anses som stabil.
• Nå betyr så mye nytt innhold ikke overveldende mye testaktiviteter og oppretting av testcase. Færre kommunikasjon, avtalesamtaler og samarbeid med interessenter om hva som må revalideres. De vil også være enige om at det ikke er så lenge siden siste utgivelse. Så det legges mindre vekt på denne handlingen.
• Teamet vil venne seg til denne syklusen; over tid vil det være en naturlig del av laget.
• Som en bieffekt oppdateres ofte data i utviklings- og testmiljøer. Det er uansett nødvendig for hver nye testsyklus. Så det blir ikke bare en annen planlagt aktivitet å gjøre. Snarere en handling som allerede er en del av den etablerte prosessen. Denne endringen av perspektiv har så stor innflytelse på atmosfæren i laget. Man skulle ikke tro det.

Konklusjon

Dette kapittelet avslutter mine tidligere innlegg om temaet scrum-livssyklusen. Dessuten handler det om hva som viste seg å fungere i det virkelige liv.

Ofte starter lag på den smidige måten og gjør mange ting feil. Så utvikler de seg etter hvert og begynner å gjøre ting annerledes. Denne serien kan hjelpe noen av dem til å gjøre denne endringen raskere.

Verken denne utgivelsestilnærmingen er den eneste gjennomførbare, og den er heller ikke uten problemer. De vil fortsatt eksistere, og lagene må håndtere dem. Forbedre så det som er mulig og glem det som ikke har noen mening.

Men etter det jeg vet, beviste denne tilnærmingen, selv om den var enkel, at endring er mulig. Fra kaotiske, uforutsigbare spurter til mer stabil levering med vanlige utgivelser som man kan stole på og planlegge med. Og det krever ingen spesiell, svært komplisert metodikk – bare enkle regler og vilje til å følge planen.