Continuous delivery: katalysator voor de digitale transformatie

De digitale transformatie. In tegenstelling tot consumenten en eindgebruikers zijn bedrijven en organisaties nog lang niet zo tech-savvy als je zou denken. Ze zitten er middenin. Onderweg naar een bedrijfsmodel met ‘digitaal in het hart’. Met continuous delivery als nieuwe ontwikkelmethode lijken IT-bedrijven de versnelling waar te gaan maken.      

Organisaties veranderen stuk voor stuk in datagedreven softwarebedrijven. Dat heeft te maken met schalen, exponentieel groeien en geen bezit hebben, maar een platform bieden. Denk Uber, Airbnb en Spotify. En snel schakelen. Want de concurrent ligt op de loer. De makers van software moeten dus mee in die transformatie. Continuous delivery is dé manier om snel nieuwe software vanaf de programmeur naar de opdrachtgever uit te rollen. Heel snel. Met slimme technieken die broncode integreren, testen én distribueren.

Kant-en-klare pakketjes

Continuous delivery is het logische gevolg van de overstap die IT-bedrijven maakten van ‘waterval’ naar ‘agile’. Eerst werd ontwikkeld in een vast aantal, vaak bewerkelijke en soms maandenlange, fasen waarbij de opdrachtgever pas aan het eind voor het eerst een werkend product te zien kreeg. Volgens de agile scrum-methode werken ontwikkelteams in sprints die slechts een aantal weken duren en wordt elke vordering met de opdrachtgever gedeeld. De gedachte erachter is dat software ‘leeft’ vanuit de code en niet in één keer bij de opdrachtgever wordt neergegooid.

Continuous delivery past goed in een agile scrum-omgeving omdat gedurende de sprintwijzigingen continu gebouwd, getest en uitgerold worden. Dat uitrollen gebeurt automatisch, van test tot acceptatie, en daarna ook naar de productie-omgeving. Dit stelt de opdrachtgever in staat op de acceptatie-omgeving bijna live de ontwikkeling uit de sprint te volgen.

Continuous delivery wordt nogal eens verward met continuous deployment. Bij continuous deployment gaat elke wijziging aan het product door een ontwikkelstraat en komt automatisch op de live- of productieomgeving te staan. Dit levert extreem korte release-cycles op.

Het verschil met continuous delivery is dat organisaties aanpassingen aan de software frequent kúnnen uitrollen, en dus ook kunnen kiezen om dit (nog) níét te doen. Dan is er ook nog continuous integration, onderdeel van beide methodieken, waarbij tijdens de gehele ontwikkeling van een product de code continu wordt gecontroleerd.

Continuous deployment is het naar de opdrachtgever brengen van het verpakte product en bij continuous delivery zorg je dat je bij elke verandering een verpakt product kunt leveren. Want dat is de voorwaarde voor continuous delivery; alles wat je verandert in de codebase moet een product opleveren dat live gezet kan worden. Een kant-en-klaar pakketje als het ware.

Omslachtig en tijdrovend

Er zitten meerdere kanten aan continuous delivery: een technologische, een organisatorische en een bedrijfsculturele. Het eerste – wat IT in de kern doet – is automatiseren. Dus ook de stapjes van: ontwikkelen, testen met de opdrachtgever, klaarzetten, uitrollen. Voor elk goed IT-bedrijf geldt: Don’t repeat yourself. Als een ontwikkelaar voor de tweede keer een aantal handelingen handmatig uitvoert, dan is-ie verkeerd bezig. Waarom? Omdat het geautomatiseerd had kunnen worden.

Organisatorisch gezien: als continuous delivery als proces is ingebed in de workflow van IT-bedrijven dan profiteren opdrachtgevers, klein en groot, daarvan. En dan is er de cultuuromslag. Anders denken, anders werken. Voor opdrachtgevers geldt dat net zo goed als voor ontwikkelaars.   

De opdrachtgever meenemen in het proces was namelijk niet zo gewoon. Werken volgens de watervalmethode was een vrij omslachtige en tijdrovende manier van werken. En testen gebeurde pas in een laat stadium, met alle gevolgen vandien als iets niet bleek te werken.

Case – HP FutureSmart

De divisie die de firmware voor HP LaserJet bouwt voor hun scanners, printers en multifunctionele apparaten bestaat uit 400 personen verdeeld over drie landen. Dat hielp niet om snel en gericht met nieuwe releases te komen om aan de marketingdoelstellingen te voldoen. De productiviteit moest met een factor tien omhoog. Daarvoor was nodig:

• Een universeel platform om alle diensten te ondersteunen
• Meer kwaliteit en sneller releases
• Minder tijdverlies aan planning

Continuous delivery was een belangrijke factor om deze doelstellingen waar te maken, met een focus op:

• Toepassen van continuous integration
• Aanzienlijke investering in geautomatiseerd testen  
• Het creëren van een hardware-simulator om tests te draaien op een virtueel platform
• Het reproduceren van de (negatieve) resultaten van tests op de werkstations van developers

Drie jaar later waren de economische voordelen van de transformatie naar agile bij HP duidelijk:

• 40% minder totale ontwikkelkosten
• 140% meer productiviteit
• 78% minder kosten per programma    
• 8 keer grotere capaciteit om te innoveren

Conclusie: deze enorme besparingen in kosten en toegenomen productiviteit zijn alleen mogelijk door continue investering van het team dat verantwoordelijk is voor geautomatiseerd testen en continuous integration. Het is geen managementactiviteit gericht op kostenbesparing. Het is een activiteit die geleid wordt door de ontwikkelaars zelf (bron).

Risico’s door aannames

Continuous delivery brengt het ontwikkelproces dichter bij de opdrachtgever. Doordat ontwikkelaars zich meer naar de voorkant begeven, met meer verantwoordelijkheid, groeien ze steeds meer toe naar ‘DevOps’. Een ‘developer’ én ‘system operator’ die zelf verantwoordelijk is voor het op een agile manier nieuwe code schrijven die stabiel (lees: vrij van fouten) in een productieomgeving kan draaien. Dit is hét antwoord op problemen die ontstaan tijdens de derde generatie in computing: het cloudtijdperk. Groot voordeel is dat je de foutgevoeligheid van de extra laag, bijvoorbeeld de systeembeheerder, er tussenuit haalt. Door het clouddenken verhuist deze juist meer naar de achtergrond.

Een ander groot voordeel is dat je sneller kunt toetsen met de eindgebruiker, bijvoorbeeld door A/B-testen. Waar het voorheen maanden duurde om iets door te voeren worden wensen en eisen sneller gehoord én bijgesteld. Je leert of je ideeën valide zijn. Want in tegenstelling tot de waterval-gedachte, waarbij het doel vooral het afvinken van de afgesproken functionaliteiten is, is bij de agile-methodiek het best passende eindproduct voor de eindklant het doel. Risico’s die ontstaan door aannames nemen af. Opleveren kan snel, en snelheid is belangrijk.

IT-bedrijven moeten direct kunnen inspringen als dat nodig is. Maar ook: opdrachtgevers weten waar ze aan toe zijn, het werk wijkt niet ineens af van de verwachtingen. Hierdoor is het totaalproces zomaar een stuk minder kostbaar. Er wordt geen geld en tijd weggegooid als het misgaat. En niets is duurder, tijdrovender en frustrerender dan iets opnieuw te moeten maken.

Kwestie van vertrouwen

De voordelen zijn helder, toch vraagt het ook iets van de opdrachtgever. Die moet accepteren dat het anders is dan denken in vaste budgetten. Dat is voor hen soms een spannende ontwikkeling. Want je moet bereid zijn om niet alles van tevoren te kunnen weten. De focus ligt namelijk veel meer op het inkopen van effort, in plaats van het inkopen van een product. De praktijk leert: omdat je in online-producten altijd iets kúnt veranderen, gebeurt het ook. Maar het nieuwe inzicht is: het snel corrigeren van fouten is belangrijker dan ze niet maken of ze per se willen voorkomen. Ook daar moeten opdrachtgevers aan wennen.

Het is een kwestie van vertrouwen, zeggen ervaren IT-bedrijven. Met een opdrachtgever in dat ritme zitten, ‘werkt geweldig’. Dat vertrouwen wekken zit hem al in de manier waarop continuous delivery werkt; omdat opdrachtgevers niet hoeven af te wachten tot het product af is, ze volgen de ontwikkeling zelf op de voet. Denk niet dat het voorbehouden is aan grote opdrachtgevers, wanneer continuous delivery als intern proces bij het IT-bedrijf ingebed is, werkt het ook voor kleinere bedrijven en organisaties.

En het mooie is, je kunt het ook op andere processen toepassen. Denk aan conceptontwikkeling. Zo is de Design Sprint ook ontstaan vanuit de agile-gedachte: in één adem van concept tot productie.