Release Management

Release management er disciplinen omkring planlægning, tidsstyring og kontrol af, hvordan softwareændringer går i produktion. Det dækker, hvad der er inkluderet i en release, hvordan den verificeres, hvordan den implementeres, hvordan den overvåges bagefter, og hvordan den fortrydes, hvis noget går galt. Målet er at gøre overgangen fra bygget til live rutine snarere end begivenhedsrig.

Det mest konsistente fund på dette område modsiger intuitionen. Store udgivelser føles sikrere, fordi de koncentrerer risikoen i en enkelt omhyggeligt styret begivenhed, men beviserne fra forskning i leveringsevne peger i den anden retning: hyppige små udgivelser giver lavere fejlrater og hurtigere gendannelse. En stor udgivelse samler mange ændringer, så når noget går i stykker, er årsagen svær at isolere, og rollback kasserer alt i stedet for den ene fejlbehæftede ændring.

Automatisering af implementering er fundamentet, der muliggør hyppighed. Manuelle implementeringsprocedurer er langsomme, inkonsistente og fejlbehæftede, og deres omkostninger pr. udgivelse skaber pres for batchændringer, hvilket netop producerer de store udgivelser, der indebærer mere risiko. Automatisering af pipelinen, så implementeringen er gentagelig og upåfaldende, fjerner incitamentet til at akkumulere.

At adskille implementering fra udgivelse er den teknik, der ændrer risikoprofilen mest. At implementere kode til produktion med en funktion deaktiveret bag et flag, og derefter aktivere den separat, betyder, at den tekniske handling med at sende kode og den forretningsmæssige handling med at eksponere funktionalitet ikke længere falder sammen. Problemer i implementeringen findes uden at brugerne påvirkes, og funktioner kan eksponeres gradvist og trækkes tilbage øjeblikkeligt uden at skulle genimplementere noget.

Gradvis eksponering følger naturligt af denne adskillelse. Frigivelse til en lille procentdel af trafikken, overvågning af fejlrater og forretningsmålinger og gradvis udvidelse begrænser eksplosionsradiusen for ethvert problem til en brøkdel af brugerne. Dette er betydeligt mere effektivt end omfattende test før frigivelse til at fange den type problem, der kun opstår under reelle produktionsforhold, belastning og data.

Rollback-kapaciteten skal verificeres snarere end antages, og det er her, mange organisationer opdager et problem på det værst tænkelige tidspunkt. En dokumenteret rollback-procedure, der aldrig er blevet udført, fejler ofte, når det er nødvendigt, især når der er tale om databasemigreringer, og skemaændringen ikke blot kan fortrydes. At øve rollback og designe migreringer, der er bagudkompatible, så den tidligere version fortsat fungerer, er det, der gør sikkerhedsnettet virkeligt.

Overvågning efter frigivelse er en del af processen snarere end en separat bekymring. En frigivelse er ikke fuldført, når implementeringen lykkes; den er fuldført, når systemet er blevet observeret i drift korrekt under reel trafik. Ved på forhånd at definere, hvilke indikatorer der skal overvåges, hvor længe, ​​og hvilken tærskel der vil udløse en rollback, konverteres perioden efter frigivelsen fra en vag vagt til et defineret trin med en tilknyttet beslutning.

Kommunikation omkring udgivelser er vigtigere end teams forventer, især hvor ændringer er synlige for kunder eller påvirker interne brugere, som skal være forberedte. Supportteams skal vide, hvad der er ændret, før kunderne spørger, og uanmeldte grænsefladeændringer genererer kontaktvolumen, der ikke står i forhold til deres størrelse. En kort og pålidelig meddelelse, der når ud til de personer, der skal besvare spørgsmålene, koster ikke meget og forhindrer en forudsigelig type forstyrrelser.

Da udgivelsespraksis bestemmes af den underliggende leveringsinfrastruktur lige så meget som af processen, kræver forbedring normalt investeringer i tekniske færdigheder snarere end proceduremæssige ændringer. I praksis etableres dette inden for produktudvikling, overvågningen efter udledning trækker på den måling, der opretholdes gennem dataanalyse således at forretningsmæssig effekt observeres snarere end kun teknisk sundhed, og i organisationer, der kører mange tjenester, ejes standarderne typisk på tværs af Det afdeling i stedet for at blive sat hold for hold.