Vad är releasehantering (release management)?

Releasehantering innefattar en serie strukturerade steg som hjälper företag att optimera hela livscykeln för deras release, från initiering till distribution osv.

Till att börja med, vad är en release?

En release är en uppsättning nya funktioner, buggfixar, tillägg eller ändringar för distribution till en levande, operativ miljö. En releasehanteringsprocess avser hanteringen av dessa releaser, från skapandet och hela vägen till testning och idrifttagning.

Framgångsfaktorn för en release kan bestämmas av hur väl den integreras i den verkliga miljön, om det uppstår några störningar och hur positiv inverkan den har på användarupplevelsen.

För att uppnå en lyckad release måste du fastställa effektiva releasehanteringsstrategier för att hålla koll på hela livscykeln för din release.

Hur går det till?

Till att börja med måste du ha en klar förståelse för hur en typisk release livscykel ser ut.

Eftersom det är vanligt att flera team arbetar på en release, skulle du kräva tydligt definierade mål, gedigen planering, effektiv kommunikation och samarbete. Och detta kan vara svårare än det låter utan en ordentlig releasehanteringsprocess.

Olika organisationer ha olika processer baserat på deras team, projektstorlek, affärsmål och behov. Vi har dock beskrivit de olika stadierna som skulle utgöra en typisk releaselivscykel.

Initiering

Releasehanteringsprocessen initieras vanligtvis när det uppstår en begäran om att introducera nya funktioner, implementera buggfixar eller utföra ändringar av befintliga funktioner.

Det är inte alltid som alla dessa förfrågningar skulle leda till en ny version. Varje förfrågan bedöms noggrant baserat på kriterier som:

• Företagspåverkan
• Prioritet
• Genomförbarhet
• Eventuella risker
• Kostnad

När behovet och omfattningen av releasen har identifierats och begäran får grönt ljus från de involverade parterna, är det dags för nästa steg: planering.

Planering

Detta är ett avgörande steg i releasehanteringsprocessen, eftersom du i huvudsak fastställer releasestrukturen. Det är här som releasens mål definieras, risker bedöms och strategier utarbetas.

Även om olika team kan ansvara för olika uppgifter, är det bra att ha en övergripande release hanteringsplan som främjar en delad förståelse för ansvar, mål och förväntningar.

Detta skulle säkerställa att de olika teamen (utveckling, infrastruktur, support osv) alla är överens redan i ett mycket tidigt skede.

En solid releaseplan kommer att:

• Tydligt beskriva målen med releasen för att vägleda alla inblandade mot en gemensam vision.
• Definiera hur releasen ska implementeras och vilken roll varje teammedlem ska ha.
• Registrera uppgifter om releasens inverkan som releasen skulle få i produktionsmiljön.
• Ha beredskapsplaner redo för att se till att du är beredd att hantera potentiella utmaningar.
• Ha en checklista redo som de inblandade teamen eller enskilda medarbetare kan hänvisa till under hela releaseprocessen.
• Kommunicera data om nertid genom att sätta tydliga tidslinjer och se till att de inblandade är välinformerade i förväg.

Designa och bygga

När väl stadiet för idéer och planering är ur vägen, är det dags för utvecklingsstadiet.

Nu är det dags för utvecklingsteamet att designa och bygga releasen. Det är här kraven förvandlas till kod och de planerade funktionerna eller förbättringarna förvandlas till körbar programvara.

Testning

Detta steg hjälper till att säkerställa att den pågående produkten körs korrekt och är redo för lansering.

Det är bra att ha dedikerade kvalitetssäkringsteam (QA) för att upptäcka och åtgärda fel och buggar i programvaran innan den kan distribueras. Om fel upptäckts skickas koden tillbaka till utvecklarna för nya tester.

Test av användaracceptans

Efter att releasen har godkänts av era huvudleads, kommer releasen sedan att iscensättas för användaracceptans (UAT) för att testa produktens användbarhet i förhållande till konsumenternas förväntningar. I detta skede skulle utvalda användare testa programvaran i den "verkliga världen" och tillhandahålla sin feedback. Om och när fel identifieras går utvecklarna tillbaka till ritbordet för att åtgärda dessa problem innan releasen kan distribueras till live-miljön.

Spridning

Efter att ha klarat alla nödvändiga tester distribueras det godkända releasepaketet till målmiljön där en mer omfattande användarbas kan komma åt den nya versionen.

I detta skede rullas releasen ut enligt det fastställda schemat för att säkerställa en smidig implementering med minimala risker. Om releasen ställer till stora problem under idrifttagningen måste du vara beredd att bromsa releasen utgåvan utan att det inverkar negativt på produktionsmiljön. Det är därför av stor vikt att ha ordentliga beredskapsplaner på plats.

Dessutom tar inte distributionen slut så snart implementering av releasen är klar. Det gäller även att informera och utbilda alla användare om ändringarna och de nya funktionerna. Slutanvändare, såväl medarbetare som kunder, måste informeras och utbildas om releasen för att säkerställa att de har en tydlig förståelse för hur man använder programvaran effektivt.

Efterdistribution

Efter implementeringen är det viktigt att fortsätta övervaka den installerade versionen för eventuella problem så att de kan åtgärdas omedelbart. Ha ett möte efter implementeringens genomförande för att reflektera över lyckade resultat och områden för förbättringar. Spåra programmets förmåga att möta affärsbehov och användarnas förväntningar genom att observera viktiga KPI:er och mätvärden. Dokumentera lärdomar och förbättringar som ska implementeras i framtida versioner.

Här är några av de frågor som du bör kunna svara på efter implementeringen:

• Fungerar programmet som förväntat och har prestandariktmärken uppfyllts?
• Har alla beroenden implementerats framgångsrikt?
• Rullades releasen ut enligt schemat och har alla servicenivåer uppfyllts?
• Återspeglar CMDB det nuvarande tillståndet i din IT-miljö efter implementeringen?
• Kan releasen rullas tillbaka vid behov?
• Är alla inblandade nöjda med förändringarna?
• Krävs det mer träning för att användarna ska kunna dra nytta av förändringarna?
• Har dokumentationsuppdateringar gjorts, inklusive releaseanteckningar och felsökningsguider?

Det finns olika metoder och tillvägagångssätt för produktdistribution, och vilken speciell strategi du använder beror till stor del på projektets omfattning, tidsramen för programvarans distribution, hur många som arbetar med releasen och typ av användare som programvaran är avsedd för.

Låt oss jämföra modellerna Vattenfall, Agil och DevOps.

Vattenfallsmodellen

Vattenfallsmodellen är en traditionell, injär och relativt strikt distributionsmetod.

Eftersom den använder en sekventiell process (planera, bygga, testa och distribuera), måste varje steg slutföras innan man kan gå vidare till nästa, och man kan inte gå tillbaka till föregående steg för ändringar. Detta innebär att det tar avsevärd längre tid att lansera varje ny release, vilket resulterar i långa releasecykler. Med tanke på programutvecklingsprocessens dynamiska karaktär, upptäcker man snart att detta tillvägagångssätt inte alltid är praktiskt genomförbart.

Det agila förhållningssättet

Detta är en mer iterativ implementeringsmetod där inkrementella releaser planeras, med syfte att rulla ut releaserna snabbt och hållbart. Denna metod fungerar genom att dela upp releasen i iterationer/sprints istället för att distribuera allt på en gång. Detta tillåter mer flexibilitet och snabba svar på förändrade krav.

Även om agila metoder som hjälper till att avsevärt öka hastigheten och effektiviteten i distributionen, löser de inte alltid problemen i teamsilon (vilket kan vara en avgörande faktor i programutvecklingen). Detta leder till vårt nästa ämne, DevOps.

Release-hantering i DevOps

DevOps är byggt på agila metoder och följer dess arbetssätt med inkrementella framsteg, samtidigt som det främjar tvärvetenskapligt teamsamarbete, automatiseringar och feedback.

DevOps syftar till att överbrygga klyftan mellan utvecklare och IT-drift, genom att betona deras ständiga samarbete och kommunikation, för kortare feedback-loopar och snabbare releaselanseringar.

Idag när de flesta program har flyttats till eller redan erbjuds genom en SaaS-modell, finns det ett konstant behov att kontinuerligt leverera nya funktioner för att öka deras mervärde och hålla jämna steg med konkurrenterna. Genom en kontinuerlig och integrerad process av utveckling, testning och idrifttagning, finner man att DevOps är en lämplig implementeringsmetod för sådana snabba releaser.

När det kommer till Agil och DevOps behöver du inte oroa dig för att välja rätt. Du kan använda Agilmetodens ramverk för att organisera arbetet, och använda DevOps för att främja en samarbetskultur.

CI/CD

CI/CD - continuous integration and continuous delivery/deployment (kontinuerlig integration och kontinuerlig leverans/distribution) är en del av det bredare DevOps-ramverket, där iterativa kodändringar byggs, testas, distribueras och övervakas.

Kontinuerlig integration

Kontinuerlig integration är var du gör små ändringar i koden och integrerar med det delade kodlagret. När dessa ändringar aktiveras utlöses automatiserade tester för att upptäcka kodkonflikter mellan den nya och gamla koden, vilket gör det lättare att åtgärda fel snabbt och i tid.

Kontinuerlig leverans

Kontinuerlig leverans är en förlängning av kontinuerlig integrering där när den nya koden har distribuerats. Ändringarna valideras genom automatiserade bygg- och enhetstester och koden levereras för kollektiv testning i en produktionsliknande miljö.

Kontinuerlig distribution

Alla ändringar som klarar de automatiserade testerna är redo för implementering. Kontinuerlig distribution kan avse automatiserad release av dessa ändringar från stadie till produktion, där programvaran kan användas av användare.

Som vi redan vet utvecklas företag ständigt och det gör också deras krav — vilket gör förändringar oundvikliga. Förändringshantering fokuserar därför på att säkerställa en noggrann dokumentation, godkännande och utvärdering av föreslagna ändringar. Releasehantering däremot kan vara en del av förändringens livscykel genom att tillhandahålla ett sätt att implementera de godkända ändringarna effektivt och utan störningar.

Även om de är sammankopplade har förändrings- och releasehantering nyanserade skillnader i hur de fungerar och vad de avses uppnå.

Förändringshantering fungerar som en portvakt, som lägger grunden för planering och utvärdering av de förändringar som planeras i produktionsmiljön. Releasehantering är mer av en verkställare, i den meningen att den fokuserar på själva konstruktionen, testningen och implementeringen av dessa förändringar i live-miljön.

Release-managers övervakar hela releaselivscykeln och leder och styr hela av releasehanteringsprocessen. De ansvarar för utgivningsprocessens ledning och samordning. Sålunda skulle en release manager förväntas:

• Definiera en tydlig releasestrategi genom att upprätthålla en övergripande och robust releaseplan.
• Har god kommunikations- och samarbetsförmåga.
• Samordna uppgifter över olika team som utveckling, testning, drift och support.
• Se till att releaseschemat följs till punkt och pricka.
• Vara väl insatt i projektledning.
• Ha en djupgående förståelse för DevOps och CI/CD-verktyg.
• Ha goda kunskaper i bästa implementeringspraxis.
• Se till att leveranserna distribueras på ett hållbart sätt till produktionsmiljön.
• Validera release-anteckningar och annan dokumentation.
• Underlätta utvärdering efter lanseringen, registrera mätvärden och samla in feedback för att förbättra releasehanteringsprocessen.

1. Sätt tydliga mål och få med alla

Definiera releasens tydliga mål, omfattning, fördelar, risker och effekter och se till att målen överensstämmer med verksamhetsmålen.

2. Fastställ övergripande planer

Skapa en detaljerad releaseplan, inklusive uppgifter, beroenden, ansvarsområden, tidslinjer, utrullningsplaner och checklistor. Glöm inte att fastställa beredskapsstrategier med noggranna backupplaner så att du snabbt kan återhämta dig efter eventuella störningar och upprätthålla tjänstens kontinuitet.

3. Upprätta en releasekalender

Upprätta en releasekalender med varje releasedatum. Kommunicera schema och nertid genom att sätta tydliga tidslinjer och se till att de inblandade är välinformerade i förväg.

4. Automatisera när så är möjligt

Manuell testning och idrifttagning är tidsödande och risken för mänskliga fel är uppenbar. Använd CI/CD-verktyg för att automatisera uppgifter som att bygga, testa och distribuera programvaran för en effektiv releaseprocess.

5. Pusha releaser till en väldesignad iscensättningsmiljö

Testa din kod i en iscensättningsmiljö som är designad för att vara så lik produktionsmiljön som möjligt, för att säkerställa att releasen inte påverkar användarna negativt när den distribueras.

6. Gör en ”mörklansering”

En mörklansering (dark launch) är när de nya funktionerna distribueras till en liten grupp av användare innan de lanseras till en större grupp. Detta hjälper till att utvärdera hur programmet presterar i den verkliga världen, fixa eventuella fel och även samla in värdefull användarfeedback.

7. Distribuera versionen till dina målanvändare

Eftersom mörklansering tillåter säker testning under produktion, kan du aktivera funktionen till 100% av dina målanvändare när du är säker på att allt fungerar som det ska i en verklig produktionsmiljö. Innan releasen släpps live, granska och se till att återställningsprocesserna är på plats. Att ha en pålitlig återställningsplan hjälper till att snabbt återgå till den tidigare stabila versionen om något skulle hända.

8. Spela in alla aspekter av releasen och håll även dokumentationen uppdaterad

Upprätthåll korrekt dokumentation som inkluderar kommentarer, installationsguider och felsökningsinformation, för att inte bara främja en heltäckande förståelse om releasen för användare, utan också underlätta smidigare distributioner av framtida releaser.

9. Spåra statistik för releasehantering

Övervaka kontinuerligt den släppta programvaran i produktionsmiljön genom att hålla koll på viktiga KPI:er och mätvärden.

Här är några mätvärden som du kan spåra:

• Releaser som levererats enligt schema
• Försenade releaser
• Framgångsfrekvens
• Nertid
• Antal annulleringar
• Felfrekvens
• Antal incidenter orsakade av en release
• Kundfeedbackbetyg

Utförd på ett effektivt sätt erbjuder releasehantering många fördelar för företag, genom att tillhandahålla ett strukturerat och kontrollerat tillvägagångssätt för distribution av programvaruversioner.

Fem fördelar med att ha en korrekt releasehanteringsprocess på plats.

• Förbättrat samarbete Genom att främja samarbete mellan CAB, projektledningsteam, utvecklare, QA-team, drift och support, säkerställer releasehantering ett sömlöst utbyte av information, minskar silos, möjliggör snabbare återkopplingsslingor och främjar en synkroniserad releaseprocess.
• Förutsägbar distribution: Strukturerad schemaläggning hjälper företag med förutsägbarhet i programreleaseprocessen. Detta minskar också tiden till marknad för programvarureleaser, vilket gör att de snabbt kan reagera på förändrade affärsbehov och förbli konkurrenskraftiga.
• Riskhantering: Team kan identifiera potentiella flaskhalsar och kodkonflikter via grundliga tester och omfattande konsekvens- och riskbedömningar. Detta hjälper dem att ta itu med utmaningar i ett mycket tidigt skede innan de förvandlas till betydande problem, och det får en negativ påverkan hos slutanvändarna.
• Förbättrad styrning: Genom att hålla koll på statusen för varje release och dess hela livscykel, samt vilket stadium den för närvarande befinner sig i, får företag en realtidsöversikt över releasens framsteg för välgrundade beslut.
• Förbättrad användarnöjdhet: Förbättra den övergripande användarupplevelsen genom att leverera högkvalitativa programvaruversioner som är korrekt testade, felfria och anpassade till kundernas förväntningar, för ökad kundnöjdhet och lojalitet.