“Het was een spannende nacht want we hebben net een grote release gepusht” Het is een uitspraak die we vorig jaar bij een Belgisch softwarebedrijf opvingen, maar die tijd is binnenkort voorbij. In de toekomst wordt het harde werk van ontwikkelaars bijna live geïmplementeerd.

Bij continuous deployment wordt je ontwikkelproces zodanig opgezet en geautomatiseerd dat ontwikkelaars veel sneller code naar de eindgebruiker kunnen duwen. In plaats van alle kleine aanpassingen te bundelen, wordt code (vaak automatisch) getest en zodanig modulair gebouwd dat ze meteen inzetbaar is in een productieomgeving. Resultaat : je code gaat sneller de deur uit, je krijgt sneller feedback en je product kan dus sneller verbeterd worden. Een verhaal dat ook past in een cloudomgeving waar je niet langer capaciteit koopt, maar huurt. “Vroeger bouwde je apps met je servers voor de productieomgeving, maar dan moest je op voorhand de capaciteit kunnen inschatten. Vandaag betaal je enkel nog wat je gebruikt voor hoe lang je het nodig hebt”, zegt Carlos Conde, head of Technology Evangelism Emea bij Amazon.

Continuous development ontstond rond 2006-2008 met de opkomst van webapps. Ook in de start-up scene kijkt men er vandaag naar. Hoe sneller je een nieuwe versie kan uitsturen, hoe sneller je product evolueert. Amazon zelf draagt continuous development hoog in het vaandel. Hier wordt gemiddeld elke elf seconden nieuwe code geïmplementeerd.

UNITT, dat Advanced Consulting Partner is van Amazon Web Services, ziet de trend vandaag bij grote bedrijven opduiken. “Bedrijven van enterprise-niveau met een veeleisende business vinden de oude manier niet langer relevant”, zegt Benjamin Jacobs, ceo van UNITT. “Zo had KPMG twee jaar geleden nog een app die over enkele weken werd uitgerold. Vandaag kost dat maar een fractie van die tijd.” Maar ook starters, zeker zij die met mobile en gaming bezig zijn, kijken volgens Jacobs naar de nieuwe methode. “Klanten doen nu tien tot twintig deployments per dag. Ze werken feature-based waar men vroeger eerder naar een grote release toeging. Als klant merk je meestal zelfs niet eens dat de code wordt vervangen want het proces is doorgaans volledig geautomatiseerd. Ook kan je makkelijker AB-testing doen door code enkel op één helft van je servers uit te rollen.”

Conde : “Zo ga je ook meer halen uit je investering. Als je vandaag ontwikkelaars betaalt om code te schrijven, en die code wordt niet meteen in praktijk gebracht, dan verlies je daar geld door. Op dat vlak is het zoals de boekenverkoop van Amazon : hoe langer zo’n boek in het warenhuis bleef liggen, hoe meer geld we er op verloren. Dat is voor software die niet wordt gebruikt (en die dus veroudert of pas later wordt getest door eindgebruikers, nvdr) niet anders.”

De sleutel van continuous deployment is dat alles gestroomlijnd en geautomatiseerd verloopt. Eerst is er continuous integration : daarbij ga je op regelmatige basis een toepassing bouwen en testen. Als nieuwe code hier op fouten botst, nog voor ze in een versie worden opgenomen, dan weet je als developer dat er nog werk aan de winkel is.

Een tweede stap is continuous delivery : In deze fase weet je dat de automatisch gegenereerde builds code bevatten die geen (grote) problemen geven. Die builds kunnen dan meteen naar quality assurance, al gaat het in praktijk om kleinere builds, of exemplaren waar slechts een klein deel moet worden gecontroleerd.

De laatste stap is continuous deployment zelf, waar code die grondig is gecontroleerd in de eerste twee stappen, en dus stabiel is, wordt uitgerold naar eindgebruikers toe. Dat kan wekelijks, dagelijks of zelfs elk half uur afhankelijk van je noden. Maar de sleutel is dat het hele proces tussen het invoeren van de code door de ontwikkelaar en het verwerken voor de finale toepassing zo automatisch mogelijk gebeurt.

Pieterjan Van Leemputten