Sneller releasen. Minder fouten. Meer schaalbaarheid. Het is niet zo gek dat CI/CD steeds meer wordt toegepast. De vele beschikbare CI/CD-tools en het steeds meer werken in de cloud maken het logisch en relatief makkelijk. Toch is er wel een valkuil: de organisatie moet er klaar voor zijn. Daar staat tegenover dat je altijd klein kunt beginnen en veel resultaat kunt boeken terwijl je weinig risico neemt.

CI/CD is een manier om volledig geautomatiseerd applicaties te ontwikkelen en te leveren. Kern is de automatisering van handmatige processen. Niet voor niets gaan CI/CD en DevOps vaak samen. Ze kunnen ook zonder elkaar, maar het is logisch om ze te koppelen. DevOps wordt immers lastig zonder CI/CD-tooling en DevOps maakt CI/CD een stuk relevanter.

CI EN CD: DRIE FASES

SNEL, VAAK EN FOUTLOOS

Veel organisaties die met CI/CD willen gaan werken, zien voordelen als snelheid en kwaliteit. Dat is volkomen terecht: met CI/CD kan je vaker kleine releases doen; de veranderingen zijn daardoor relatief klein en er is minder kans dat er iets misgaat. Omdat alle handelingen en fouten worden vastgelegd, ben je bovendien niet afhankelijk van de kennis van specifieke collega’s. En als eenmaal alles is geautomatiseerd, dan is het veel makkelijker om een extra omgeving op te spinnen voor een demo, test of experiment. Tot slot breng je dankzij kortere feedbackloops snel wijzigingen aan en los je problemen snel op. Voordelen te over.

En dan is CI/CD ook nog eens heel breed toepasbaar. Bijvoorbeeld in de FinTech, de zorg of bij de overheid. Branches waarin het vaak relevant is om de toegang tot omgevingen te minimaliseren. Dankzij de pipelies zijn er geen admins meer nodig die alle handmatige stappen uitvoeren en voor Break Glass / Disaster Scenario’s kun je tevoren admin accounts opzetten en een alert instellen bij gebruik. Het maakt ‘Keep people away from data’ gemakkelijker.

CODE SCHRIJVEN BLIJFT ESSENTIEEL

Wie wil beginnen met CI/CD, hoeft niet meteen de hele pipeline te automatiseren. Veel bedrijven hebben dat ook helemaal niet nodig. Een deel van het proces automatiseren, levert vaak al veel winst op. Wel belangrijk is het besef dat – ook bij een gedeeltelijke overstap – een bepaalde mate van aandacht en expertise belangrijk zijn om het te laten werken. Code schrijven blijft essentieel. Bovendien is – net als bij iedere systeemverandering – de juiste cultuur voorwaardelijk voor succes: een organisatie die er niet klaar voor is, zal worstelen met CI/CD. Het is dan vooral het CD-gedeelte dat vaak vraagt om een cultuurverandering. Er is immers veel vertrouwen nodig in de engineers. Als iedere release toch weer over dertig schijven moet en de afstemming weken duurt, is de snelheid er direct weer uit. In dat kader is steun vanuit het management onmisbaar.

Ook is het belangrijk dat er ruimte is om mensen op te leiden en bij te scholen, al is het maar omdat development en operations meer van elkaar te weten moeten komen. Maar ook het schrijven van code, het bouwen van de infrastructuur, het kiezen van de deployment strategie, het opzetten van een veilige releaseomgeving: het zijn zaken die vragen om specifieke kennis die niet iedere generieke developer standaard in huis heeft.

RISICO NEMEN OF BEPERKEN?

Neem de deployment strategie. De keus is ruim, met aan het ene uiterste Blue-Green: hiermee neem je het minste risico, maar het is wel het meest complex en kostbaar. Je hebt hierbij namelijk altijd twee omgevingen draaien waartussen je kunt schakelen. Bij wijzigingen of problemen ervaar je daardoor minimale downtime.

Het andere uiterste is werken met back-ups. En er zit een aantal varianten tussenin, zoals de Canary-release. Daarbij leid je een van het verkeer naar een nieuwe versie, het andere deel niet. Gaat er iets mis, dan heeft hooguit de helft van de klanten er last van. Relatief eenvoudig, maar wel met wat meer risico.

Als het gaat om het beperken van risico, is klein en intern beginnen een aanrader. Automatiseer een taak die relatief vaak wordt uitgevoerd en die veel handmatige componenten kent. Je creëert zo een afgebakend geheel om mee te oefenen. Gaat er iets mis, dan hebben je klanten daar geen last van. Terwijl je wel meteen resultaat ziet. Low risk, high impact. Heb je wat ervaring opgedaan, dan kan je het breder gaan uitrollen.

Met bart sparren over de cloud?