Blog

Wie is er bang voor Continuous Delivery?

Telkens wanneer een nieuwe trend de kop op steekt, hoor je mensen zeggen 'dat is niks nieuws, zo deden we het decennia geleden al'. Zo is Agile niet geboren met het opstellen van het Agile Manifesto, maar bestaat al zo lang er software is. Rapid Application Development (RAD) maakt de laatste jaren een explosieve groei door, maar het concept stamt uit de jaren ‘80. Ook Continuous Delivery is een buzzword dat je de laatste tijd vaak hoort, terwijl het concept al een aantal jaar bestaat.

De grondslag van dit soort revivals in IT-ontwikkeling, is technische vooruitgang. Een revolutionair nieuw idee is de eerste stap, maar pas als je de benodigde middelen hebt, kun je het gaan uitvoeren.

Waarom is het naar productie brengen van applicaties zo moeilijk?
In 2010 werd de Continuous Delivery werkwijze populair, mede dankzij het gelijknamige boek van Jez Humble en David Farley uit. De mantra was het nastreven van een compleet geautomatiseerd deployment proces zodat software-aanpassingen – van features en bug fixes tot configuraties en experimentjes – veilig en snel worden uitgevoerd. Als je alleen buiten werktijden een nieuwe release naar productie kunt brengen, is er iets mis in je manier van werken.

Key daarbij is blue/green deployment: creëer twee omgevingen die bijna identiek zijn; een oude, laten we zeggen blauwe omgeving, en een nieuwe, groene. De blauwe omgeving staat live en als het testen met de groene omgeving klaar is, zet je de knop van blauw naar groen om. Mocht er onverhoopt toch iets mis zijn, kun je de knop weer terug zetten met minimaal risico.

Het idee was veelbelovend, maar grootschalige implementatie bleef uit, voornamelijk omdat er onvoldoende middelen waren voor de grootschalige automatisering van het ontwikkelproces. Zes jaar later hebben we die hulpmiddelen wel voor handen en kunnen we de beloften van 2010 in de praktijk waar maken.

Ingrediënten voor Continuous Delivery
Drie grote uitdagingen stonden een doorbraak van Continuous Delivery in de weg:

  1. Configuration management is bijzonder belangrijk bij Continuous Delivery. Als er dagelijks nieuwe software wordt gereleaset, is het belangrijk nauwgezet in kaart te brengen welke veranderingen er zijn doorgevoerd in de hard- en softwareconfiguratie, en in de gaten te houden waar er risico is op vertraging of kwaliteitsverlies. Er zijn tegenwoordig meerdere aPaaS (application platform as a service) aanbieders waarmee je volledig geautomatiseerd omgevingen kunt inrichten en beheren die identiek zijn aan de productieomgeving.
     
  2. Continuous integration is een manier van werken waarmee je voorkomt dat de takken van verschillende ontwikkelteams te ver uit elkaar groeien waardoor het systeem dat naar productie wordt gebracht, instabiel wordt. Alle ontwikkelaars checken minstens een keer per dag kleine stukken software (units) in de hoofdstroom (de zogenaamde ‘trunk’). Tegenwoordig bieden veel leveranciers van modelgedreven ontwikkelplatforms, onder andere OutSystems, geautomatiseerd versiebeheer en controles voor het inchecken van software zodat aanpassingen in de trunk probleemloos verlopen. Mocht er zich een probleem voordoen in de trunk, dan moet dat eerst worden opgelost, zodat het ontwikkelproces door kan lopen.
     
  3. Test automation is van het grootste belang om bij Continuous Delivery zeker te zijn dat het systeem dat naar productie wordt gebracht, goed functioneert. Oplossingen voor het automatiseren van tests zijn er, en inmiddels zijn we bij de derde generatie van tools die modelgebaseerd testen mogelijk maken. Op dit moment wordt 15% van het testwerk geautomatiseerd gedaan. De belofte met deze nieuwe generatie tools is een automatiseringsgraad van 90%.

Invoering van Continuous Delivery
Technologische ontwikkelingen hebben er de afgelopen jaren voor gezorgd dat Continuous Delivery bereikbaar is geworden voor alle bedrijven. Maar de invoering behelst meer dan de aanschaf van technologie en duurt veelal enkele jaren. Zo moet de architectuur worden afgestemd op deze nieuwe werkwijze; er moet worden nagedacht over hoe je software maakt en wijzigt zodat releases ook snel en eenvoudig kunnen worden teruggedraaid, en over het mogelijk maken van A/B-testen voor een gecontroleerde uitrol in productie. En - last but not least - moet er ook voor worden gezorgd dat de bedrijfscultuur ingericht is op Continuous Delivery, zodat mensen niet alleen kunnen omgaan met continu innoveren, maar hier ook plezier in hebben.

Deze blog is geschreven door Joachim Vandecasteele. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
Categorie:   
Auteur
afbeelding van JoachimVandecasteele
Joachim Vandecasteele
COOLProfs - CTO

Joachim Vandecasteele is de CTO van COOLProfs, specialist in het bouwen van bedrijfskritische informatiesystemen op maat. COOLProfs onderscheidt zich door haar aanpak, waarin de menselijke factor van IT centraal staat en waarbij in nauwe samenwerking met de klant het gewenste resultaat wordt gerealiseerd. Vandecasteele was voor zijn tijd bij COOLProfs senior consultant bij KPMG Consulting op het gebied van World Class IT en consultant ISES International op het gebied van CASE-tools voor systeemontwikkeling. Hij heeft verschillende publicaties op zijn naam staan over de toekomst van de IT-organisatie, over strategierealisatie met de balanced scorecard en over maatwerk systeemontwikkeling. Vandecasteele studeerde Bestuurlijke Informatiekunde aan de Katholieke Universiteit Brabant en Bedrijfsinformatica aan de Haagse Hogeschool. Zijn vrije tijd besteedt hij aan zijn gezin, alles volgen wat met IT te maken heeft en marathons lopen. Altijd gedreven, scherp en vrolijk!

Twitter: jvandecasteele
Email: joachim.vandecasteele@coolprofs.com

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.