Inleiding

Het is 7 uur ‘s ochtends als ik inlog op IRC. In de chatroom zijn Linda en Stefan reeds aanwezig. ‘Zal ik starten?’ vraagt Stefan. ‘Doe maar’, zegt Linda. Stefan drukt op de Build-knop in Jenkins en de release, die ik gister had klaargezet, wordt geïnstalleerd op de productieomgeving. Vijf minuten later is het gebeurd. We controleren ieder nog even of er geen problemen zijn. Kwart over 7 zit ik aan mijn ontbijt. Over een uur gebruiken de eerste scholieren de nieuwe release.

Het ambacht van softwareontwikkeling is voor buitenstaanders nog met veel mysterie en onzekerheid omgeven. Het gevoel is dat deze projecten altijd uitlopen, meer kosten en minder (functionaliteit) opleveren. De initiële reactie op deze onzekerheid was steeds verder uitgewerkte stapsgewijze projectaanpakken, veelal aangeduid met termen als ‘watervalmethode’ of ‘V-model’. Het laatste decennium blijken echter vrijere agile-aanpakken in veel gevallen succesvoller ([Koed14b]). Andere aspecten die bijdragen aan het verder optimaliseren van de softwareontwikkeling zijn (zoals ook buiten de IT) verdergaande automatisering van de processen en (keten)integratie van betrokken afdelingen, in dit specifieke geval bekend onder de naam DevOps.

In dit artikel worden de voordelen van automatisering en DevOps voor de uitkomsten van softwareontwikkeling in kaart gebracht aan de hand van een sprekend praktijkvoorbeeld: Wikiwijs Maken. Stichting Kennisnet en KPMG Advisory N.V. ontwikkelen sinds 2010 samen Wikiwijs Maken. Wikiwijs Maken is een webapplicatie waarmee docenten digitaal lesmateriaal kunnen maken voor het Nederlandse onderwijs. In 2015 zijn er iets minder dan 1,9 miljoen lessen gevolgd via het Wikiwijs Maken-platform. Prognoses voor 2016 gaan uit van een groei van minimaal 600.000 lessen.

Stichting Kennisnet en KPMG hebben de afgelopen jaren veel nieuwe functionaliteiten toegevoegd aan Wikiwijs Maken, waaronder het maken van interactieve toetsen en de mogelijkheid om educatieve content uit te wisselen met publieke en private systemen. Gebruik van Creative Commons-licenties en export naar verschillende formaten zorgt ervoor dat Wikiwijs Maken dient als content-hub voor vrije leermiddelen en hiermee een unieke rol vervult in de Open Educational Content-strategie ([OCW12], [SURF]) van de Nederlandse overheid.

In dit artikel beschrijven we de uitdagingen bij het releasen van grote hoeveelheden kleine en grote functionaliteiten en de oplossingen die we hebben toegepast in het Wikiwijs Maken-project.

De waarde van software

Zolang software nog niet gebruikt kan worden, heeft het kostbare ontwikkelproces dat eraan voorafging nog niets van waarde opgeleverd. Toch komt het veelvuldig voor dat het weken of zelfs maanden duurt voordat software het daglicht ziet en in gebruik wordt genomen.

Door de toepassing van agile-methoden in het softwareontwikkelproces kunnen ontwikkelteams tegenwoordig met hoge regelmaat nieuwe (versies van) functionaliteit in software opleveren. Maandelijks, of zelfs wekelijks, extra functies leveren is geen uitzondering meer. Zelfs het produceren van meerdere nieuwe versies per dag wordt steeds gewoner. Het is echter minder gebruikelijk dat al deze versies snel na oplevering het daglicht zien: ze worden niet direct maar pas veel later gereleaset. Hiermee laten organisaties potentieel vanuit softwareontwikkeling beschikbare waarde liggen (zie bijvoorbeeld [Koed14a]).

Figuur 1. Stabiliteit door frequente releasemomenten.

Waarom releasen we niet vaker?

Softwarereleases zijn een van de meest voorkomende oorzaken van instabiliteit. Juist rond de release van nieuwe of vernieuwde software gaat het vaakst een IT-systeem stuk. Los van het feit dat downtime vervelend is, kost downtime ook geld. Deze nadelige gevolgen wil men daarom graag vermijden.

Het is dan ook niet zo vreemd dat het organisatieonderdeel dat doorgaans verantwoordelijk is voor het releasen en beheren van software, IT Operations, zo min mogelijk software wil releasen. Uitgebreide en ingewikkelde gestandaardiseerde processen, ontleend aan methoden als ITIL, zijn erop gericht om controle en stabiliteit in het releaseproces te krijgen. Deze processen nemen daardoor veel tijd en kennen veel betrokkenen – ook in de business waar de wijzigingen moeten worden goedgekeurd. Geen wonder dat deze ook kostbare processen het liefst zo weinig mogelijk worden uitgevoerd.

Ondertussen is er vanuit de business vaak veel vraag naar verandering in software. Software moet sneller, makkelijker of mobiel worden, of voldoen aan de steeds veranderende wetgeving. De wereld verandert en de software kan niet achterblijven. In de directe omgeving van bedrijven blijken applicaties die executives gebruiken, zoals Facebook, Spotify, Amazon en Google, zich wel snel aan te passen aan veranderende omstandigheden. Deze applicaties worden ontwikkeld met flexibele en lichtgewicht agile-methodieken zoals Scrum en deze organisaties volgen de principes uit het Agile Manifesto ([Agil01]) om verandering te lijf te kunnen gaan.

Het Agile Manifesto onderschrijft het nut van plannen en processen, maar plaatst de noodzaak tot verandering en het dienen van de organisatie en zijn mensen hierboven. Zo waardeert de Spotify-engineeringcultuur vrije uitwisseling van ideeën en oplossingen hoger dan standaardisatie en processen met als doel een gezonde balans te vinden tussen consistentie en flexibiliteit. Constante evaluatie en terugkoppeling over de prestaties zorgen ervoor dat applicaties iteratief kunnen evolueren en er geëxperimenteerd kan worden met verschillende oplossingsrichtingen.

Ook het onderwijslandschap is continu in verandering. De manier waarop software wordt toegepast in de klas is in de afgelopen jaren veel veranderd. Dit is goed zichtbaar in de evolutie van Wikiwijs Maken (zie tabel 1).

Tabel 1. Nieuwe Wikiwijs Maken-functionaliteit door de jaren heen.

Om de veranderingen voor te blijven wordt Wikiwijs Maken ontwikkeld via de Scrum-methodiek met iteraties van twee weken. Elke twee weken is er nieuwe functionaliteit die in gebruik genomen kan worden. Omdat de productieomgevingen in de praktijk niet door Stichting Kennisnet of KPMG worden beheerd, is een derde beheerpartij verantwoordelijk voor de stabiliteit van de productieomgeving en het uitvoeren van veranderingen in deze omgeving.

De consequenties van een foute release zijn enorm voor het onderwijs. Downtime tijdens lesuren heeft tot gevolg dat het onderwijsproces vastloopt en juist voor Kennisnet is het belangrijk om aan te tonen dat de inzet van ICT betrouwbaar waarde kan toevoegen aan het onderwijsproces. Daarom is het releasen van software een kwestie die zorgvuldig moet worden aangepakt, zeker als het eens in de twee weken plaatsvindt.

Ondanks het feit dat het ontwikkelteam voor Wikiwijs Maken elke twee weken een nieuwe versie kon opleveren, werden deze versies niet na oplevering naar productie gebracht. Het was niet ongebruikelijk dat meerdere versies werden opgespaard om deze in één keer naar productie te brengen. De belangrijkste reden hiervoor was de grote hoeveelheid handmatige handelingen binnen het releaseproces en de hoeveel tijd die besteed werd aan het valideren van de juistheid van een release.

Automatiseren

De belangrijkste voorwaarde voor het snel produceren en releasen van software is dat het proces geautomatiseerd is. Het is een monotoon proces en vergt het herhaaldelijk uitvoeren van dezelfde handelingen voor elke nieuwe versie, steeds weer op elke omgeving waarop de versie geïnstalleerd moet worden. De eentonigheid maakt dat kleine veranderingen in de procedure makkelijk vergeten of over het hoofd worden gezien, waardoor het risico op fouten toeneemt. Gelukkig zijn de handelingen bij uitstek geschikt om te automatiseren: duidelijk gedefinieerd en repetitief.

Vanaf midden jaren negentig wordt al automatisering toegepast bij het ontwikkelen van software. Continuous Integration (het automatisch integreren, testen en installeren van software op een testserver) werd toen geïntroduceerd door Grady Booch ([Booc94]). In Continuous Integration worden de wijzigingen van verschillende teamleden (en/of verschillende teams) automatisch met elkaar geïntegreerd. Snelle automatische tests controleren vervolgens of de wijzigingen en de integratie ervan het gewenste resultaat hebben. Inmiddels is Continuous Integration een veel toegepaste best practice bij het ontwikkelen van software die niet alleen ontwikkelteams in staat stelt om meerdere malen per dag een versie van de software voort te brengen, maar ook een kwaliteitsmaatregel is die zorgt voor de efficiënte ontwikkeling van kwalitatief betere software.

Lange tijd is het automatiseren van het voortbrengingsproces beperkt gebleven tot de werkzaamheden van de ontwikkelteams. Inmiddels wordt ook binnen het gebied van IT Operations ingezien dat automatisering noodzakelijk is om aan de vraag vanuit de organisatie te blijven voldoen. In eerste instantie gaat het hierbij vaak om veelvoorkomende handelingen door de servicedesk, zoals het beheren van gebruikers en het opnieuw instellen van wachtwoorden.

Toch zijn er ook handelingen die vaak niet geautomatiseerd zijn. Dit betreft meestal het doorvoeren van wijzigingen in het besturingssysteem van de omgeving of het wijzigen van de database. Deze handelingen zijn slechts een enkele keer nodig en brengen hogere risico’s met zich mee. Ook vergen ze specialistische kennis van degene die de handelingen uitvoert. Vaak gaat het om wijzigingen die ontworpen worden door het ontwikkelteam, maar moeten worden toegepast door IT Operations.

Kloof

Om het gehele proces (van ontwikkeling tot naar productie brengen) te automatiseren moeten de verschillende verantwoordelijke organisatieonderdelen veel meer samenwerken dan gebruikelijk is binnen organisaties. De ontwikkel- en operations-onderdelen moeten begrip hebben voor elkaars verantwoordelijkheden en zich verantwoordelijk voelen voor het algehele succes van het product.

Er bestaat in veel organisaties een kloof tussen IT Operations en Softwareontwikkeling. Een verklaring hiervoor zijn de tegenstrijdige verantwoordelijkheden van de twee organisaties: de een is verantwoordelijk voor een stabiele (zonder verandering) productieomgeving, de ander voor het in hoog tempo ontwikkelen van de broodnodige veranderingen in de software.

De kloof kan een negatief effect hebben op het verantwoordelijkheidsgevoel van ontwikkelteams. In plaats van zich verantwoordelijk te voelen voor het succesvol in gebruik nemen van de software (de enige rechtvaardiging van het bestaan van de software), houdt de verantwoordelijkheid van het ontwikkelteam op wanneer de software overgedragen is aan IT Operations. De kloof vergroot op zijn beurt ook het wantrouwen van IT Operations richting het ontwikkelteam. Bij elke mislukte release is de kans groot dat de kloof verder wordt vergroot.

DevOps

DevOps is een beweging naar een intensieve samenwerking tussen Softwareontwikkeling en IT Operations in combinatie met het toepassen van vergaande automatisering. Dit om tot een hoog releasetempo te komen. Het veranderen van een organisatie naar het toepassen van DevOps (een samenvoeging van ‘Developers’ en ‘Operations’) vergt naast vergaande automatisering ook een prestatiegerichte bedrijfscultuur: een cultuur waarin samenwerking en het uiteindelijke resultaat centraal staan.

Tegelijk met de opkomst van cloudinfrastructuren zijn er meerdere oplossingen ontstaan voor het volledig geautomatiseerd inrichten van deze infrastructuur zoals virtuele netwerken, servers en clusters. Software zoals Puppet, Chef of Ansible kan groepen servers automatisch installeren en configureren aan de hand van configuratiescripts. Deze scripts worden geschreven door de ontwikkelaars van de software en de beheerders van de servers, en worden zodanig opgebouwd dat ze te gebruiken zijn voor alle omgevingen die geconfigureerd moeten worden: test-, acceptatie- en productieomgevingen. Doordat dezelfde configuratie wordt gebruikt voor elke omgeving, worden installatiehandelingen en de configuratie veelvuldig getest. Hierdoor worden veel problemen vroegtijdig gesignaleerd voordat ze in de productieomgeving terechtkomen.

Bij Wikiwijs Maken paste het ontwikkelteam Continuous Integration toe en werden softwarebundels automatisch geproduceerd. De beheerpartij had op haar beurt delen van de installatie geautomatiseerd. Toch leidde deze automatisering niet tot een grote verbetering in de regelmaat van softwarereleases.

De reden hiervoor was de overdracht van de (automatisch geproduceerde) softwarebundel aan de beheerpartij. Bij deze overdracht worden de wijzigingen in de software doorgegeven, en ook de eisen waar de omgeving aan moet voldoen en de handelingen die nodig zijn voor het installeren van de software. Deze informatie werd aangeleverd in de vorm van een installatiehandleiding. Met behulp van deze handleiding paste de beheerpartij vervolgens de omgevingen en eventuele automatisering aan, om vervolgens een release uit te voeren. Onzorgvuldigheden bij het schrijven of lezen van de handleiding leidden regelmatig tot mislukte releases.

Om de kloof tussen de ontwikkel- en beheerafdelingen te overbruggen hebben Stichting Kennisnet, KPMG en de beheerpartij stapsgewijs het installatieproces geautomatiseerd. De eerste stap was het vervangen van de handmatige handelingen die beschreven stonden in de installatiehandleiding. Deze werden vervangen door scripts die gebruikt konden worden door de al aanwezige automatisering van de beheerorganisatie. Hierdoor werden de complexere maar toch veelvoorkomende handelingen zoals databasewijzigingen minder foutgevoelig.

De volgende stap was het ontwikkelen van een script dat de totale release van Wikiwijs Maken automatisch kon uitvoeren. Dit script voert de handelingen voor een installatie van de software uit, inclusief het uitvoeren van controles voor de installatie en het maken van back-ups. Er is rekening gehouden met zowel de wens tot verandering als de wens tot stabiliteit van het systeem.

Het releasescript wordt in het Continuous Integration-proces gebruikt om elke versie die ontwikkeld wordt te installeren in de testomgeving. Automatische en handmatige tests controleren vervolgens of de nieuwe functionaliteit werkt en of er geen regressie is opgetreden. De releaseprocedure wordt hierdoor meerdere malen per dag doorlopen, waardoor eventuele problemen snel gevonden worden.

Omdat het installatiescript door de ontwikkel- en beheerpartijen samen werd ontwikkeld, legde dit de verschillende specialismen van de beide partijen bloot. Zo is de ontwikkelpartij het beste op de hoogte van de werking en benodigdheden van de applicatie, maar heeft de beheerpartij meer kennis in huis over bijvoorbeeld het monitoren of het ‘hardenen’ (veilig inrichten) van de serverinfrastructuur. Door intensiever samen te werken bleek men beter in staat een stabiele applicatie te ontwikkelen zonder verandering in de weg te staan.

Software is niet per definitie geschikt om automatisch te testen en releasen. Wikiwijs Maken is gebaseerd op code uit 2008 en is in die tijd niet geschikt gemaakt voor Continuous Integration, en zeker niet voor de volledige automatisering van het voortbrengingsproces. De applicatie is daarom de afgelopen jaren niet alleen met nieuwe functionaliteit uitgebreid, maar tevens geschikt gemaakt voor automatisch installeren en testen. De manier waarop de database en de applicatie werden geconfigureerd is geleidelijk maar sterk aangepast.

Wikiwijs Maken maakt gebruik van een combinatie van (automatische) unit- en integratietests. Integratietests worden uitgevoerd op een volledig geconfigureerde installatie van de applicatie. Om het mogelijk te maken snel verschillende testscenario’s te doorlopen heeft KPMG functionaliteit gemaakt om testdata te genereren. Met deze functionaliteit wordt in een oogwenk een nieuw scenario klaargezet in de applicatie, waarna de handelingen van een gebruiker worden gesimuleerd om een zo realistisch mogelijke test uit te kunnen voeren. Doordat ze in staat zijn snel test- (en ontwikkel)omgevingen op te bouwen, te vernietigen en opnieuw op te bouwen, kunnen ontwikkelaars snel verschillende features (her)tesen.

Databasewijzigingen worden in Wikiwijs Maken in kleine, automatisch toe te passen bundels (zogenaamde migraties of changesets) gedefinieerd. Doordat van elke bundel is opgeslagen of deze al is uitgevoerd, kan het installatiescript berekenen welke wijzigingen nog niet zijn toegepast op de omgeving en deze vervolgens toepassen. Hierdoor is het niet meer nodig om handmatig de benodigde wijzigingen te aggregeren voor de verschillende omgevingen.

Conclusie

We weten al ruim twintig jaar dat het toepassen van automatisering bij het voortbrengen van software verstandig of zelfs noodzakelijk is. Desondanks worden er pas sinds kort weer grote stappen gemaakt in het automatiseren van het gehele proces. Dit is vooral te danken aan de verhoogde effectiviteit van de ontwikkelteams en de popularisatie van het begrip DevOps.

Het automatiseren en stroomlijnen van het releaseproces van Wikiwijs Maken heeft ervoor gezorgd dat Stichting Kennisnet en KPMG in de afgelopen jaren in hoog tempo grote aantallen technische en functionele veranderingen konden maken. Bij nieuwe applicaties die Stichting Kennisnet met KPMG ontwikkelt, wordt al in een vroeg stadium rekening gehouden met automatisch testen, installeren en configureren. Hierbij worden de lessen die geleerd zijn bij het automatiseren van Wikiwijs Maken toegepast:

• Richt de ontwikkel-, test- en acceptatie-infrastructuur zo veel mogelijk in gelijk aan de productie-infrastructuur. Doe dit in een vroeg stadium van het project.
• Installeer de applicatie op alle omgevingen automatisch en via hetzelfde proces. Hierdoor wordt de installatieprocedure vanaf het allereerste moment getest.
• Zorg ervoor dat ontwikkel- en beheerafdelingen nauw samenwerken en inzicht hebben in elkaars werkzaamheden. Zo wordt er vanaf het begin van het project rekening gehouden met de verantwoordelijkheden van de verschillende afdelingen. Hoewel het samenbrengen van verschillende disciplines in één team hierbij kan helpen, moet men niet de waarde van de verschillende specialismen (ontwikkeling en operations) onderschatten.
• Voorkom zo veel mogelijk dat misgelopen installatieprocedures invloed hebben op de live applicatie. Detecteer problemen snel en stop de installatieprocedure vroeg.
• Zorg ervoor dat ook de herstelprocedures (back-up en roll-back) geautomatiseerd zijn.
• Ontwerp applicaties zo dat de verschillende onderdelen van de applicatie afzonderlijk te testen zijn. Hierdoor kunnen grote delen van de applicatie snel en automatisch getest worden, voordat de tijdrovende integratie- en gebruikerstests worden uitgevoerd.
• Zorg ervoor dat je automatisch nieuwe omgevingen met testdata voor diverse scenario’s kunt genereren. Dit maakt het makkelijker om veelvuldig (automatisch) integratietests uit te voeren met behulp van tooling zoals Selenium.

In de toekomst zal een nog bredere toepassing van automatisering en verbeterde architectuur het mogelijk maken om op simpele wijze zonder enige geplande verstoring releases uit te voeren. Gecombineerd met een brede testdekking wordt het dan mogelijk om veilig meerdere releases per week, of zelfs per dag, uit te voeren.

Met het voorbeeld van Wikiwijs Maken tonen Kennisnet en KPMG aan dat de voordelen van DevOps, namelijk sneller de waarde van softwareontwikkeling benutten met significant lagere risico’s op verstoringen door het releaseproces, daadwerkelijk kunnen worden bereikt. Door hun goede ervaringen te delen hopen ze andere organisaties te inspireren om hun voorbeeld te volgen!