Releasehantering är disciplinen att planera, schemalägga och kontrollera hur programvaruändringar går in i produktion. Det täcker vad som ingår i en release, hur den verifieras, hur den distribueras, hur den övervakas i efterhand och hur den återställs om något går fel. Målet är att göra övergången från byggd till live-rutin snarare än händelserik.
Det mest konsekventa fyndet inom detta område motsäger intuitionen. Stora utgåvor känns säkrare eftersom de koncentrerar risken till en enda noggrant hanterad händelse, men bevisen från leveransprestandaforskning pekar åt andra hållet: frekventa små utgåvor ger lägre felfrekvens och snabbare återställning. En stor utgåva samlar många ändringar, så när något går sönder är orsaken svår att isolera, och rollback kasserar allt snarare än den enda felaktiga ändringen.
Automatisering av distribution är grunden som möjliggör frekvens. Manuella distributionsprocedurer är långsamma, inkonsekventa och felbenägna, och deras kostnad per release skapar press på batchändringar, vilket leder till just de stora releaser som medför större risk. Att automatisera pipelinen så att distributionen är repeterbar och anmärkningsfri tar bort incitamentet att ackumulera.
Att separera driftsättning från release är den teknik som förändrar riskprofilen mest. Att driftsätta kod till produktion med en funktion inaktiverad bakom en flagga, och sedan aktivera den separat, innebär att den tekniska handlingen att leverera kod och den affärsmässiga handlingen att exponera funktionalitet inte längre sammanfaller. Problem i driftsättningen hittas utan att användarna påverkas, och funktioner kan exponeras successivt och tas bort direkt utan att någonting behöver omdistribueras.
Gradvis exponering följer naturligt av den separationen. Att släppa till en liten andel av trafiken, övervaka felfrekvenser och affärsstatistik, och gradvis expandera begränsar explosionsradien för alla problem till en bråkdel av användarna. Detta är betydligt mer effektivt än omfattande tester före lansering för att upptäcka den typ av problem som bara uppstår under verkliga produktionsförhållanden, belastning och data.
Återställningsförmågan måste verifieras snarare än antas, och det är här många organisationer upptäcker ett problem i värsta fall. En dokumenterad återställningsprocedur som aldrig har körts misslyckas ofta när det behövs, särskilt när det gäller databasmigreringar och schemaändringen inte bara kan återställas. Att öva på återställning och utforma migreringar som är bakåtkompatibla så att den tidigare versionen fortsätter att fungera är det som gör skyddsnätet verkligt.
Övervakning efter utgivning är en del av processen snarare än en separat fråga. En utgivning är inte klar när driftsättningen lyckas; den är klar när systemet har observerats fungera korrekt under verklig trafik. Att i förväg definiera vilka indikatorer som ska övervakas, hur länge och vilken tröskel som skulle utlösa en rollback omvandlar perioden efter utgivningen från en vag vaka till ett definierat steg med ett beslut bifogat.
Kommunikation kring releaser är viktigare än teamen förväntar sig, särskilt där ändringar är synliga för kunder eller påverkar interna användare som måste vara förberedda. Supportteam behöver veta vad som har ändrats innan kunderna frågar, och oanmälda gränssnittsändringar genererar kontaktvolymer som inte står i proportion till sin storlek. Ett kort och tillförlitligt meddelande som når de personer som ska svara på frågorna kostar lite och förhindrar en förutsägbar typ av störningar.
Eftersom utgivningspraxis bestäms lika mycket av den underliggande leveransinfrastrukturen som av processen, kräver förbättring vanligtvis investeringar i tekniska åtgärder snarare än procedurförändringar. I praktiken etableras detta inom produktutveckling, övervakningen efter utsläpp bygger på de mätningar som upprätthålls genom uppgifter analytics så att affärspåverkan observeras snarare än bara teknisk hälsa, och i organisationer som driver många tjänster ägs standarderna vanligtvis av alla IT-avdelning snarare än att ställas lag för lag.