När det kommer till scrum-leverans förväntar sig folk vanligtvis en release-exekvering efter slutet av en sprint. Detta innebär direkt efter en lyckad demopresentation till kunden.
Men jag har alltid undrat hur detta kunde vara en sådan automatisk förväntan. Speciellt om du överväger nedanstående möjliga aktiviteter som måste hända före eller vid sidan av.
- Utveckla och slutföra alla berättelser inom sprinten. Vissa kanske blir klara tidigare, men för det mesta är berättelserna färdiga strax innan sprinten är slut. Kanske även efter demopresentationen, för att vara öppen här.
- Utför alla schemalagda tester över sprintinnehållet för att säkerställa att koden som ska släppas är produktionsklar.
- Kom ikapp med upptäckta buggar och fixa dem i tid innan släppet sker.
- Se till att distributionspipelinen är uppdaterad med det senaste innehållet och att själva pipelinen är tillförlitlig att köra.
- Kör pipelinen på alla relevanta miljöer för att få dem till det senaste tillståndet ur kod- och dataperspektiv.
- Förbered releasenotes och kommunicera med klienten om effekterna av releasen och exakt vad som kommer att förändras efteråt.
- Om det är relevant, synkronisera med andra parallella scrum-team för att säkerställa att det beroende innehållet kommer att släppas samtidigt. Ingenting bör saknas för att säkerställa att ditt releaseinnehåll kommer att fungera som förväntat.
- Utöver allt detta, gå igenom alla scrum-ceremonier. Inte bara relaterade till den aktuella sprinten utan även de som är inriktade på nästa sprint (t.ex. berättelseförfiningssessioner).
Tänk dig nu att sprinten har två veckor.
Släpp aktiviteter i sig själva tar tid och människor att slutföra. Men det kan inte ta för mycket. Strax efter sprintens sista dag kommer direkt dagen ett av nästa sprint, och cirkeln ska börja igen.
Ser förväntningarna på release efter varje sprint fortfarande så automatiska ut?
Innehållsförteckning
Släpp innehållsbearbetning
Om alla processer inom sprinten är automatiserade finns det en möjlighet att bara ”trycka i avtryckaren” och installera den senaste kodversionen i produktion i slutet av varje sprint. Problemet är att jag aldrig har upplevt ett så perfekt tillstånd av scrum-teamet.
Om det faktiskt är så i vissa småskaliga privata företag så avundas jag dem verkligen. Men verkligheten i företagsvärlden är att ett scrum-team inte kommer att uppnå den nivån av mognad. Tvärtom är releaseprocesser vanligtvis kopplade till tidskrävande aktiviteter som når de flesta av följande sprint, vilket påverkar sprinten ur innehålls- och alla mätningsperspektiv. Releasen är bara en stressig handling som ingen i laget är glad över att gå igenom.
Så jag var efter att ha upptäckt det näst bästa scenariot för att hantera releaser.
Slutsatsen var att göra varannan sprint till Release Sprint. Här är vad det betyder.
Separat kodversion för nästa utgåva
Det här handlar om att hantera separata grenar i GIT-förvaret. Det finns många sätt att närma sig samma problem, och alla kan vara framgångsrika. Men för syftet med den här artikeln kommer jag att hålla saker enkla för att visa tillvägagångssättet och dess inverkan.
För att påverka de pågående utvecklingsaktiviteterna så lågt som möjligt är det viktigt att separera innehållet för nästa release i en separat gren. Låt oss kalla det Release Branch. Med detta kommer följande att lösas:
- Utvecklingsteamet kan fortsätta i aktiviteter och smälta samman i huvudgrenens nya berättelser utan störningar.
- Det finns ingen risk att releaseinnehållet kommer att påverkas av oväntade kodändringar från scrum-teamet.
- Testaktiviteter kan utföras i ett isolerat utrymme. Här kommer endast ändringar som är nödvändiga för att lösa testningen att införas.
- Eftersom releasepipelinen endast kommer att distribuera innehållet från Release Branch i produktion, har vi en tydlig process och full kontroll över innehållet som ska släppas. Det kan inte hända att någon oväntad commit i Git-grenen skulle bryta redan testad kod.
Så håll bara innehållet i nästa release åt sidan och låt det avslutas till ett stabilt tillstånd, redo för release.
Tajma släppen så att de fungerar upprepade gånger
Jag gav upp ambitionen att göra releasen efter att varenda sprint var avklarad. Det var superklart att detta inte skulle ha någon chans att fungera. Åtminstone inte med sådana biverkningar som:
- påverka nästa sprintutvecklingsinnehåll,
- att inte kunna stabilisera utgivningsinnehållet,
- komma ikapp med alla nödvändiga testaktiviteter osv.
Så målet var att genomföra releasen i slutet av varannan sprint. Det skulle innebära följande:
- En release kommer alltid att innehålla berättelser från de två senaste redan avslutade spurterna. Eftersom releasen utförs inom den aktuella (aktiva sprinten) ingår inte detta sprintinnehåll i releasen ännu.
- Det finns en hel sprinttid för nödvändiga testaktiviteter och buggfixar att slutföras.
- Releaseägaren har tillräckligt med tid för att samla in releaserelevant information (testfall, releasenotes, etc.) med icke-release-sprinten. På så sätt kan de fungera i princip fristående och hålla resten av utvecklingsteamet igång med nya berättelser.
- I händelse av buggupptäckt kan releaseägaren snabbt ansluta till betongutvecklaren för att åtgärda problemet och återgå till det aktuella sprintinnehållet. Så det bör alltid finnas en viss procentuell tid tilldelad från teamets kapacitet för att stödja denna buggfixning. Hur mycket exakt kan upptäckas över tid.
Det är uppenbart att användarna inte kommer att få det senaste sprintinnehållet i den senaste utgåvan. Men med tiden kommer detta att bli irrelevant. De kommer att få två sprintar med innehåll med varje nästa släpp ändå, efter varje andra sprint.
Detta ser ut som en bra kompromiss mellan snabb leveranstillfredsställelse och att hänga med i scrumaktiviteterna utan betydande störningar.
Kör release-distributionen
När testning, buggfixning och pipelineberedskap har slutförts framgångsrikt är det en ganska enkel process att köra produktionspipelinen och slutföra releasen till produktion.
Eftersom det distribueras från en fristående gren kan detta i princip vara en obemärkt och osynlig aktivitet. Ingen behöver veta. Om så är fallet är det den bästa möjliga implementeringen av utgåvan.
En förutsättning för det är att ha skapat en gedigen automatiserad DevOps-pipeline. Används inte bara för att distribuera till produktionsmiljön utan också till alla andra lägre nivåer. Detta kan inkludera dev, sandbox, test, kvalitetssäkring, prestandamiljö, etc. Detta ska vara ett klick för att distribuera alla lösningar för varje enskild miljö.
Frisättningen ska inte vara en smärtpunkt eller stress. Eller en mardröm som alla fruktar och fortsätter att förbereda sig för den dagen i en vecka. Nej – i stället, om ingen märker detta någonsin, är detta det bästa tecknet på en framgångsrik release.
Slå tillbaka Release-grenen till utvecklingsgrenen
Release Branch innehåller nu en del speciellt innehåll som inte finns i den vanliga pågående utvecklingsgrenen. Det är relaterat till alla korrigeringar som implementerades under testperioden. Detta innehåll måste slås samman tillbaka till utvecklingsgrenen för att säkerställa att korrigeringarna kommer att finnas kvar även efter nästa utgåva.
Vid den tidpunkten fungerar den senaste Release Branch som en nödsituation redo att omdistribuera produktionskod. Om ett brådskande högprioriterat problem behöver lösas kort efter produktionsinstallationen kan den använda denna gren. Det är enkelt att ta den här koden och implementera fixen inuti. Detta är fortfarande den exakta kopian av den nuvarande produktionskoden utan något nytt outgiven innehåll.
Slutligen, när den nya testperioden börjar, kan den tidigare utgivningsgrenen tas bort och ersättas med en ny. Den nya skapas igen som en kopia från den nuvarande utvecklingsgrenen.
Upprätta regelbundna releaser
Och nu har vi det 😀—en solid process för att närma sig releasen. Det enda som saknas är att göra ett åtagande att hålla det regelbundet. I det här fallet efter varannan sprint.
Genom att hålla det regelbundet sätter vi faktiskt grunden för att göra det lättare att utföra, främst för att:
- Om släppet sker efter en inte alltför lång tid finns det inte så mycket nytt innehåll att installera till produktionen. Ökningen är liten och anses vara stabil.
- Nu betyder så mycket nytt innehåll inte överväldigande mycket testaktiviteter och skapande av testfall. Färre kommunikation, avtalssamtal och samarbete med intressenter om vad allt behöver valideras på nytt. De kommer också överens om att det inte är så länge sedan det senaste släppet. Så mindre vikt läggs på denna handling.
- Teamet kommer att vänja sig vid denna cykel; över tid kommer det att vara en naturlig del av laget.
- Som en bieffekt får utvecklings- och testmiljöer ofta data uppdaterade. Det behövs i alla fall för varje ny testcykel. Så det blir inte bara ännu en schemalagd aktivitet att göra. Snarare en handling som redan är en del av den etablerade processen. Denna förändring av perspektiv har så mycket inflytande på atmosfären i laget. Det skulle man inte tro.
Slutsats
Det här kapitlet avslutar mina tidigare inlägg om ämnet scrum-livscykeln. Det handlar också om vad som visade sig fungera i verkligheten.
Ofta börjar lag på det smidiga sättet och gör många saker fel. Sedan utvecklas de så småningom och börjar göra saker annorlunda. Den här serien kan hjälpa några av dem att göra denna förändring snabbare.
Inte heller är det här utgivningssättet det enda fungerande, och det är inte heller problemfritt. De kommer fortfarande att finnas, och teamen måste hantera dem. Förbättra sedan det som är möjligt och glöm det som inte är meningsfullt.
Men vad jag vet visade detta tillvägagångssätt, även om det var enkelt, att förändring är möjlig. Från kaotiska, oförutsägbara spurter till mer stabil leverans med regelbundna släpp som man kan lita på och planera med. Och det kräver ingen speciell, mycket komplicerad metodik – bara enkla regler och vilja att följa planen.