Continuous Deployment in Scrum

​20 december 2016 - Sinds de overstap naar Agile en Scrum zijn steeds meer bedrijven geïnteresseerd in DevOps en het overstappen naar Continuous Deployment. Continuous Deployment is de meest verregaande manier van werken om software in productie te brengen, Continuous Integration en Continuous Delivery zijn de fasen die hieraan voorafgaan.

Verschillen Continuous Integration, Continuoius Delivery en Continuous Deployment

Figuur 1: Verschillen Continuous Integration, Continuous Delivery en Continuous Deployment

Continuous Integration

Bij Continuous Integration wordt er regelmatig (bij voorkeur meerdere keren op een dag) software ingechecked door de ontwikkelaars. Dit wordt gedaan nadat de Unit tests op de lokale omgeving succesvol hebben gedraaid. Na elke commit wordt er (automatisch) een nieuwe versie gebouwd en worden er één of meerdere soorten tests gedraaid. Denk hierbij aan Integratie testen, Functionele testen, Perfomance testen et cetera. Afhankelijk van hoe ver je als organisatie bent qua volwassenheid, zullen de testen uitgebreider zijn.
Voordeel van deze werkwijze is dat je als team frequent feedback krijgt over de gebouwde oplossing. Daarbij zie je direct of een nieuwe wijziging ervoor zorgt dat of de build niet meer werkt of dat testen niet meer succesvol zijn. Je weet direct welke wijziging hiervoor verantwoordelijk is en dat maakt het relatief eenvoudig dit op te lossen.

Continuous Delivery

Wanneer Continuous Integration goed in de werkwijze is ingebed kun je kijken naar de volgende stap, Continuous Delivery. De aanvulling op Continuous Integration is dat elke commit niet alleen wordt getest maar ook, na goedkeuring, in productie gezet kan worden. De enige stap die nog handmatig wordt uitgevoerd is de Acceptatie test. Ook het moment en uitvoeren van de release naar productie is nog een manuele actie.
Het kan zijn dat dit voor organisaties een must is omdat je niet gedurende de dag bijvoorbeeld een nieuwe versie naar productie mag brengen. Bijvoorbeeld omdat er afspraken met gebruikers zijn dat dit volgens een vast schema plaatsvindt  of omdat de organisatie hier bij aanvang nog geen vertrouwen erin heeft. Het automatisch testen is voor deze stap essentieel, als je dit niet goed op orde hebt zul je in deze fase niet succesvol zijn.

Continuous Deployment

De laatste fase is Continuous Deployment. Sommige mensen verwarren Continuous Delivery met Continuous Deployment, maar er zit een groot verschil tussen. Bij Continuous Deployment wordt elke commit daadwerkelijk gereleased naar de productie omgeving. Er vindt geen enkele handmatige interactie meer plaats. Het testen (inclusief Gebruikers Acceptatie test) en het uitrollen naar productie wordt volledig automatisch uitgevoerd. Een voorbeeld van deze werkwijze kun je vinden bij een aantal webwinkels die meerdere keren per minuut een release doen van de software.

Continuous Deployment Maturity model

Met voorgaande in het achterhoofd is het duidelijk dat je niet zomaar kunt beginnen met Continuous Deployment. Om dit te kunnen doen zul je volwassen moeten worden in de verschillende facetten die horen bij Software ontwikkeling. Om dit in kaart te brengen kun je kijken naar een Continuous Deployment Maturity model zoals hieronder weergegeven. Continuous Deployment Maturity modelFiguur 2: Continuous Maturity Model
 
Het model is opgebouwd rondom een aantal facetten: Culture & Organization, Build & Deploy, Release, Data management, Test & Verificatie en Information & Reporting. Elk facet doorloopt een aantal fasen. In dit artikel lichten we het onderdeel Cultuur en Organisatie uit. In een volgend artikel worden de andere facetten toegelicht.

Cultuur en Organisatie

Fase 1: Initial
In de eerste fase zitten organisaties die aan het begin staan van Agile en Scrum. De teams zijn nog georganiseerd op basis van technologie. Denk hierbij aan een team dat werkt aan een Cobol applicatie of onderdeel, een team dat werkt aan een .Net oplossing en een team dat zich focust op database aanpassingen en onderhoud. Er is een lijst met requirements, soms al vastgelegd in een backlog en deze wordt ook geprioriteerd. De werkwijze is in een proces vastgelegd.

Fase 2: Managed
Wanneer het team volwassener wordt komt het in de volgende fase. In deze fase is er één backlog per team beschikbaar. Het werken volgens een van de Agile methodes (bijvoorbeeld Scrum, Kanban, XP) wordt geïntroduceerd en toegepast binnen de teams. Testen wordt betrokken bij het ontwikkelen binnen het team.

Fase 3: Defined
In de volgende fase van volwassenheid wordt de samenwerking met Operations gestart. Het is mogelijk dat Operations onderdeel is van het team, ze worden in ieder geval regelmatig betrokken bij de werkzaamheden van het team. Changes, oplossing van Bugs en realisatie van nieuwe features worden allemaal op dezelfde wijze naar productie gebracht. Het team trekt steeds meer verantwoordelijkheid naar zich toe. Denk hierbij aan o.a. kwaliteit, velocity maar ook het doorvoeren van proces en product verbeteringen.

Fase 4: Quantatively managed
In de volgende fase van volwassenheid is het team zelf verantwoordelijk voor het doorvoeren van wijzigingen op productie. Er vindt binnen het team Continuous improvement plaats.
 

Figuur 3: Continuous Improvement cyclus

Oplevering van functionaliteit kan los staan van oplevering naar productie. Dit betekent dat alles wat wordt gebouwd naar productie kan. Toch zie je vaak dat er nog in releases wordt gewerkt waardoor er bijvoorbeeld één keer per 2 weken of maand  functionaliteit naar productie wordt gebracht.

Fase 5: Optimizing
In de laatste fase van volwassenheid zijn de teams Cross functional. Dit betekent dat iedereen in het team naast zijn of haar eigen aandachtsgebied ook een of meerdere andere taken kan uitvoeren. De developer kan bijvoorbeeld testen en documenteren, de tester kan documenteren en User stories schrijven en beheren. Nieuwe functionaliteit wordt zo snel mogelijk naar productie gebracht. Als het klaar is wordt het gereleased, er wordt niet gewacht op een vaste dag of tijdstip. Er is ook geen roll back scenario, productie problemen worden direct opgelost.

Aanpak

Wat is nu de aanpak wanneer je als organisatie de stap wil maken naar bijvoorbeeld Continuous Integration of zelfs Continuous Deployment. Belangrijk is om eerst het doel te bepalen, dit doel kan per product verschillen. Er is dus niet één doel voor de gehele organisatie.

Doel
Continuous Deployment is geen doel op zich. Het klinkt als het hoogst haalbare, maar het is goed om te bekijken wat voor jouw organisatie of product het beste past. Als je werkt aan een backoffice systeem dat meerdere jaren stabiel draait en waarbij nieuwe functionaliteiten heel goed planbaar zijn , dan is Continuous Integration al voldoende. Denk hierbij bijvoorbeeld aan salaris berekening systemen die vaak vanuit wet- en regelgeving worden geleid. Heb je een product dat customer facing is in een markt die vaak en snel veranderd,  dan kan het een significant voordeel geven als je direct op veranderende omstandigheden in kunt spelen. Denk bijvoorbeeld aan webwinkels. Continuous Deployment is dan veel belangrijker.

Waar staan we nu
Als je eenmaal weet welk doel je wilt bereiken, breng dan in kaart waar je op dit moment staat. Het Continuous Deployment Maturity Model kan je hierbij helpen.

Planning en uitvoering
Als het doel duidelijk is en je weet waar je op dit moment staat kun je een plan maken om het doel te realiseren. Een deel is relatief eenvoudig, bijvoorbeeld implementatie van een tool. Verandering van cultuur bijvoorbeeld is lastiger en vergt meer tijd. Dit is per organisatie verschillend en er is ook geen eenduidige aanpak.
Definieer een aantal tussenstappen en -resultaten. Als je een volgende stap in het plan heb bereikt, meet dan het resultaat en bekijk of dit aansluit bij de verwachting. Kijk ook opnieuw of de vooraf gedefinieerde stappen nog de juiste zijn en pas indien nodig het plan aan.

Conclusie

Continuous Deployment is niet de heilige graal. Bepaal voor je eigen organisatie of project waar je naartoe wil en welk doel daarbij hoort. Ga vervolgens stap voor stap. Zorg eerst dat je Continuous Integration goed hebt ingebed in de organisatie en ga (indien gewenst) vandaaruit verder. Het is niet een eenvoudige weg, maar het levert wel een groot voordeel op doordat kwaliteit (automatisch testen en frequent uitvoeren) in alle gevallen wordt gerealiseerd. Uiteindelijk is het vele malen goedkoper fouten in de ontwikkelfase op te lossen, dan ze pas in productie te ontdekken.

Hebt u behoefte aan advies of ondersteuning, aarzel dan niet om contact met ons op te nemen via 085 - 487 52 11.

Marcel Groennou, DevOps Consultant / Agile Coach