Inom agil utveckling, speciellt Scrum, är det vanligt att förvänta sig en lansering direkt efter avslutad sprint, oftast omedelbart efter en lyckad demo för kunden.
Jag har dock alltid ifrågasatt denna automatiska förväntan, särskilt när man betänker alla de aktiviteter som måste genomföras före och under lanseringen.
- Utveckling och färdigställande av alla user stories inom sprinten. Vissa stories kan vara klara tidigare, men oftast färdigställs de strax innan sprintens slut, kanske till och med efter demon.
- Genomförande av alla planerade tester för sprintens innehåll för att säkerställa att koden är redo för produktion.
- Identifiering och korrigering av eventuella fel (buggar) i tid innan lanseringen.
- Säkerställande av att distributionsprocessen (pipelinen) är uppdaterad med det senaste innehållet och att den är pålitlig.
- Körning av pipelinen i alla relevanta miljöer för att få dem till det senaste tillståndet, både vad gäller kod och data.
- Förberedelse av release notes och kommunikation med kunden om effekterna av lanseringen och exakt vad som kommer att förändras.
- Vid behov, samordning med andra parallella Scrum-team för att säkerställa att beroende innehåll lanseras samtidigt, så att allt fungerar som förväntat.
- Utöver allt detta, genomförande av alla Scrum-ceremonier, inte bara de som är relaterade till den aktuella sprinten, utan även de som är inriktade på nästa sprint (t.ex. refinement-möten).
Tänk dig nu att sprinten varar i två veckor.
Lanseringen i sig tar tid och kräver insatser, men den får inte ta för lång tid. Direkt efter sprintens sista dag börjar nästa sprint, och cykeln börjar om.
Verkar det fortfarande lika självklart med en lansering efter varje sprint?
Hantering av releaseinnehåll
Om alla processer inom sprinten är helt automatiserade, kan man tänka sig att bara ”trycka på knappen” och installera den senaste versionen i produktion i slutet av varje sprint. Problemet är att jag aldrig upplevt en sådan perfekt situation med ett Scrum-team.
Visst, kanske finns det i mindre, privata företag, och jag avundas dem i så fall. Men i de flesta företag är det ovanligt att ett Scrum-team når den mognadsnivån. Ofta är lanseringsprocessen kopplad till tidskrävande aktiviteter som sträcker sig över flera sprintar, vilket påverkar innehållet och mätresultaten. Lanseringen blir en stressig händelse som ingen i teamet ser fram emot.
Jag letade därför efter det näst bästa sättet att hantera lanseringar.
Slutsatsen blev att varannan sprint skulle vara en ”Release Sprint”. Här är vad det innebär.
Separat kodversion för nästa lansering
Detta handlar om att hantera separata grenar i Git. Det finns många sätt att lösa samma problem, och alla kan vara framgångsrika. Men för enkelhetens skull kommer jag att hålla det enkelt för att tydliggöra metoden och dess effekt.
För att minimera påverkan på pågående utvecklingsarbete är det viktigt att separera innehållet för nästa lansering i en egen gren, låt oss kalla den ”Release Branch”. Detta löser följande problem:
- Utvecklingsteamet kan fortsätta arbeta med nya user stories och smälta in dem i huvudgrenen utan störningar.
- Det finns ingen risk att lanseringsinnehållet påverkas av oväntade kodändringar från teamet.
- Testaktiviteter kan genomföras i ett isolerat utrymme, där endast ändringar för att lösa problem införs.
- Eftersom distributionsprocessen endast hämtar innehåll från ”Release Branch” har vi full kontroll över vad som lanseras. Det finns ingen risk att oväntade commits skulle bryta redan testad kod.
Så, håll innehållet för nästa lansering åtskilt och låt det mogna till ett stabilt tillstånd, redo för lansering.
Schemalägg lanseringarna regelbundet
Jag gav upp idén om att lansera efter varje sprint. Det var tydligt att det inte skulle fungera, åtminstone inte utan negativa effekter som:
- påverka utvecklingsinnehållet i nästa sprint,
- oförmåga att stabilisera lanseringsinnehållet,
- svårigheter att hinna med alla nödvändiga testaktiviteter osv.
Målet blev att lansera i slutet av varannan sprint. Det skulle innebära följande:
- En lansering kommer alltid att innehålla user stories från de två senaste avslutade sprintarna. Eftersom lanseringen genomförs under den pågående sprinten, inkluderas inte sprintens innehåll i lanseringen.
- Det finns en hel sprinttid för att utföra nödvändiga tester och åtgärda buggar.
- Releaseägaren har tillräckligt med tid under icke-release-sprinten för att samla in relevant information (testfall, release notes etc.). På så sätt kan de arbeta relativt självständigt och låta resten av teamet fortsätta arbeta med nya user stories.
- I händelse av att buggar upptäcks kan releaseägaren snabbt samarbeta med en utvecklare för att åtgärda problemet och återgå till sprintens innehåll. Därför bör en viss procentandel av teamets kapacitet reserveras för buggfixar, och det exakta antalet kan fastställas med tiden.
Det är självklart att användarna inte får det senaste innehållet i den senaste utgåvan, men med tiden kommer detta att bli mindre relevant. De kommer att få två sprintar med nytt innehåll vid varje lansering, efter varannan sprint.
Detta verkar vara en bra kompromiss mellan att snabbt leverera värde och att hålla takten i Scrum-arbetet utan större störningar.
Genomför lanseringen
När tester, buggfixar och förberedelse av pipelinen är klara är det ganska enkelt att köra produktionspipelinen och slutföra lanseringen till produktion.
Eftersom den distribueras från en separat gren kan detta i princip vara en obemärkt aktivitet. Ingen behöver veta. Om så är fallet, är det den bästa implementeringen av en lansering.
En förutsättning för detta är att ha en stabil automatiserad DevOps-pipeline, inte bara för produktionsmiljön, utan även för alla andra miljöer (dev, sandbox, test, QA, prestandamiljö etc.). Det ska vara enkelt att med ett klick distribuera lösningarna till alla miljöer.
Lanseringen ska inte vara en smärtpunkt eller stressmoment, eller en mardröm som alla fruktar och förbereder sig för i en vecka. Nej, tvärtom, om ingen märker det, är det det bästa beviset på en lyckad lansering.
Slå samman Release-grenen med utvecklingsgrenen
Release-grenen innehåller nu en del specifikt innehåll som inte finns i den vanliga utvecklingsgrenen, till exempel de korrigeringar som genomfördes under testperioden. Detta innehåll måste slås samman med utvecklingsgrenen för att säkerställa att korrigeringarna behålls även efter nästa lansering.
Vid det här laget fungerar den senaste Release-grenen som en backup ifall det skulle behöva göras en snabbomdistribution av produktionskoden. Om ett akut problem uppstår kort efter lanseringen kan denna gren användas, eftersom den är en exakt kopia av den nuvarande produktionskoden utan nytt outgiven innehåll.
Slutligen, när den nya testperioden börjar, kan den tidigare Release-grenen tas bort och ersättas med en ny, som skapas som en kopia från den aktuella utvecklingsgrenen.
Inför regelbundna lanseringar
Och där har vi det! En stabil process för att hantera lanseringar. Det enda som återstår är att förbinda sig till att göra dem regelbundet, i det här fallet efter varannan sprint.
Genom att göra det regelbundet blir det enklare, främst för att:
- Om lanseringen sker med jämna mellanrum, finns det inte så mycket nytt innehåll att installera i produktionen. Ökningen är liten och anses stabil.
- Mindre nytt innehåll betyder mindre testaktiviteter och skapande av testfall. Det kräver mindre kommunikation, diskussioner och samarbete med intressenter om vad som ska testas. De är också mer benägna att acceptera att det inte var så länge sedan den senaste lanseringen, och lägger mindre vikt vid den.
- Teamet vänjer sig vid cykeln, och det blir en naturlig del av teamets arbete.
- En bieffekt är att utvecklings- och testmiljöer uppdateras regelbundet med ny data. Detta behövs i alla fall för varje testcykel, så det blir inte ytterligare en schemalagd uppgift. Istället är det en del av den befintliga processen, vilket i sig kan påverka stämningen i teamet på ett positivt sätt.
Slutsats
Detta kapitel avslutar mina tidigare inlägg om Scrum-livscykeln och handlar om vad som fungerar i verkligheten.
Ofta börjar team med agil utveckling och gör många fel. Så småningom utvecklas de och börjar göra saker annorlunda. Den här serien kan hjälpa några av dem att göra den förändringen snabbare.
Det här sättet att hantera lanseringar är inte det enda fungerande, och det är inte utan problem. Det kommer fortfarande att finnas utmaningar som teamen måste hantera. Därför bör de fortsätta att förbättra det som går att förbättra och glömma det som inte är meningsfullt.
Men vad jag vet är att detta enkla tillvägagångssätt visat att förändring är möjlig. Från kaotiska, oförutsägbara sprintar till en mer stabil leverans med regelbundna lanseringar som man kan lita på och planera efter. Det kräver ingen speciell eller komplicerad metodik, bara enkla regler och viljan att följa planen.