"Vaak uitrollen? Dat klinkt riskant." Het is de meest voorkomende reactie op CI/CD, en hij heeft het precies andersom. Risico groeit met de omvang van een release, niet met de frequentie. De release die maanden werk in één avond live zet is de riskante; de wijziging van twintig regels die dezelfde middag live gaat, is de veilige. CI/CD is geen modewoord maar de techniek die dat tweede mogelijk maakt: elke wijziging gaat door dezelfde gecontroleerde route, en daardoor is een release bij ons geen gebeurtenis meer.
Wat de pijplijn doet
Bij elke wijziging, klein of groot, gebeurt automatisch hetzelfde:
- Bouwen op een verse omgeving — de applicatie wordt van nul opgebouwd, zonder voorkennis of achtergebleven restanten.
- Testen — de testset draait volledig, elke keer. Niet "even snel de belangrijkste dingen", want daarvoor is geen reden: het kost geen mensentijd.
- Eén artefact — wat getest is, is exact wat uitgerold wordt. Er zit geen handmatige stap tussen waarin nog iets kan afwijken.
- Uitrollen volgens de beschrijving — de declaratieve beschrijving van de applicatie wordt uitgevoerd; niemand hoeft "even de server in".
De spoedfix en het grote nieuwe onderdeel nemen dezelfde route. Dat is het punt: er bestaat geen aparte, minder zorgvuldige weg voor als het snel moet.
Waarom grote releases juist riskant zijn
Een release van veertig wijzigingen tegelijk heeft veertig verdachten als er iets misgaat, en terugdraaien betekent veertig dingen terugdraaien, ook de negenendertig goede. Een release van één wijziging heeft één verdachte, en de error tracking vertelt binnen minuten of hij zich misdraagt. Kleine stappen maken niet alleen de kans op een fout kleiner; ze maken vooral het antwoord op "wat was het?" triviaal.
Daar komt de menselijke kant bij. Een zeldzame release is een gebeurtenis: een avond vrijhouden, iemand paraat, een draaiboek. Gebeurtenissen worden uitgesteld, en uitstel maakt de volgende release groter en dus enger. Zo ontstaat de spiraal waarin "we releasen volgende maand wel" de norm wordt en elke release een beetje meer voelt als een sprong.
Wat je er als opdrachtgever van merkt
Een gemelde fout kan dezelfde dag gerepareerd én live zijn, in plaats van te wachten op "de volgende release". Een klein verzoek blijft een klein verzoek, omdat er geen releaseoverhead omheen zit. En vrijdagmiddag is geen verboden dagdeel: een wijziging die door de pijplijn is gekomen op vrijdag is niet riskanter dan een op dinsdag.
Uit eigen keuken
Ook deze website werkt zo. Elk kennisbankartikel, deze pagina incluis, gaat als commit door een pijplijn die onder meer de metadata en beide taalversies controleert voordat er iets live gaat. Niet omdat een artikel spannend is, maar omdat een route die er altijd is, er ook is als het wél spannend is.
Releases die niemand opvallen
De beste release is er een die niemand heeft gemerkt, behalve degene die op de fix wachtte. Zo richten wij softwareprojecten standaard in, en zo nemen we ook bestaande projecten onder handen die nu nog per gebeurtenis releasen. Benieuwd wat daarvoor nodig is bij jouw applicatie: neem contact op.