Releasebeheer

Releasemanagement is de discipline die zich bezighoudt met het plannen, inplannen en controleren van de implementatie van softwarewijzigingen in productie. Het omvat wat er in een release wordt opgenomen, hoe deze wordt geverifieerd, hoe deze wordt geïmplementeerd, hoe deze achteraf wordt gemonitord en hoe deze wordt teruggedraaid als er iets misgaat. Het doel is om de overgang van gebouwde naar live-omgeving routinematig te laten verlopen in plaats van stressvol.

De meest consistente bevinding op dit gebied spreekt de intuïtie tegen. Grote releases voelen veiliger aan omdat ze het risico concentreren in één zorgvuldig beheerde gebeurtenis, maar bewijs uit onderzoek naar leveringsprestaties wijst juist het tegenovergestelde aan: frequente, kleine releases leiden tot lagere faalpercentages en sneller herstel. Een grote release bundelt veel wijzigingen, waardoor de oorzaak moeilijk te achterhalen is wanneer er iets misgaat, en een rollback alles verwijdert in plaats van alleen de ene foutieve wijziging.

Automatisering van de implementatie vormt de basis voor frequente implementaties. Handmatige implementatieprocedures zijn traag, inconsistent en foutgevoelig, en de kosten per release leiden tot de druk om wijzigingen in batches uit te voeren. Dit resulteert juist in grote releases die meer risico's met zich meebrengen. Door de pipeline te automatiseren, zodat de implementatie herhaalbaar en probleemloos verloopt, verdwijnt de prikkel om grote releases in batches uit te voeren.

Het scheiden van implementatie en release is de techniek die het risicoprofiel het meest verandert. Code implementeren in productie met een functionaliteit die is uitgeschakeld met een vlag, en deze vervolgens apart inschakelen, betekent dat de technische handeling van het uitbrengen van code en de zakelijke handeling van het beschikbaar stellen van functionaliteit niet langer samenvallen. Problemen tijdens de implementatie worden ontdekt zonder dat gebruikers er last van hebben, en functionaliteiten kunnen geleidelijk worden vrijgegeven en direct weer worden ingetrokken zonder dat er iets opnieuw hoeft te worden geïmplementeerd.

Geleidelijke blootstelling vloeit op natuurlijke wijze voort uit die scheiding. Door de release te laten plaatsvinden aan een klein percentage van het verkeer, foutpercentages en bedrijfsstatistieken te monitoren en geleidelijk uit te breiden, wordt de impact van een probleem beperkt tot een fractie van de gebruikers. Dit is aanzienlijk effectiever dan uitgebreide tests voorafgaand aan de release om problemen op te sporen die zich alleen voordoen onder reële productieomstandigheden, belasting en data.

De mogelijkheid tot terugdraaien moet worden geverifieerd in plaats van aangenomen, en dit is waar veel organisaties op het slechtste moment met een probleem worden geconfronteerd. Een gedocumenteerde terugdraaiprocedure die nooit is uitgevoerd, faalt vaak wanneer deze nodig is, met name bij databasemigraties waarbij de schemawijziging niet zomaar ongedaan kan worden gemaakt. Het oefenen met terugdraaien en het ontwerpen van migraties die achterwaarts compatibel zijn, zodat de vorige versie blijft functioneren, is wat het vangnet daadwerkelijk maakt.

Monitoring na de release is onderdeel van het proces en geen aparte zorg. Een release is niet voltooid wanneer de implementatie succesvol is verlopen; de release is voltooid wanneer is vastgesteld dat het systeem correct functioneert onder reële belasting. Door vooraf te definiëren welke indicatoren in de gaten worden gehouden, hoe lang, en welke drempelwaarde een terugdraaiing activeert, verandert de periode na de release van een vage observatie in een gedefinieerde stap met een bijbehorende beslissing.

Communicatie rondom releases is belangrijker dan teams denken, vooral wanneer wijzigingen zichtbaar zijn voor klanten of interne gebruikers beïnvloeden die op de hoogte moeten zijn. Supportteams moeten weten wat er is veranderd voordat klanten ernaar vragen, en onaangekondigde interfacewijzigingen genereren een onevenredig grote hoeveelheid contactverzoeken. Een korte, betrouwbare melding die de mensen bereikt die de vragen moeten beantwoorden, kost weinig en voorkomt een voorspelbare vorm van verstoring.

Omdat de releasepraktijk evenzeer wordt bepaald door de onderliggende leveringsinfrastructuur als door het proces zelf, vereist verbetering doorgaans investeringen in engineering in plaats van procedurele wijzigingen. In de praktijk wordt dit vastgesteld binnen productontwikkelingDe monitoring na de vrijlating maakt gebruik van de metingen die worden bijgehouden via Data analytics zodat de impact op de bedrijfsvoering wordt geobserveerd in plaats van alleen de technische gezondheid, en in organisaties die veel diensten aanbieden, worden de standaarden doorgaans door iedereen beheerd. IT afdeling in plaats van het per team vast te stellen.