Tag Continuous Delivery
Een verbetering (?) in onze pipeline
De verbetering was eenvoudig: rol niet meer altijd alles uit, maar kijk naar de wijziging in de laatste commit. Bevindt die zich in de front-end, rol dan de front-end uit; bevindt die zich in de back-end, dan de back-end. Simpel, duidelijk, efficiënt: iedereen blij. – Maar wat we over het hoofd hadden gezien: merges. Help! Probleem!
Een ontwikkelaar is verantwoordelijk voor drie systemen
Ik weet niet meer waar ik de inval had, onder de douche of op de wc of tijdens het tanden poetsen (duidelijk is in elk geval dat het op de badkamer was): een ontwikkelaar is verantwoordelijk voor (ten minste) drie systemen.
"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.
(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?
Wat houdt ons tegen continu te leveren?
CI/CD houdt meer in dan het alleen inrichten van een buildserver: het is een heel andere manier van werken. Het verlangt van je dat je je werkt anders opdeelt, dat je in kleine stapjes werkt, dat alle code die je schrijft continu van hoge kwaliteit is. Continuous delivery vraagt van ontwikkelaars bepaalde gewoontes – gewoontes waar ze zich goed bij voelen – te herzien.