CI/CD is een belangrijk onderdeel van de moderne manier van applicatiedevelopment die we bij rb2 nastreven. Het biedt ons evenals de keuze voor een cloud-native architectuur de mogelijkheid om zoveel mogelijk waarde voor onze klanten te bieden, en dit ook zo snel mogelijk te doen. Sterker nog, zonder CI/CD is de keuze voor een cloud-native architectuur eigenlijk tamelijk zinloos.
Beide keuzes dienen namelijk eenzelfde doel, maar dan op verschillende niveaus. Waar de keuze voor cloud-native een fundamentele is die te maken heeft met waar je alles op bouwt, raakt CI/CD de business een stuk meer. Met andere woorden, de continue verbeteringen van de software die je bouwt op een cloud-native architectuur middels het CI/CD principe zijn duidelijk merkbaar voor de mensen die ermee moeten werken.
Software altijd in releasebare staat
Als je snel wilt gaan moet er een hoge mate van automatisering zijn, zowel op het gebied van het bouwen als bij het testen van veranderingen. Zo zijn onze pipelines gebaseerd op Git repositories (zowel GitHub als GitLab). Als een developer iets naar Git pusht, gebeurt er ook meteen iets in onze pipeline, waardoor we zo goed mogelijk up-to-date blijven. Pull requests worden zoveel mogelijk geautomatiseerd getest. Het mag duidelijk zijn dat er geen code live gezet wordt zonder dat er een goede review is gedaan, niet alleen geautomatiseerd, maar ook zeker door iemand bij rb2.
Het draait er bij ons vooral om dat software altijd in releasebare staat moet zijn. De automatisering helpt hierbij. Zijn er kleine wijzigingen in de vorm van pull requests, dan voeren we die in minder dan een dag door en pushen die meteen richting de live omgeving. Dit helpt bij het in stand houden van een gezonde codebase voor de applicatie waar je aan werkt. De impact van dergelijke kleine wijzigingen kan daarnaast nooit enorm groot zijn, dus de klant merkt er eigenlijk weinig tot niets van.
Impact op de klant
CI/CD is natuurlijk niet alleen iets waar wij bij rb2 eenzijdig voor kunnen kiezen. Het moet uiteindelijk ook bij onze klanten goed landen. Zoals wel vaker bij relatief nieuwe ontwikkelingen, wisselt de mate waarin men erin meegaat ook bij CI/CD. Deels is dat vanwege het feit dat het toch een andere manier van denken vergt, deels hangt het ook af van waar je CI/CD voor inzet.
Als je als organisatie al jaren gewend bent om met gated releases te werken, dan kan de overstap naar CI/CD best groot zijn. Er wordt continu aan je software gesleuteld, zonder dat je daar echt zicht op hebt. Kleine wijzigingen zouden klanten in een ideale wereld moeten accepteren, ook om het henzelf makkelijker te maken. Dat is echter voor een belangrijk deel een kwestie van vertrouwen, dat je natuurlijk niet zomaar even opbouwt.
De vertrouwenskwestie ligt overigens zeker niet alleen bij de klant. Bij rb2 worden we ook per release nog beter in CI/CD, simpelweg omdat wij ook blijven leren. Door vaak te releasen, word je er nog beter in. Dat zal ook zijn effect hebben op hoe snel we het vertrouwen kunnen winnen.
Kijk vooruit, niet achterom
Het zal nog wel een paar jaar duren voor alle klanten gewend zijn aan CI/CD. Het is uiteindelijk wel belangrijk dat dit gebeurt, omdat het anders veel langer duurt voor de klant zijn concurrentievoordeel kan vergroten ten opzichte van de andere partijen in zijn markt. Vooruit kijken is hierbij dus belangrijk voor klanten.
Vooruit kijken komt ook zeker naar boven als je kijkt naar de impact van CI/CD op roll-backs. Dat is van oudsher een tamelijk vervelende bezigheid. Zeker toen er nog in big bangs werd gedeployed, maar ook als je het continu doet wil je dit eigenlijk niet. Met CI/CD wordt een roll-forward echter steeds makkelijker. Is er een fix nodig voor een feature, dan kun je die fix toepassen door naar de volgende versie te gaan. Niet door een stap terug te gaan om vervolgens te wachten tot er een fix is in de huidige versie. Zo kun je zelfs als iets niet goed gaat toch vooruit blijven kijken en denken.
-
-
-
-
0 Reacties Bewaren