Continuous Delivery
DevOps gaat primair om het versnellen van software delivery. In de tijd waarin we leven is Time To Market uitermate belangrijk. De wereld om ons heen verandert razendsnel (wie had begin 2020 gedacht dat we minstens twee jaar in een pandemie zouden verkeren?) en software moet net zo snel mee kunnen veranderen.
Één van de manieren waarop in de DevOps gedachte software delivery versneld kan worden is door het automatiseren van het complete software delivery process (Continuous Delivery). Een code wijziging zou zonder handmatige stappen, volledig geautomatiseerd naar de productieomgeving uitgerold moeten kunnen worden.
Voor moderne applicaties die ontwikkeld zijn met deze principes in gedachte, is het relatief eenvoudig om dit soort automation op te zetten. Er is tegenwoordig veel tooling beschikbaar die hierbij helpt. Containerization en Kubernetes maken dit makkelijker dan ooit tevoren.
Mooi, we kunnen het deployment proces technisch gezien dus vrij eenvoudig automatiseren. Maar hoe zorg je ervoor dat de wijzigingen die je op deze manier binnen no-time van development naar productie doorzet ook daadwerkelijk goed zijn? Met deze nieuwe manier van werken wordt het immers óók eenvoudig om bugs binnen no-time op je productieomgeving te krijgen. Niet zo handig :-).
Test automatisering als onderdeel van het development process
Een oplossing voor dit probleem is, geheel in lijn met de automate everything gedachte van DevOps, om het testen van je software te automatiseren. Veel teams passen al Continuous Integration toe, waarbij er bij elke wijziging van de software een aantal automatische checks uitgevoerd worden. Vaak beperkt dit zich echter tot checks op code stijl en code kwaliteit, maar ontbreken tests waarmee de werking van het systeem aangetoond kan worden.
Er zijn verschillende manieren om het testen van software te automatiseren, maar de meest krachtige is naar mijn mening om het geautomatiseerd testen onderdeel te maken van het software development proces. TDD, Test Driven Development, is een practice waarbij developers voor elke wijziging in code óók test code schrijven om aan te tonen dat de functionaliteit werkt. Sterker nog, de test wordt geschreven nog vóórdat er ook maar één regel productie code geschreven wordt. Dit heeft een aantal grote voordelen:
- Het schrijven van tests dwingt je als ontwikkelaar om goed na te denken over de functionaliteit van je code en de verschillende scenario’s die er op kunnen treden. Dit helpt om code robuust te maken en niet alleen het happy path af te vangen.
- Het schrijven van tests stimuleert je als ontwikkelaar om verantwoordelijkheden in code goed te scheiden en je code modulair, loosely coupled, op te zetten. Spaghetti code (code met veel afhankelijkheden, weinig structuur) is erg lastig te testen. Wanneer je als regel hanteert dat elke wijziging automatische tests heeft dan wordt het schrijven van tests pijnlijk als je productie code niet goed in elkaar zit. De tests vormen zo dus een graadmeter voor de kwaliteit van je code.
- De tests die je schrijft dienen als documentatie van je software code. Op basis van de tests kun je exact zien waarvoor de software ontworpen is.
- Doordat alle code in de software voorzien is van automatische tests kun je bij elke wijziging geautomatiseerd verifiëren dat alle bestaande functionaliteit nog steeds naar behoren werkt.
Snelheid in delivery door vertrouwen in wijzigingen
Het laatste punt is waar het uiteindelijk om gaat. Door de automatische tests kun je met vertrouwen wijzigingen maken aan de software. Als er door wijzigingen per abuis bestaande functionaliteit niet meer werkt (regressie) dan gaan er tests falen en wordt de deployment pipeline vanzelf gestopt. De wijziging zal daardoor niet naar productie gedeployed worden, totdat de functionaliteit weer werkt en de test weer slaagt.
De waarde hiervan is werkelijk enorm. Zowel direct – eindgebruikers krijgen geen niet of slecht werkende software voor hun kiezen, als indirect: de automatische tests geven het ontwikkelteam het vertrouwen om wijzigingen te maken.
Onderhoudbaarheid
Moderne software is onderhevig aan constante verandering. Requirements veranderen voortdurend en kunnen ervoor zorgen dat grote wijzigingen aan de structuur van de code nodig zijn. Om snel te kunnen ontwikkelen en om software onderhoudbaar te houden is hergebruik van code cruciaal. Dit betekent dus per definitie dat je voor het toevoegen van nieuwe functionaliteit óók de code van bestaande functionaliteit moet wijzigen. In software waarbij er géén of weinig automatische tests zijn worden dit soort wijzigingen meestal niet gedaan, omdat men bang is bestaande functionaliteit kapot te maken. Het gevolg hiervan is dat de software ontwikkeling steeds langzamer gaat en dat de kans op regressie significant toeneemt.
Hoe ga je zonder automatische tests überhaupt merken dat je software niet meer werkt zoals het hoort? Precies, dat gaan je eindgebruikers je vertellen (niet fijn) óf je gaat veel handmatig testwerk moeten doen. Dit laatste is nu net wat je wil voorkomen. DevOps gaat immers om snelheid.
DevOps + test automatisering = 
.
