Recent schreef ik over wat Continuous delivery is en hoe je dit technisch het beste faciliteert. In deze bijdrage ga ik een stapje verder en komt Continuous deployment aan de orde. Ook hier vind je weer meer over de benodigde technologie.
Continous deployment gaat net een stapje verder dan continuous delivery en staat geen enkele handmatige actie meer toe. Elke goedgekeurde broncodewijziging moet in principe in een automatische uitrol resulteren, inclusief automatisch gegenereerde release notes én een bijgewerkt databaseschema.
Maar ook geen enkele vorm van handmatig testen is toegestaan. Sterker nog, zelfs de servers waarop de software draait moeten automatisch ingericht worden. Heb je een bepaalde Windows-patch nodig? Dan is het uitrollen van die patch onderdeel van het bouwproces (en dat is weer onderdeel van de broncode).
Terugdraaien en foutcorrecties
En wat nu als je nu toch een fout in productie vindt? Het systeem dat zorgt voor het automatisch bijwerken van het databaseschema is ook in staat om dat weer terug te draaien (mits de ontwikkelaar daar natuurlijk rekening mee heeft gehouden). Dus ook het terugdraaien van een uitrol is dan niet meer dan een druk op de knop. Vaak is de bug echter vrij snel op te lossen en is het waarschijnlijker dat er gewoon een extra uitrol overheen gaat.
En als je toch al in staat bent om alles automatisch in productie te zetten, is het wellicht ook interessant om een nieuwe functionaliteit in verschillende verschijningsvormen voor een beperkte groep zichtbaar te maken. En te testen welke variant het beste werkt, ook wel A/B-testing genoemd. Mooi idee toch?
Speelt technologie hier nog een rol? Absoluut!
De invloed van technologie mogen we natuurlijk niet onderschatten. Veel van de hierboven geschetste methodieken waren een paar jaar geleden niet eens mogelijk en zijn enorm afhankelijk van moderne technologie. Zowel de software-architectuur als de tools rondom infrastructuur hebben een enorme vlucht genomen. Daarom is het vak van software-architect al lang niet meer zo simpel. Hieronder een greep uit de technologie en tools waar je in ieder geval niet zonder kunt.
Source Control
Git is niet alleen een versiebeheersysteem, maar verandert de manier van werken op een fundamenteel niveau. Veel zaken, zoals het automatisch nummeren van versies, zijn alleen mogelijk met Git. Er zijn zelfs ad-hoc releasestrategieën ontstaan zoals Gitflow en Githubflow die zonder veel werk direct aansluiten bij continuous delivery en continuous deployment. Git hosting services zoals Github en Bitbucket voegen daar nog concepten aan toe als Pull Requests, die de manier hoe teams samenwerken naar grote hoogten brengt.
Geautomatiseerd testen
Xunit is een unit-test-raamwerk dat het bouwen van geparallelliseerde software stimuleert. Niets is zo confronterend als het omzetten van bestaande unit-testen, die bijvoorbeeld met Microsoft’s eigen MSTest zijn gebouwd, naar Xunit. Dit haalt vaak pijnlijke ontwerpproblemen naar boven die normaal gesproken pas in productie aan het licht komen. Bijvoorbeeld als er veel gebruikers tegelijkertijd met het systeem bezig zijn. Door hier al vanaf het begin rekening mee te houden, is de kans een stuk hoger dat het uiteindelijke systeem goed omgaat met grote hoeveelheden gebruikers.
Hoewel je handmatige tests van het systeem moet minimaliseren, door bijvoorbeeld gebruik te maken van Javascript en Jasmine, heb je altijd een aantal zogenaamde smoke tests nodig. Dit zijn geautomatiseerde testen die het systeem in een testomgeving testen om na te gaan of alles nog goed werkt. In dat geval heeft de online service Browserstack in combinatie met het Selenium browser-testraamwerk de voorkeur. Hiermee kun je websites dynamisch testen in verscheidene browsers en platformen.
Build process
Psake is een op Powershell gebaseerd build process dat onderdeel blijft van je broncode en dus mee-evolueert met de rest van het systeem. De grote kracht van Psake is dat gebruikers het complete deploymentproces kunnen testen zonder afhankelijk te zijn van een specifiek build product.
Powershell DSC is een van de vele tools die het mogelijk maakt om ook de infrastructuur vanuit dezelfde broncode te kunnen configureren. Heeft een nieuwe release een andere versie van het .NET Framework nodig? Voeg dan de juiste instellingen toe aan de DSC-scripts en het build process installeert die automatisch.
Het bouwen van complexe software uit kleine onderhoudbare componenten is inmiddels dé manier om dit met vele teams te doen. Myget is een online service gebaseerd op Nuget, waarmee je de bouw van interne componenten stimuleert die allemaal hun eigen releasekalender hebben. Dit is wat mij betreft de ultieme manier om monolithische software (moeilijk te onderhouden en aan te passen software) te voorkomen.
Technologie
Owin is een open standaard waarmee je componenten ontwikkelt die via http communiceren en die je op allerlei manieren kunt hosten. Bijvoorbeeld in een automatische unit test, zonder directe afhankelijkheid van een web server als Microsoft IIS. Het is ook mogelijk om bijvoorbeeld de resistentie tegen netwerkproblemen en/of serveruitval te testen. Zonder überhaupt iets aan het netwerk aan te passen. Netflix doet dit al jaren met hun Chaos Monkey en Latency Monkey tools.
Zover over continuous deployment. Volgende week volgt het laatste deel van deze reeks, waarin je meer leest over de impact van beide methodieken op de organisatie en je met een handig stappenplan zelf aan de slag kunt.
Zie ook het eerder verschenen artikel Continuous delivery: het pijnloze productieproces.
