Hoe gaaf is het als je je software volledig pijnloos in productie brengt zonder kans op installatiefouten door handmatige acties? En zou het niet nuttig zijn als je een nieuwe functie gedurende een korte periode kunt testen bij een kleine doelgroep, om die functie op elk gewenst moment weer uit te schakelen?
Kun je je voorstellen dat dit met een enkele druk op de knop kan? En dat beheerders samen met de ontwikkelaars optrekken om dit voor elkaar te krijgen? Het zal niet makkelijk zijn, maar het is echt mogelijk. Kijk maar naar bedrijven als Facebook, Twitter en Github. Die doen dit al jaren. Sterker nog, het nastreven van zo’n manier van werken kan een complete cultuurverandering met zich meebrengen, die traditionele organisatorische silo’s doorbreekt.
Continuous wat?
Deze manier van ontwikkelen heet continuous delivery. Wat is dat nou eigenlijk? Er zijn eigenlijk twee termen in de omloop; continuous delivery en continuous deployment. Volgens mijn definitie is continuous delivery een verzamelterm voor een aantal methodieken, principes en tools die het mogelijk maken om een stuk software of een systeem met één druk op de knop op te kunnen leveren. Zonder dat daar handmatige acties bij komen kijken.
Normaal gesproken heb je bij een oplevering te maken met zaken als (handmatig) testen, versienummers bepalen, de juiste bestanden verzamelen, instellingen aanpassen en deze op te leveren als een zip-bestand. Als het systeem een database nodig heeft, dan is het vaak ook nog zaak om de update van (een kopie van) de productiedatabase te testen.
Continuous deployment: een stapje verder
Als je dit allemaal goed voor elkaar hebt, dan zou het voor de beheerders voldoende moeten zijn om het ingepakte bestand uit te pakken, de infrastructuurafhankelijke instellingen op de juiste plek te zetten en de database scripts te draaien. Hoewel die laatste zaken nog te overzien zijn, zijn dit eveneens handmatige en dus foutgevoelige stappen. Continuous deployment gaat nog een stap verder en heeft als doel om het volledige proces van codewijziging tot het in productie brengen van de software te automatiseren. En mocht er toch een probleem zijn met de wijziging, dan kan ook het terugdraaien van de productieomgeving naar een vorige versie volledig geautomatiseerd verlopen.
Waarom zou je dit doen?
Continuous werken doe je om je software zo snel en zo pijnloos mogelijk in productie te krijgen, zónder de kwaliteit in gevaar te brengen. En dat lukt organisaties nu vaak nog niet. Wellicht omdat er nog een organisatorische scheiding bestaat tussen de afdeling die de software ontwikkelt en de afdeling die verantwoordelijk is voor het in productie brengen en beheren van die omgeving. Daar ontbreekt het nog wel eens aan vertrouwen in elkaars kunnen.
Continuous delivery kan dat patroon doorbreken door de mensen uit de afdelingen een stimulans te geven om samen te werken aan een gezamenlijk doel. Zo kunnen testers hun kennis en ervaring gebruiken om het systeem meer geautomatiseerd testbaar te maken in plaats van saai en repetitief handmatige testwerk uit te voeren. En het uitrolproces kan een stuk gestroomlijnder als je softwareontwikkelaars zich ermee gaan bemoeien. Immers, ontwikkelaars hebben over het algemeen een hekel aan dingen twee keer doen.
Technieken
Zoals ik al eerder aangaf, is continuous delivery de eerste stap naar continuous deployment. Een zelfde soort onderscheid kun je maken in de methodieken en technieken die nodig zijn. Om met continuous delivery te beginnen bijvoorbeeld, zul je een veelvoud aan werkwijzen moeten introduceren.
Testen? Dat moet automatisch!
Zoveel mogelijk van de productiecode moet je dekken door geautomatiseerde tests, ook wel unit tests genoemd. Het is daarbij belangrijk om de juiste scope (unit) van testen te kiezen. Test Driven Development, een ontwerp- en ontwikkeltechniek die het bouwen van testbare software enorm stimuleert, kan je daarbij helpen. Het is geen vereiste, maar uit eigen ervaring weet ik dat het achteraf toevoegen van geautomatiseerde tests heel moeilijk is.
Als het systeem bestaat uit meerdere onderdelen die normaal gesproken alleen na de uitrol samen getest kunnen worden, dan zijn acceptatietesten geen overbodige luxe. Deze zogenaamde end-to-end tests raken één van die onderdelen en gebruiken dummies om de overige componenten te simuleren.
Handmatig testen zou je sowieso moeten verbannen. Uiteraard is dat in de praktijk niet altijd mogelijk, maar breng dan in ieder geval in kaart waarom dat niet kan. En wat er voor nodig is om het toch te verwezenlijken.
Versienummers? Niet meer over nadenken!
Een releasestrategie en bijbehorende branchingstrategie zijn cruciaal. Zo’n strategie geeft aan hoe het team om moet gaan met tussentijdse releases, definitieve releases, hot-fixes en het reguliere ontwikkelwerk. Ook zegt het iets over labeling en schema’s voor versienummers.
Modules moet je daarnaast automatisch versioneren. Een ontwikkelaar zou geen handmatige acties meer hoeven uitvoeren om het versienummer op te hogen. Als je Git gebruikt als versiecontrolesysteem zijn er handige tools die, op basis van de branchingstrategie en naamgevingsconventies, automatisch een versienummer genereren.
Uitrollen zonder risico’s
Bij de uitrol moet een beheerder vaak nog handmatige aanpassingen doen aan de instellingen die afhankelijk zijn van de infrastructuur. Denk aan databaseconnectie-informatie, gebruikersnamen en wachtwoorden. Ook dit kun je verbeteren door softwarepakketten te gebruiken die de uitrol van dit soort gegevens en/of instellingen automatiseren.
Het proces waarmee de broncode wordt omgezet naar de definitieve versie van de software is vaak ingericht met een standaardpakket. Maar wat veel ontwikkelaars vergeten, is dat dit proces veelal net zo veranderlijk is als de broncode zelf. Door dit proces onderdeel te maken van de broncode kan het meegroeien met veranderende wensen en eisen. Bijkomend voordeel is dat ontwikkelaars het hele uitrolproces op hun eigen ontwikkel-pc’s kunnen testen. En dat draagt weer bij aan korte feedbackcycli.
Niets is meer vertragend dan een databasespecialist die elke aanpassing aan het databaseschema moet goedkeuren en uitrollen. Ook dit kun je volledig geautomatiseerd uitvoeren. Er zijn softwarebibliotheken zoals Fluent Migrator die eigen metadata toevoegen aan het databaseschema en daarmee exact bepalen wat de verschillen zijn tussen het huidige schema en dat van de nieuwe softwareversie.
Zover over Continuous delivery. Volgende week deel twee van deze reeks, waarin je meer leest over Continuous deployment.
