De afgelopen weken heb je meer kunnen lezen over continuous delivery en continuous deployment. In het laatste deel van deze reeks komt het ontwikkelproces aan de orde, want beide werkwijzes hebben behoorlijke impact op de organisatie. En kun je niet wachten om zelf te starten? Lees dan de zeven stappen die je helpen om aan de slag te gaan!
Continuous delivery en/of continuous deployment vereisen beide dat je organisatie snel kan schakelen en mee kan groeien met nieuwe wensen en eisen. En dat werkt natuurlijk niet als je nog volgens een watervalmethodiek werkt. Het zal niet als een verrassing komen dat continuous werken hand in hand gaat met Agile methodieken als Scrum en Kanban.
Veel van de onderliggende engineeringprincipes komen uit Extreme Programming (één van de eerste Agile methodieken). Het iteratieve karakter van Scrum past perfect bij continuous delivery, terwijl het continue proces van Kanban juist weer beter aansluit bij continuous deployment.
Groeiproces
Ook qua groeiproces klopt dit als een bus. Veel organisaties die voor het eerst in aanraking komen met Agile-softwareontwikkeling beginnen met Scrum. Hoewel ze bijna altijd onderschatten hoeveel impact Scrum heeft op de organisatie, introduceert dat wel de juiste mentaliteit voor continuous delivery.
Daarnaast zie je dat teams die volwassen genoeg zijn, uiteindelijk overgaan op Kanban. Kanban is een wat vrijer proces, zonder een vooraf gedefinieerde planning. Hierbij ligt de nadruk op het beperken van de hoeveelheid werk die tegelijkertijd wordt opgepakt. Er kan nog wel een project aan ten grondslag liggen, maar in de praktijk is elk brokje werk dat het team oppakt een afgebakend geheel. Een prima combinatie met continuous delivery dus. Helemaal als ze dat brokje werk volledig geautomatiseerd in productie kunnen zetten.
En nu? Aan de slag in zeven stappen!
Is je interesse gewekt voor continuous development en deployment, maar staat je organisatie hier nog erg ver vandaan? Dan is het slim om stap voor stap te starten. Wat mij betreft is dit de beste aanpak:
- Stap over op Git. Zonder Git is de rest wel te doen, maar een stuk moeilijker. Probeer maar eens met Team Foundation Server verschillende branches te monitoren, zonder elke keer de Team Build-instellingen aan te moeten passen.
- Start met automatiseren van het build process. Heb je dit voor elkaar, dan is het een stuk makkelijker om andere onderdelen gecontroleerd te automatiseren.
- Zorg dat het build process flexibel genoeg is om alle configuratie- en infrastructuurinstellingen te ondersteunen die de beheerafdeling normaliter handmatig uitvoert. Zo hoef je straks geen handmatige stappen meer uit te voeren, buiten het op de juiste plek zetten van de dll’s of executables.
- Vervang eventuele database scripts met een library die schema’s vanuit code kan bijwerken naar de laatste versie. Fluent Migrator en Entity Framework kennen beide zulke functies.
- Begin met het herstructuren van de broncode (ook wel refactoring genoemd) en zorg dat je meer en meer aspecten automatisch test vanuit het build process. Overweeg ook om onderdelen van het systeem los te trekken, zodat je die apart kunt beheren en ontwikkelen.
- Kies een releasestrategie en volg die ook, eventueel in combinatie met automatische versionering met behulp van Gitversion.
- Begin met het schrijven van tijdelijke karaktertesten die als vangnet dienen voor de veranderingen die nodig zijn om continuous delivery of deployment mogelijk te maken.
Bestaande patronen doorbreken
Het mooie van alle in dit artikel genoemde werkwijzen, is dat ze ieder al een heel specifiek probleem oplossen. Continuous delivery kan een doel op zich zijn, maar het is de weg ernaartoe die het grote verschil maakt. In tegenstelling tot veel alles-of-niets principes zoals bijvoorbeeld Scrum, zijn het de individuele stappen die je softwareontwikkeling naar een hoger plan brengen.
En hoewel er behoorlijk wat technische uitdaging zit in het introduceren van deze nieuwe kijk op softwareontwikkeling, is dat niet de grootste uitdaging van het geheel. Wat veel lastiger zal zijn, is het doorbreken van de bestaande patronen. Zeker als verantwoordelijkheden nog verdeeld zijn over verschillende – mogelijk zelfs fysiek gescheiden – afdelingen. Maar als je dat punt eenmaal voorbij bent, vraag je je waarschijnlijk af hoe je ooit überhaupt zonder kon werken.
