Tag Continuous Deployment
Worsteling
We betoogden tegen verschillende omgevingen voor ontwikkel, test, acceptatie en productie: dat is duur en bovendien nodeloos complex. Er is maar één omgeving die ertoe doet: productie. Maar om de wijzigingen naar productie klein en veilig te houden, kunnen we functionaliteit verbergen. – “Dat is valsspelen!” riep iemand in het publiek, de wanhoop nabij. “Je hebt nu alsnog een testomgeving, alleen dan op productie!”
Bezwaren tegen continuous deployment
Continuous deployment is: elke commit gaat meteen naar productie. Er is geen testomgeving, er is geen acceptatieomgeving; er zijn geen lang levende branches behalve de main branch, en die is gelijk met productie. – Waanzin! wil je roepen, dat kan nooit werken! – Oké. Waarom niet?
Aantekeningen over continuous deployment
De grootste uitdaging in het omarmen van continuous deployment ligt niet in het technische aspect. Deployment pipelines zijn anno 2026 alomtegenwoordig, unittesting is (bij de meeste teams) niet meer optioneel, en feature flags zijn in hun simpelste vorm niet meer dan eenvoudige booleans. Om continuous deployment een succes te kunnen maken, zullen de mensen hun vertrouwde manieren van werken moeten herzien.
De increment, het cadeautje
Scrum is, als ik het meningencircus op LinkedIn mag geloven, al een tijdje uit de mode. Dat is onterecht en terecht. Het is onterecht in zoverre dat veel interpretaties en implementaties van Scrum de geest van het framework niet gevat hebben. Maar het is terecht in zoverre dat Scrum wel degelijk tekenen van ouderdom vertoont, littekens van de tijd waarin het is ontstaan. Beide soorten problemen komen bijeen in de notie van het increment.
"Trunk"
Op het virtuele bord van onze Retrospective verscheen in de kolom kan beter een sticky met maar één woord erop: ’trunk’. Na een aardige tijd trunk-based te hebben ontwikkeld, bekende een collega de werkwijze nog altijd niet helemaal onder de knie te hebben.
De vergeten tester
Twee dingen kunnen tegelijkertijd waar zijn. (1) Ik vind de tester de belangrijkste rol hebben in het team. (2) Ik wil geen tester in het team. – Ik wil haast zeggen: de rol van de tester is te belangrijk om bij een tester neer te leggen, maar die uitspraak is makkelijk te misinterpreteren en nodeloos provocerend. En toch…
(Hoe te) releasen als het spannend wordt?
De laatste PI-planning stond er een interessante sessie op de agenda: ‘Releasen als het spannend wordt’. De titel intrigeerde ons. Met de boekenclub lazen we op dat moment Continuous Deployment van Valentina Servile, dus de hele notie van een spannende release deed de wenkbrauwen fronsen. Waar kwam dit gevoel vandaan?
Gaan we snel genoeg?
Sinds kort ben ik in van team gewisseld. Sinds die wissel mag ik mezelf met recht full stack developer noemen. Ik ben verantwoordelijk voor de back-end, de front-end – de database, de infrastructuur, security – de requirementsanalyse, de tests… Je kunt je voorstellen: het kan even duren voordat een (ogenschijnlijk) eenvoudige feature afgerond is. Af en toe maakt een knagend schuldgevoel zich dan ook meester van me: gaan we snel genoeg?