De Change Advisory Board kan naar huis

Komt er een einde aan de Change Advisory Boards (CAB)? Ik denk het wel. Stel u voor hoe organisaties in de traditionele ITIL-aanpak omgaan met changes en releases: de change manager verzamelt alle verzoeken voor een change, zet ze op een rij voor de CAB en deze komt eens per twee maanden bijeen om ze te bespreken.

Zo zal het in de praktijk lang niet altijd meer gaan, maar het vertegenwoordigt wel een jarenlange filosofie. Wie nu nog vertrouwen heeft in deze aanpak, moet zich oprecht zorgen maken over de continuïteit van zijn organisatie. Want bedenk dat grote, it-gedreven organisaties zoals Facebook, Google of Amazon probleemloos meerdere releases per dag doorvoeren in hun systemen. 

Het is duidelijk dat ‘continuous’ de norm wordt: continuous integration, continuous development en  continuous delivery. En wie hierin niet volgt, loopt grote kans ingehaald te worden door de directe concurrenten die er wel mee aan de slag gaan.

Het gaat hier niet uitsluitend over applicaties deployen, maar ook over het beheren van de configuratie van uw infrastructuur. Denk bijvoorbeeld aan het definiëren van een webserver. Dit zorgt ervoor dat telkens wanneer je een bepaald type webserver wenst, die er telkens exact hetzelfde zal uitzien. En dat is waar het om gaat. 

Continuous

Het ontwikkelen, testen en vrijgeven van meerdere releases per dag is in de eerste plaats mogelijk door het beschikbaar komen van allerlei tools om de build-, test-, deployment- en provisioningprocessen vergaand te automatiseren. Door deze stappen maximaal te automatiseren, win je niet alleen aan snelheid maar ook aan kwaliteit. Fouten zijn te voorkomen door zeer gestructureerd en gestandaardiseerd te werken: je schakelt de factor van ‘human error’ zoveel mogelijk uit.

Met welke tools zou je dan aan de slag kunnen? GitHub kan bijvoorbeeld dienst doen als basis om je source code in onder te brengen, voor build tools wordt er dan weer vaak gekeken naar Jenkins. Wat deployment betreft gebruiken wij voornamelijk Ansible, Chef of Puppet.

Cloud en virtualisatie

Dankzij de diverse automatiseringstools kan je perfect de gepaste configuratie voor je infrastructuur opnieuw toepassen. Naast deze tools hebben cloud en virtualisatie de continuous-filosofie enorm ondersteund. Door de onbeperkte beschikbaarheid van virtual machines in de cloud is capaciteit altijd en onmiddellijk beschikbaar.

Dat was vroeger wel anders: hardware bestellen, hardware configureren en dan testen. En bij iedere volgende release was het maar afwachten of de configuratie van de hardware nog wel onveranderd was gebleven. Nu zijn omgevingen exact te kopiëren in de cloud en hoef je in ieder geval niet meer bang te zijn dat een gewijzigde configuratie de test negatief beïnvloedt. 

Open source

Nagenoeg ieder ontwikkelplatform biedt wel mogelijkheden voor continuous development en delivery. Echter open source biedt wat mij betreft de beste mogelijkheden. Open source tools kunnen veel sneller inspelen op de commerciële behoeften van een organisatie. Daarenboven wordt open source ondersteund door een grote, internationale community en garandeer je zo een hoge kwaliteit. Verder is open source in de regel kostenefficiënter dan gesloten platforms. Al met al voldoende reden om de mogelijkheden van deze platforms goed te onderzoeken en evalueren.

‘Continuous’ is here to stay. Het biedt enorme kansen, maar vereist ook een andere manier van werken. Het vraagt om korte communicatielijnen en intensieve samenwerking binnen teams. Maar wie dat goed organiseert, kan rekenen op uitstekende resultaten. Want net door die volledige controle over de automatisatieketting kan het gehele releaseproces geautomatiseerd worden en dan maakt het niet meer uit wanneer en hoe vaak je een nieuwe release uitrolt.

Peter Dens, managing director bij Kangaroot