4.7.3. Aanvullende informatie over de maatregelen (release- en deployment beheer) 3.0

4.7.3.1. Wat is release en deployment beheer?

Release en deployment beheer is een preventieve maatregel en omvat de procedures, systemen en functies nodig om release pakketten samen te stellen, te bouwen, testen en uit te rollen in een productie-omgeving. Release en deployment beheer omvat volgende activiteiten (zie paragraaf 4.7.3. Aanvullende informatie over de maatregelen (release- en deployment beheer) 3.0 | 4.7.3.3. De bouwstenen van release en deployment beheer):

• Planning fase,

• Bouw, test en acceptatie fase,

• Uitrol,

• Verificatie en afsluiten.

4.7.3.2. Succesfactoren voor een goed release en deployment beheer

Een organisatie moet de kritische succesfactoren definiëren die passend zijn voor haar omgeving en elke kritische succesfactor moet opgevolgd worden door één of meerdere kritische prestatie-indicatoren (zie hoofdstuk: ‘Prestatie-indicatoren (KPI’s)'). Succesfactoren voor release en deployment beheer omvatten:

• Optimalisatie van de kost en minimalisatie van het risico dat elke wijziging van een bestaande omgeving met zich meebrengt,

• Een consistente implementatie aanpak,

• Goede samenwerking met andere beheersprocessen zoals wijzigingsbeheer, incidentbeheer, probleembeheer en asset- en configuratiebeheer,

• Traceerbaarheid en auditeerbaarheid van de implementatie.

4.7.3.3. De bouwstenen van release en deployment beheer

4.7.3.3.1. Planning

Een goed doordacht en onderbouwd releaseplan is een belangrijk onderdeel van elke succesvolle release, waarbij de nodige aandacht moet worden geschonken aan wat in de release is inbegrepen en hoe deze wordt uitgerold in productie.

Een releaseplan omvat volgende elementen:

• Welke wijzigingen in de release zijn opgenomen,

• Wie geïmpacteerd wordt door de release,

• Welke risico’s verbonden zijn aan de release,

• De doelgroep van de release,

• Een duidelijke lijn van goedkeuringen die weergeven welke belanghebbenden welke wijzigingsvraag moeten goedkeuren in elke stap van de release,

• Aanduiding van het team verantwoordelijk voor de release en de uitrol,

• Planning van de uitrol en uitrol strategie.

• Vaak worden ook bouw- en testplannen in deze fase opgesteld waarbij aandacht wordt geschonken aan functionele en niet-functionele behoeften, designspecificaties, testprocedures, planning voor bouw en test, acceptatie-criteria in elke stap van de bouw en test en eventuele planning van een piloot opstelling. 

De planning moet tevens rekening houden met de wijze waarop de uitrol in productie zal worden uitgevoerd. Hier zijn verschillende opties mogelijk:

• Big bang optie: de nieuwe of gewijzigde functionaliteit wordt uitgerold naar alle betrokken gebruikers tegelijk in één enkele operatie;

• Gefaseerde aanpak: de nieuwe of gewijzigde functionaliteit wordt eerst uitgerold naar een beperkte groep gebruikers, vervolgens wordt de operatie herhaald volgens planning naar andere groepen van gebruikers, net zo vaak als nodig is om de doelgroep volledig te bereiken;

• Pull optie: met deze optie wordt de release ter beschikking gesteld aan de gebruikers maar zij bepalen zelf of en wanneer ze de release op hun apparatuur installeren.

Indien geopteerd wordt voor een pull optie, wordt vaak aangeraden om deze optie slechts een beperkte tijd beschikbaar te houden, gevolgd door een geforceerde of push uitrol (volgens big bang of gefaseerde aanpak) aangezien er altijd wel gebruikers zullen zijn die geen gebruik maken van de pull optie. Deze optie noemen we de gelimiteerde pull. De keuze van de uitroloptie heeft zowel gevolgen voor de benodigde middelen voor release en deployment als op de zakelijke omgeving. Om de juiste keuze te maken is een goede kennis van de zakelijke omgeving en de profielen in de doelgroep noodzakelijk.

Automatische of manuele releases

De mechanismen voor een geslaagde release en uitrol moeten geïdentificeerd worden tijdens de planning en getest tijdens bouw en test fase. Automatisatie kan helpen om herhaalbaarheid en consistentie te garanderen, maar de tijd nodig om een geautomatiseerde uitrol te faciliteren is niet altijd voorhanden. Indien een manuele uitrol de enige optie is, is het belangrijk om alle stappen te monitoren en de impact van vele herhaalde manuele activiteiten te meten aangezien deze waarschijnlijk niet repetitief en/of inefficiënt zijn. Teveel manuele acties kunnen het proces vertragen en kostbare middelen opgebruiken met gevolgen voor het beloofde serviceniveau.

Er zijn vele tools op de markt die kunnen helpen bij (een beperkte) automatisatie:

• Inventarisatie en ontdekkingstools,

• Software voor ontdekking en verificaties van bestaande implementaties kunnen helpen om de vooraf bepaalde vereisten voor installatie na te gaan,

• Automatisatie van het bouwproces,

• Automatisatie van het onderhoud van gegevens in de CMDB na een release,

• Installatie procedures.

4.7.3.3.2. Bouw, test en acceptatie

Zodra een release plan is opgesteld en goedgekeurd, moeten de nodige componenten (hardware, software, documentatie en alle andere) gebouwd, samengesteld en getest worden. Na succesvolle testen volgt dan nog een formele acceptatie door alle belanghebbenden (eindgebruikers, beheersorganisatie, DPO, …).

Het is raadzaam reeds bij aanvang van deze fase de nodige documentatie aan te leggen om de accuraatheid en efficiëntie van de bouw te verzekeren. Alle activiteiten van het bouwproces moeten gedocumenteerd worden zodat – indien nodig – opnieuw kan aangevat worden. Vaak wordt hierbij gebruik gemaakt van strikte procedures en sjablonen.
Elke stap in het bouwproces vereist eigen test procedures en -plannen en acceptatiemomenten. Bouw, test en acceptatie omvatten volgende activiteiten:

• Ontwikkelen van bouwplannen vertrekkende vanuit ontwerp, ontwerp specificaties, functionele en niet-functionele behoeften en andere omgevingsfactoren die een rol spelen bij de ontwikkeling van de release;

• Vaststellen van de logistiek nodig om de omgeving voor te bereiden;

• Inplannen van bouw, test en acceptatie activiteiten;

• Toewijzen van middelen, identificatie van rollen en verantwoordelijkheden nodig om de activiteiten uit te voeren;

• Bouw-, test- en acceptatie omgevingen voorbereiden;

• Testgegevens en test databases voorbereiden;

• Beheer van de nodige licenties.

Piloot opstellingen

Piloot opstellingen zijn nuttig om een nieuwe of gewijzigde functionaliteit uit te testen op een beperkte doelgroep vooraleer wordt besloten tot in productie name van de nieuwe of gewijzigde functionaliteit. Hierbij moet de nodige aandacht geschonken worden aan de scope van de piloot opstelling: welke functionaliteit is opgenomen, welke doelgroep wordt erbij betrokken, welke departementen worden aangesproken, enz. De piloot opstelling moet daarnaast voorzien in de nodige verzameling van testresultaten en feedback,
waaronder:

• Opmerkingen en tevredenheidsscores van eindgebruikers en andere belanghebbenden,

• Feedback van de beheersorganisatie,

• Statistische informatie over het gebruik, de resultaten en efficiëntie van de piloot opstelling.

Bouw, test en acceptatie van de release

Tijdens bouw, test en acceptatie van de release moet de nodige aandacht geschonken worden aan volgende aspecten:

• Security by design en by default, Gebruik van de bouw-, test- en acceptatie omgeving,

• Documentatie van het bouwproces zodat de bouw kan worden overgedaan indien nodig,

• Test resultaten documenteren,

• Acceptatie-criteria en acceptatie momenten vastleggen,

• Nagaan dat voldaan is aan alle functionele en informatieveiligheidsvereisten,

• Verificatie van de activiteiten en nagaan of alle vooronderstellingen die gemaakt werden voorafgaand aan de bouw werden ingevuld.

Logistiek en levering van componenten

Tijdens de bouwfase moet rekening worden gehouden met de logistiek en levering van de nodige componenten (hardware, software, licenties, enz.). Dit houdt onder andere volgende in: 

• Hoe en wanneer de nodige componenten worden geleverd;

• Welke doorlooptijden worden voorzien en wat de impact is van eventuele vertragingen;

• Opvolging van de verschillende leveringen.

Release pakketten

Release pakketten moeten op een gestandaardiseerde en gecontroleerde wijze opgebouwd worden volgens de specificaties van het ontwerp. Vaak is dit een iteratief proces: naarmate de in productie name vordert, kan het zijn dat de bouw van een release pakket herstart moet worden. Tijdens de bouw van een release pakket houdt men best rekening met volgende factoren:

• Een gecontroleerde samenstelling en integratie van de componenten in het release pakket;

• Opmaak van release documentatie (bouw, installatie, test en acceptatie plannen, procedures en scripts);

• Opvolgen en verifiëren van de kwaliteit van de bouw;

• De geautomatiseerde en/of manuele procedures nodig om het pakket te verdelen, uit te rollen en te installeren en – waar nodig – bestaande componenten te verwijderen; 

• Fall back procedures ingeval van problemen of falen van de uitrol;

• Opvolging van de benodigde licenties;

• Installatie en verificatie van het release pakket;

• Notificatie en communicatie naar de betrokken partijen (gebruikers, beheerorganisatie en andere belanghebbenden).

4.7.3.3.3. Uitrol

Zodra de diverse testen op het release pakket succesvol zijn afgerond, kan het uitgerold worden in de productie omgeving. Maar eerst moeten de wijzigingen voorgesteld in het release pakket goedgekeurd worden door het proces wijzigingsbeheer. Vanaf dit punt worden bijkomende wijzigingen aan de release beheerd door het proces wijzigingsbeheer, bv. oplossen van fouten of bugs (voor meer informatie zie pagina 4.4. Minimale maatregelen - Beheer van wijzigingen 3.0 ). De uitrol naar de productie omgeving moet met de nodige omzichtigheid benaderd worden:

• Is de doelomgeving klaar voor uitrol?

• Zijn potentiële risico’s van de uitrol in kaart gebracht en gemitigeerd?

• Is er rekening gehouden met eventuele onderbrekingen in de operationele werking en de gevolgen ervan?

• Is de volgorde waarin de componenten uitgerold worden goed gedefinieerd?

Zodra de uitrol is beëindigd, moet nagegaan worden of de nieuwe of gewijzigde ICT-dienstverlening correct werkt voor alle belanghebbenden – interventies of zelfs een fall back moeten worden voorzien indien dit niet zo is.

De uitrol eindigt met de overhandiging aan de beheerorganisatie, dit gebeurt vaak in twee fazen:

• Formele notificatie dat de ICT-dienst of functionaliteit in kwestie beschikbaar is in de productie omgeving;

• Formele notificatie dat de ICT-dienst of functionaliteit in kwestie volledig operationeel is en SLA’s volledig in werking zijn.

4.7.3.3.4. Verificatie en afsluiten

Om een uitrol af te sluiten wordt ze eerst nog geverifieerd en worden lessen getrokken uit de release/uitrol. Bijkomend worden volgende activiteiten uitgevoerd:

• Verificatie dat aan alle functionele, technische en informatieveiligheidsvereisten zijn voldaan;

• Controle dat alle acties, noodzakelijke herstellingen (fixes) en wijzigingen zijn doorgevoerd;

• Feedback van gebruikers, beheersorganisatie en andere belanghebbenden;

• Terugkoppeling naar het proces wijzigingsbeheer;

• Kwaliteitscontrole op de uitrol;

• Nagaan of er geen capaciteits-, performantie- of andere problemen zijn opgedoken na de uitrol;

• Verificatie dat eventuele problemen, gekende fouten en tijdelijke oplossingen gedocumenteerd zijn en goedgekeurd door alle betrokken partijen;

• Opvolgingen van incidenten en problemen veroorzaakt door de uitrol;

• Formele overhandiging naar de beheersorganisatie, inclusief de nodige documentatie;

• Een post-implementatie review door het proces wijzigingsbeheer waar vereist. 

4.7.3.3.5. Het proces  

Open