Computable.be
  • Thema’s
    • Security & Awareness
    • Cloud & Infrastructuur
    • Data & AI
    • Software Innovation
  • Computable Awards
    • Nieuws Computable Awards
    • Hall of Fame
  • Cybersec e-Magazine
  • Kennisbank
  • Inlog
  • Nieuwsbrief
continuous development en continuous delivery

De Change Advisory Board kan naar huis

26 augustus 2016 - 12:514 minuten leestijdOpinieCloud & Infrastructuur
Peter Dens
Peter Dens

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

Meer over

ITILOpensourceTesting

Deel

Fout: Contact formulier niet gevonden.

Meer lezen

Kwantum
ActueelCloud & Infrastructuur

Nieuwe Cisco-netwerkchip brengt quantum-internet dichterbij

cybersecurity
ActueelCarrière

Kort: Betere soft skills nodig voor cybersecurity-medewerkers, ontslagronde Crowdstrike, Gates fakkelt Musk af en…

ActueelCloud & Infrastructuur

Europese Rekenkamer kraakt EU-strategie voor chipsector

ActueelCarrière

Helft bedrijven kijkt voor it’ers naar het buitenland

ActueelCloud & Infrastructuur

Digital Realty biedt directe lijn met Microsoft Azure

Boete
ActueelCloud & Infrastructuur

EU legt Apple en Meta onder nieuwe Big Tech-wetgeving forse boetes op

2 reacties op “De Change Advisory Board kan naar huis”

  1. Fernand Van Huffel schreef:
    2 september 2016 om 09:10

    Als de CAB zou verdwijnen, hoe zal ITIL dan nog rijmen met de nieuwe situatie?

    Beantwoorden
  2. Peter Dens schreef:
    5 september 2016 om 15:15

    Fernand,

    dat antwoord heeft wat nuance nodig. Geef me een dag of 2 en ik typ iets moois voor je uit.

    groeten,

    Peter

    Beantwoorden

Geef een reactie Reactie annuleren

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Populaire berichten

Meer artikelen

Footer

Direct naar

  • Kennisbank
  • Computable Awards
  • Colofon
  • Cybersec e-Magazine

Producten

  • Adverteren en meer…
  • Persberichten

Contact

  • Contact
  • Nieuwsbrief

Social

  • Facebook
  • X
  • LinkedIn
  • YouTube
  • Instagram
© 2025 Jaarbeurs
  • Disclaimer
  • Gebruikersvoorwaarden
  • Privacy statement
Computable.be is een product van Jaarbeurs