Når det kommer til scrum levering, forventer folk normalt en udgivelsesudførelse efter afslutningen af en sprint. Dette betyder direkte efter en vellykket demopræsentation til kunden.
Men jeg har altid undret mig over, hvordan dette kunne være sådan en automatisk forventning. Især hvis du overvejer nedenstående mulige aktiviteter, der skal ske før eller ved siden af.
- Udvikle og færdiggøre alle historier inden for spurten. Nogle bliver måske afsluttet før, men det meste af tiden er historierne afsluttet lige før afslutningen af spurten. Måske endda efter demopræsentationen at være åben her.
- Udfør alle planlagte test over sprintindholdet for at sikre, at koden, der skal frigives, er produktionsklar.
- Indhent opdagede fejl og ret dem i tide, før udgivelsen sker.
- Sørg for, at implementeringspipelinen er opdateret med det seneste indhold, og at selve pipelinen er pålidelig at udføre.
- Kør pipelinen på alle relevante miljøer for at bringe dem i den nyeste tilstand fra kode- såvel som dataperspektiv.
- Forbered udgivelsesbemærkninger og kommuniker med klienten om virkningen af udgivelsen, og hvad der præcist vil ændre sig bagefter.
- Hvis det er relevant, synkroniser med andre parallelle scrum-teams for at sikre, at det afhængige indhold bliver frigivet samtidigt. Der bør ikke mangle noget for at sikre, at dit udgivelsesindhold fungerer som forventet.
- Oven i alt dette skal du gennemgå alle scrum-ceremonierne. Ikke kun relateret til den nuværende sprint, men også dem, der er målrettet til den næste sprint (f.eks. historieforfiningssessioner).
Forestil dig nu, at spurten har to uger.
Frigivelse af aktiviteter i sig selv tager tid og folk at fuldføre. Men det kan ikke tage for meget. Lige efter sprintens sidste dag kommer den første dag i næste spurt, og cirklen skal begynde igen.
Ser forventningen om udgivelse efter hver sprint stadig så automatisk ud?
Indholdsfortegnelse
Frigiv indholdsbehandling
Hvis alle processer inden for sprinten er automatiserede, er der mulighed for blot at “trække i aftrækkeren” og installere den seneste kodeversion i produktion ved slutningen af hver sprint. Problemet er, at jeg aldrig har oplevet en så perfekt tilstand af scrum-holdet.
Hvis det faktisk er tilfældet i nogle små private virksomheder, misunder jeg dem virkelig. Men virkeligheden i erhvervslivet er, at et scrum-team ikke opnår det niveau af modenhed. Tværtimod er udgivelsesprocesser normalt forbundet med tidskrævende aktiviteter, der når det meste af det følgende sprint, hvilket påvirker sprintet fra indholds- og alle metriske perspektiver. Udgivelsen er bare en stressende handling, som ingen på holdet er glade for at gå igennem.
Så jeg var efter at have opdaget det næstbedste scenarie for at håndtere udgivelser.
Konklusionen var at gøre hver anden sprint til Release Sprint. Her er hvad det betyder.
Separat kodeversion til næste udgivelse
Dette handler om at håndtere separate grene i GIT-lageret. Der er mange måder at gribe det samme problem an på, og de kan alle lykkes. Men med henblik på denne artikel vil jeg holde tingene enkle for at demonstrere tilgangen og dens virkning.
For at påvirke de igangværende udviklingsaktiviteter så lavt som muligt, er det vigtigt at adskille indholdet til den næste udgivelse i en separat gren. Lad os kalde det Release Branch. Hermed vil følgende blive løst:
- Udviklingsteamet kan fortsætte i aktiviteter og smelte sammen i hovedgrenens nye historier uden forstyrrelser.
- Der er ingen risiko for, at udgivelsesindholdet vil blive påvirket af uventede kodeændringer fra scrum-teamet.
- Testaktiviteter kan udføres i et isoleret rum. Her vil kun ændringer, der er nødvendige for at løse testen, blive indført.
- Da release-pipelinen kun vil implementere indholdet fra Release Branch i produktionen, har vi en klar proces og fuld kontrol over det indhold, der skal frigives. Det kan ikke ske, at en eller anden uventet commit i Git-grenen ville bryde allerede testet kode.
Så hold det næste udgivelsesindhold til side og lad det afslutte til en stabil tilstand, klar til udgivelse.
Tid udgivelserne, så de virker gentagne gange
Jeg opgav ambitionen om at lave udgivelsen efter hver eneste sprint var gennemført. Det var super klart, at dette ikke ville have nogen chance for at virke. I hvert fald ikke med sådanne bivirkninger som:
- påvirker det næste sprintudviklingsindhold,
- ude af stand til at stabilisere udgivelsesindholdet,
- indhente alle de nødvendige testaktiviteter osv.
Så målet var at udføre udgivelsen ved slutningen af hver anden sprint. Det ville betyde følgende:
- En udgivelse vil altid indeholde historier fra de sidste to allerede afsluttede spurter. Da udgivelsen udføres inden for det aktuelle (aktive sprint), er dette sprintindhold endnu ikke inkluderet i udgivelsen.
- Der er en hel en-sprint tid til nødvendige testaktiviteter og fejlrettelser, der skal fuldføres.
- Udgivelsesejeren har tid nok til at samle udgivelsesrelevante oplysninger (testcases, udgivelsesbemærkninger osv.) med ikke-udgivelsessprintet. På denne måde kan de stort set fungere selvstændigt og holde resten af udviklingsteamet i gang med nye historier.
- I tilfælde af fejlopdagelse kan Release-ejeren hurtigt oprette forbindelse til betonudvikleren for at løse problemet og vende tilbage til det aktuelle sprintindhold. Så der bør altid være afsat en vis procentdel tid fra holdets kapacitet til at understøtte denne fejlretning. Hvor meget præcist kan opdages over tid.
Det er klart, at brugerne ikke får det seneste sprintindhold i den seneste udgivelse. Men med tiden bliver dette irrelevant. De får alligevel to sprints med indhold med hver næste udgivelse, efter hver anden sprint.
Dette ligner et godt kompromis mellem hurtig leveringstilfredshed og at holde trit med scrum-aktiviteterne uden væsentlige forstyrrelser.
Udfør udgivelsesimplementeringen
Når test, fejlretning og pipeline-beredskabsaktiviteter er gennemført med succes, er det en ret ligetil proces at udføre produktionspipelinen og fuldføre udgivelsen til produktion.
Da det er implementeret fra en selvstændig gren, kan dette dybest set være en ubemærket og usynlig aktivitet. Ingen behøver at vide det. Hvis det er tilfældet, er det den bedst mulige implementering af udgivelsesimplementeringen.
En forudsætning for det er at have skabt en solid automatiseret DevOps-pipeline. Ikke kun bruges til at implementere til produktionsmiljøet, men også til alle andre lavere niveau-miljøer. Dette kan omfatte dev, sandbox, test, kvalitetssikring, ydeevnemiljø osv. Dette skal være et enkelt klik for at implementere alle løsninger til hvert enkelt miljø.
Frigivelsen bør ikke være et smertepunkt eller stress. Eller et mareridt, som alle frygter og bliver ved med at forberede sig til den dag i en uge. Nej – i stedet, hvis ingen lægger mærke til dette nogensinde, er dette det bedste tegn på en vellykket udgivelse.
Flet udgivelsesgrenen tilbage til udviklingsgrenen
Release Branch indeholder nu noget særligt indhold, som ikke findes i den almindelige løbende udviklingsgren. Det er relateret til alle de rettelser, der blev implementeret i testperioden. Dette indhold skal flettes tilbage til udviklingsgrenen for at sikre, at rettelserne forbliver der selv efter den næste udgivelse.
På det tidspunkt fungerer den seneste udgivelsesgren som en produktionskode, der er klar til at blive geninstalleret i nødstilfælde. Hvis et presserende højprioritet problem skal løses kort efter produktionsinstallation, kan det bruge denne gren. Det er nemt at tage denne kode og implementere rettelsen indeni. Dette er stadig den nøjagtige kopi af den aktuelle produktionskode uden nyt uudgivet indhold.
Endelig, når den nye testperiode starter, kan den tidligere udgivelsesgren slettes og erstattes af en ny. Den nye er igen oprettet som en kopi fra den nuværende udviklingsgren.
Etabler regelmæssige udgivelser
Og nu har vi det 😀—en solid proces til at nærme os udgivelsen. Det eneste, der mangler, er at forpligte sig til at holde det regelmæssigt. I dette tilfælde efter hver anden spurt.
Ved at holde det regelmæssigt sætter vi faktisk grunden for at gøre det nemmere at udføre, primært fordi:
- Hvis udgivelsen er efter ikke alt for lang tid, er der ikke så meget nyt indhold at installere til produktionen. Tilvæksten er lille og anses for at være stabil.
- Nu betyder så meget nyt indhold ikke overvældende mange testaktiviteter og oprettelse af testcases. Færre kommunikation, aftaleopkald og samarbejde med interessenter om, hvad alting skal genvalideres. De vil også blive enige om, at det ikke er så længe siden sidste udgivelse. Så der lægges mindre vægt på denne handling.
- Holdet vil vænne sig til denne cyklus; med tiden vil det være en naturlig del af teamet.
- Som en bivirkning bliver udviklings- og testmiljøer ofte opdateret med data. Det er i hvert fald nødvendigt for hver ny testcyklus. Så det bliver ikke bare endnu en planlagt aktivitet. Snarere en handling, der allerede er en del af den etablerede proces. Denne ændring af perspektiv har så stor indflydelse på holdets atmosfære. Det skulle man ikke tro.
Konklusion
Dette kapitel afslutter mine tidligere indlæg om emnet scrum livscyklus. Det handler også om, hvad der viste sig at virke i det virkelige liv.
Ofte starter teams på den agile måde og gør mange ting forkert. Så udvikler de sig til sidst og begynder at gøre tingene anderledes. Denne serie kunne hjælpe nogle af dem med at gøre denne ændring hurtigere.
Hverken denne udgivelsestilgang er den eneste brugbare, og den er heller ikke uden problemer. De vil stadig eksistere, og holdene skal håndtere dem. Forbedre derefter, hvad der er muligt, og glem det, der ikke har nogen mening.
Men efter hvad jeg ved, viste denne tilgang, selv om den var enkel, at forandring er mulig. Fra kaotiske, uforudsigelige spurter til mere stabil levering med regelmæssige udgivelser, som man kan stole på og planlægge med. Og det kræver ikke en speciel, meget kompliceret metode – kun simple regler og vilje til at følge planen.