Iedere commit geautomatiseerd getest. Elke succesvolle test automatisch geïnstalleerd op de productieomgeving. Deployment scripts die automatisch terugdraaien als een installatie fout gaat. Eén commando om elke OTAP-server op dezelfde manier in te richten en te upgraden. En: metrieken waarmee het succes van het project realtime zichtbaar is voor het hele team. Kortom ‘continuous deployment’ als ideaal!
Continuous deployment lijkt soms een onhaalbaar doel, dat door teamleden wordt gepareerd met excuses. Er zijn altijd wel redenen waarom het in een specifieke situatie niet kan werken. Vaak zijn de aarzelingen ook valide, omdat je niet van de ene op de andere dag alles kunt veranderen. Mijn ervaring is echter, dat je met een aantal kleine verbeteringen al in de buurt kunt komen van continuous deployment.
In deze tekst geef ik een aantal uitvluchten die je zou kunnen horen als je continuous deployment wilt realiseren bij een project. Ik gebruik daarbij weliswaar de scrum terminologie, maar de meeste opmerkingen gelden ook voor andere methodes!
Make It Happen
“Elke commit op de repository volledig automatisch naar productie opleveren, dat kan op mijn project niet.”
Een snelle stroom van nieuwe features naar productie is voor veel projecten iets waarvan ontwikkelaars slechts kunnen dromen. Op elk project zijn er zeer waarschijnlijk processen die meerdere malen handmatig worden uitgevoerd. Hoeveel sneller en betrouwbaarder zou je software op kunnen leveren als deze taken bij elke oplevering automatisch verliepen?
Begin met iets eenvoudigs. Bijvoorbeeld een script dat kan controleren of de applicatie correct is gestart. Een dergelijk script kan een hoop frustratie voorkomen voor iemand die de software wil gaan testen of accepteren. Het geeft het team ook meer zekerheid over de kwaliteit van de oplevering. Het is iets eenvoudigs, maar het is toch weer een stapje dichter bij continious deployment. Om Bruce Lee te quoten “A goal is not always meant to be reached, it often serves simply as something to aim at”.
Work smarter, not harder
“Maar de product owner wil geen toevoeging in de sprint voor continuous deployment.”
De product owner bepaalt de functionaliteit en de volgorde waarin die functionaliteit moet worden gebouwd. Het team is verantwoordelijk voor de kwaliteit en de snelheid waarmee de software wordt opgeleverd. Een geautomatiseerde acceptatietest (of een uitbreiding van een bestaande test) hoort gewoon bij het opleveren van een user story. Als je een nieuwe keuken koopt, dan verwacht je toch ook dat daar garantie op zit?
Geautomatiseerd naar productie vereist veel controles op alle niveaus. Als er ook maar iets mis is verwacht je dat de deployment scripts of de geautomatiseerde tests zo snel mogelijk een failure laten zien. Een failure vraagt om een oplossing.
Als de build pipeline op rood staat vanwege een onbetrouwbare test, dan is dát het moment voor de oplossing. En kijk niet naar je collega als de build pipeline op rood springt, hij heeft het net zo druk als jij!
Fast delivery
“De product owner wil altijd aan het einde van de sprint alles anders terwijl we voldoen aan de acceptatiecriteria.”
De product owner weet precies wat hij niet wil, op het moment dat hij het resultaat ziet. Als alle stories aan het einde van de sprint af zijn, dan geeft het de product owner weinig tijd om feedback te geven. Kleine user stories zorgen ervoor dat je tussentijds al dingen kunt laten zien. Wat is nu fijner dan halverwege de sprint al feedback te krijgen op de stories die al ‘done’ zijn?
Zorg er dus voor dat elke wijziging die je doet direct ergens zichtbaar en testbaar is voor de product owner. Op die manier krijgt die ook invloed op het verloop van de sprint. Vaak kost het wijzigen van iets kleins tijdens de sprint helemaal niet veel moeite. En als iets wel veel moeite kost, dan wordt direct zichtbaar dat de product backlog wijzigt.
Responsible delivery
“De product owner is niet beschikbaar om stories te accepteren.”
Het is de verantwoordelijkheid van de developer om er alles aan te doen opdat de user stories kunnen worden geaccepteerd. Als het goed is, kent de product owner het product zo goed dat hij/zij in staat is om zelf de applicatie te doorlopen en te testen. Face to face werkt het beste, maar als de product owner even niet beschikbaar is kun je een notificatie sturen zodat hij/zij kan accepteren wanneer dat uitkomt. Er zijn toch heldere acceptatiecriteria opgesteld?
Mensen gaan anders reageren op het moment dat bepaalde signalen zichtbaar en transparant zijn. Een product owner accepteert sneller op het moment dat iedereen kan zien hoe lang het duurt voordat een story is geaccepteerd. Je kunt bijvoorbeeld afspreken dat een user story moet worden geaccepteerd binnen twee dagen nadat de notificatie is gestuurd. Hiervoor geldt natuurlijk wel dat gedurende die twee dagen ook een testomgeving met de nieuwe user story beschikbaar moet zijn.
No shortcuts
“Het opleveren van een script voor het aanmaken van een queue is toch geen onderdeel van de story?”
Natuurlijk is dat onderdeel van de story! Dat er ‘developer’ in je functietitel staat, betekent niet dat je geen infrastructuurtaken mag uitvoeren. Hoe kan de applicatie anders automatisch op een testomgeving worden geïnstalleerd? En als dat betekent, dat je iemand uit een ander team nodig hebt, roep hem er dan bij. Of beter nog, ga naast hem zitten.
De product owner wil werkende software zien. Op een discussie over welke discipline het werk nog niet af heeft zit niemand op te wachten. Werkende software is hoe we voortgang meten. Daarbij moet je als team een geïntegreerde applicatie opleveren. Als de user stories daardoor groot worden, kun je proberen de stories functioneel te splitsen. Het is altijd beter om een zogenaamde ‘tracer bullet’ door alle lagen van de applicatie te sturen, dan een halffabricaat op te leveren.
Open Source
“We moeten een business case maken voor de aankoop van deze DevOps tool.”
Dat is onzin. Het ontwikkelteam is niet het enige team in de wereld dat probeert om sneller geautomatiseerd naar productie op te leveren. Er zijn open source projecten die veel meer contributors hebben dan de commerciële tegenhangers. Puppet heeft bijvoorbeeld op het moment van schrijven 250+ contributors en Docker heeft 300+ contributors.
De tool die je kiest is minder belangrijk dan de cultuur van het project. Dev- en Ops-engineers vinden uiteindelijk wel een manier om sneller en betrouwbaarder op te leveren. Het is belangrijker om een tool te kiezen waarmee de engineers beter kunnen samenwerken. Dit zorgt voor synergie bij het automatisch installeren van een nieuwe test- of productieomgeving.
Done is Done
“We gebruiken onze Definition of Done niet omdat hij bestaat uit 10 A4tjes met lappen tekst.”
In een ideale situatie is een story done als alle geautomatiseerde testen slagen en de feature toggle in productie wordt aangezet. Hoe dichter de Definition of Done daarbij in de buurt komt, hoe beter. Als je nooit naar de Definition of Done kijkt of als je hem nooit haalt, probeer dan eens de tien belangrijkste punten op een half A4-tje op te schrijven. En als je nu al weet dat je die tien punten niet gaat halen, maak er dan vijf van. Als iedereen het eens is over die punten print ze dan en hang ze op. En zorg er voor dat zoveel mogelijk punten automatisch worden gecontroleerd.
Waarom zou je pas helemaal aan het einde van de sprint naar Sonar violations gaan kijken? Meestal is er dan geen tijd meer voor een goede oplossing. Het is veel eerlijker en eenvoudiger als de build pipeline faalt op het moment dat iemand een Sonar violation incheckt. Je kunt dan direct jouw collega op de Definition of Done aanspreken. En als je te veel violations hebt, verlaag dan eerst de norm en laat vervolgens de build falen. Je kunt niet alles in één keer oplossen.
Herken jij een van deze excuses? Of loop jij tegen hele andere problemen aan? En hoe gaat jouw project om met die problemen?
Rino Kadijk, Senior Software Engineer bij Salves Development
References:
http://www.startuplessonslearned.com/2009/06/why-continuous-deployment.html
https://www.informit.com/articles/article.aspx?p=1621865
http://www.martinfowler.com/articles/continuousIntegration.html
http://blog.hendrikbeck.com/2013/01/14/making-continuous-delivery-work-with-scrum-and-sprints/
https://alankent.wordpress.com/2014/03/01/continuous-delivery-with-maven/
https://www.youtube.com/watch?v=X9ap-zH0Gkc
