Het uitrolschema: maak er een requirement van

Het gebeurt nog steeds regelmatig dat een applicatie wordt opgeleverd, zonder dat er in een vroeg stadium de gelegenheid is geweest invloed uit te oefenen op het uitrolschema. Om grip te krijgen op deze materie, zullen we een vijftal release soorten beschrijven.

In een uitrolschema wordt gespecificeerd welke delen van een applicatie op welke manier en met welke frequentie kunnen worden uitgerold. Nog steeds gebeurt het regelmatig dat bij oplevering van een applicatie of een website nauwelijks over een uitrolschema is nagedacht. Het uitrollen gebeurt dan a l’improviste, iets dat als het ware vanzelf uit de architectuur voortkomt en dat zelden zal stroken met de wensen van de klant. In het voortraject is er nooit duidelijk van een uitrolschema sprake geweest – het thema is hoogstens zijdelings aan de orde geweest, er zijn wat mooie woorden gevallen als “generiek” of “flexibel”, en dat is het dan.
Pas gaandeweg, als de applicatie al live is – als er al beheer gepleegd moet worden – beginnen de effecten van deze leemte voelbaar te worden. De functionele eigenaar zit ijverig werklijsten te maken van wat er allemaal gefixt en aangepast moet worden. Maar van de IT-ers krijgt hij steeds te horen wat er op het gebied van uitrollen allemaal kán – dat wil zeggen, wat er allemaal sóms kan, wat er allemaal móeilijk kan en wat er misschien wel helemáál niet kan. En wie had hier om gevraagd? Inderdaad, helemaal niemand, en dat is precies het punt: er is nooit een uitrolschema gespecificeerd geweest.

De vijf release soorten

Stilzwijgend is de applicatie-eigenaar ervan uitgegaan dat uitrollen helemaal vanzelf zou gaan. Bij kleine, relatief eenvoudige sites, waar de oorspronkelijke ontwikkelaars ook het beheer hebben overgenomen, kan dit misschien nog steeds het geval zijn. Maar bij grote, complexe sites, waarbij downtime ook nog eens rechtstreeks vertaald kan worden in omzetderving of imagoschade, is het verstandig al helemaal in het beginstadium van de ontwikkeling van een applicatie een uitrolschema te formuleren, waar vervolgens de architectuur op afgestemd kan worden.

Figuur 1. De vijf release soorten

De basiselementen van een uitrolschema zijn de verschillende release soorten, waarvan we er hieronder een vijftal zullen beschrijven. We beginnen met de grootste: een nieuwe versie

1) Een nieuwe versie
Een nieuwe versie is de meest grootschalige wijziging op het systeem denkbaar. We denken aan een echte 2.0 versie waarbij ook wijzigingen in de hardware of het netwerk mogelijk zijn. Het spreekt vanzelf dat een nieuwe versie grondig doorgetest dient te worden. Het opleveren van een nieuwe versie is bijna te vergelijken met het opleveren van een geheel nieuwe applicatie, behalve dan dat de site bij de gebruikers bekend is en vanaf de eerste dag met het volle aantal bezoekers te maken zal krijgen. Het tempo waarin nieuwe versies opgeleverd worden ligt ergens tussen de 2 en 8 jaar

2) Major release
‘Major’ noemen we de release waarin significante wijzigingen of uitbreidingen van de functionaliteit zijn ondergebracht. Weliswaar hebben we het niet over een 2.0 maar altijd nog over een 1.1. In de meeste gevallen zal er een ontwikkelteam voor zijn samengesteld en zal de leiding in handen zijn van een projectmanager. Ook in het geval van een major release zal er grondig getest moeten worden. Niet alleen de nieuwe of gewijzigde functionaliteit, maar alles wat in de site door de wijzigingen beïnvloed kan worden, dient getest te worden (regressietest). Over het ontwikkelen van een major release gaan meestal enkele maanden heen.

3) Minor release
Naast een major release kan er ook een minor release worden gedefinieerd, een 1.0.1. Hierin zijn kleine wijzigingen en bugfixes opgenomen. Eén van de belangrijkste taken van releasemanagement is om te bepalen welke changes thuishoren in een major en welke in een minor release. Bij een minor release zijn de wijzigingen op het systeem minder ingrijpend, wat betekent dat de testinspanningen kleiner zijn en de risico’s bij uitrol beduidend lager zijn. In de regel zullen minor releases niet door projectteams worden gemaakt maar door applicatiebeheer. Minor release worden eerder binnen een tijdsbestek van weken dan van maanden uitgerold.

4) Gestructureerde data
Veel informatieverschaffing is zelf aan een cyclus onderhevig – denk aan nieuwsbrieven, wijzigingen van het assortiment in een webwinkel, het menu in een restaurant, of gewijzigde reistijden wegens werkzaamheden. Het kan verstandig zijn om een gedeelte van de informatieverschaffing in een week- of maandcyclus onder te brengen. Naar binnen toe kunnen organisaties daar de bedrijfsprocessen op inrichten en naar buiten toe is de informatieverschaffing consistent en transparant.

Dit betekent dat er binnen deze cyclus zonder al te veel inspanning een brok data op de site geplaatst moet kunnen worden en dat de architectuur daarop ingericht dient te zijn. Technisch zijn er talloze mechanismen denkbaar die zo’n cyclus verzorgen en de mogelijkheid bestaat diverse stappen daarin te automatiseren (plaats een Excelsheet in een directory en voilà).

5) Ad hoc data
Bij ad hoc informatie kan bijvoorbeeld gedacht worden aan nieuws, of aan informatie over storingen. Het is informatie die snel, dat wil zeggen, binnen een dag, binnen een uur, of zelfs on the fly beschikbaar moet zijn. In verreweg de meeste gevallen zal voor deze cyclus een CMS (Content Management Systeem) worden ingezet.

De kracht van een helder uitrolschema

Problemen met uitrollen zijn vaak terug te voeren op het plaatsen van elementen in de verkeerde release soorten. Een berucht voorbeeld is de “hard gecodeerde tekst”. Ooit had iemand bedacht dat een bepaalde tekst niet CMS-gestuurd hoefde te zijn omdat deze toch nooit gewijzigd zou gaan worden. En als de tekst dan tóch gewijzigd moet worden, dan kan dat pas gebeuren in de eerstvolgende minor release die misschien wel veertien dagen op zich laat wachten. En leg dat maar eens uit, zo’n klein tekstje…

Ook hier geldt, voorkomen is beter dan fixen. Is de opdrachtgever in staat de datastromen en de toekomstige wijzigingen onder te verdelen in de vijf hierboven genoemde release soorten en kan de opdrachtgever aan iedere release type een tijdsbestek vastkoppelen? Dan beschikt hij over de belangrijkste elementen om een uitrolschema op te stellen. Met zo’n uitrolschema kan hij aan de bouwers eisen stellen over hoe en hoe vaak verschillende onderdelen van de applicatie uitgerold moeten worden. Of met andere woorden, het uitrolschema fungeert dan als een requirement.

Van daaruit kunnen vragen beantwoord worden als: wat wordt configureerbaar gemaakt en wat niet? Welke onderdelen moeten los van de applicatie-als-geheel kunnen worden uitgerold? Met een helder uitrolschema kunnen onaangename verrassingen worden voorkomen en kan het uitrolproces afgestemd worden op de wensen binnen de organisatie.