Opleveren met een strikje eromheen

De afgelopen jaren ben ik direct of indirect betrokken geweest bij een groot aantal interne en externe software ontwikkeltrajecten. De meeste van deze projecten hadden een gedegen project opzet gebaseerd op een bestaande of eigen ontwikkelmethodiek. Versiebeheer werd toegepast, ontwikkelstraten ingericht en testplannen opgesteld. De basis voor een goed resultaat was bij al deze projecten aanwezig, de afronding viel echter vaak tegen.

Veel projecten hebben namelijk als op te leveren eindproducten een handje vol executable files, webpages of libraries. Vaak worden deze vergezeld door een aantal configuratie-bestanden die, afhankelijk van de doelomgeving, al dan niet moeten worden gekopieerd of nog even moeten worden aangepast. Hierdoor ontbreekt vaak een eenduidige manier van versie-indicatie, waardoor het vaak niet eenvoudig te achterhalen is welke versie van de software of versies van bestanden er nu daadwerkelijk zijn uitgerold bij de klant. Dergelijke perikelen zouden niet voor mogen komen in een software ontwikkelingstraject en zeker niet als uiteindelijke oplevering. Maar hoe voorkom je het?

Installatie-document

Het makkelijkste antwoord is dat er een uitgebreid installatie-document zou moeten zijn. Dit document beschrijft hoe de applicatie zou moeten worden uitgerold en wat eventuele configuratie handelingen zouden moeten zijn. Idealiter heeft een klant vereisten waaraan dit document moet voldoen. Wat ik echter vaak zie is dat een dergelijk document ontbreekt of enkel bestaat in de vorm van een e-mail met daarin enkele activiteiten.

Een tweede optie, die de eerste overigens niet uitsluit, is het opleveren van een eindproduct in de vorm van een ‘deployable package of installer'. Voor de meeste target systemen zijn installer frameworks beschikbaar met daarin een enorm scala aan mogelijkheden. De eenvoudigste versie van een dergelijke package is er een die enkel bestanden kopieert naar een doelfolder, waarna er alsnog veel handmatige activiteiten moeten worden uitgevoerd. Het loont zich echter om een iets uitgebreidere installer te ontwikkelen die bijvoorbeeld configuratie activiteiten uitvoert die zouden kunnen verschillen per target-omgeving.

En daar zit vaak het probleem: een uitgebreidere installer wordt meestal complexer en bestaat vaak uit specifieke elementen of activiteiten die gebouwd moeten worden. Het wordt dus onderdeel van je applicatie-ontwikkeling. En net als bij elke stuk software zal er dus tijd en geld beschikbaar voor moeten zijn. Geld dat uiteindelijk door de klant betaald moet worden. De klant zal dus overtuigd moeten worden van de voordelen van dit onderdeel van je applicatie waar hij zelf nooit mee zal gaan werken.

Hoe zit het met de return on investment? Laten we eens aannemen dat het ontwikkelen van een installer een week (veertig uur) kost en dat deze installer onze installatie doorlooptijd reduceert van zestig minuten naar tien minuten. We hoeven immers geen configuratie bestanden en paden te controleren. Om de geïnvesteerde uren terug te winnen zouden we 40 uur/50 minuten = 48 keer moeten installeren. Dat lijkt vaak maar is dat wel zo? In een aantal van onze webprojecten hebben we omgevingen met meerdere webservers en databaseclusters.

Terugwinnen

Een installatie van een omgeving betekent dan eigenlijk vier installaties. We hebben onze veertig uur dan in 48/4 = twaalf omgevinginstallaties terug gewonnen. Als we dan ook nog rekening houden met iteratief ontwikkelen in bijvoorbeeld drie iteraties die daadwerkelijk worden opgeleverd dan komen we op vier installaties per iteratie uit. Een van deze vier installaties is er één in een omgeving bij de klant, wat dus betekent dat je minimaal drie interne installaties per iteratie moet uitvoeren om tijdwinst te behalen uit je installer. Hierbij is het realistisch om aan te nemen dat bij een gemiddeld ontwikkeltraject meer dan drie interne opleveringen plaatsvinden per iteratie. Heb je meerdere releases per jaar, dan valt het nog voordeliger uit.

Tijd en geld zouden dus geen probleem moeten zijn. Wat krijgt een klant nog meer terug voor de tijd die wordt geïnvesteerd? Een groot voordeel van het gebruik van een installer is het terugdringen van het aantal handmatige acties die tijdens het uitrollen moeten worden uitgevoerd. Aangezien de kans op fouten bij handmatige acties aanwezig is, leidt het terugdringen van deze acties tot een hogere betrouwbaarheid van een release. Als het daarbij ook nog zo is dat iets op meerdere systemen uitgerold moet worden, dan is de kans op onderlinge configuratieverschillen een stuk kleiner wanneer minder handmatige stappen uitgevoerd moeten worden. Dit leidt dus tot een eenduidiger eindresultaat.

Looptijd

Een laatste punt is de looptijd van een uitrol. Deze wordt bij minder handmatige acties een stuk korter. Een kortere looptijd betekent minder kosten aan resources die een uitrol uitvoeren en wellicht nog wel het belangrijkst: een kortere down-time voor systemen.

Ook leidt het gebruik van een installer tot het terugdringen van de complexiteit van een release, waardoor er minder expertise nodig is bij het uitrollen. Kort door de bocht betekent dit dat een release kan worden uitgevoerd door mensen die geen expert zijn op het gebied van de uit te rollen release. Dit uit zich weer positief in de kosten van een uitrol.

Met een relatief kleine inspanning van veertig uur kunnen dus een hoop voordelen worden behaald. Deze voordelen uiten zich in een hogere kwaliteit van de oplevering, op de doorlooptijd van de oplevering en uiteindelijk op het financiële vlak. Het gebruik van een goed verpakte oplevering leidt dus voor zowel de klant als de ontwikkelaar tot een oplevering met een 'strikje' eromheen!