7 suggesties voor een schaalbare continuous delivery pipeline

Andreas Prins

Een Continuous Delivery Pipeline als onderdeel van een Agile transformatie is gelijk aan de kruiden in een smaakvol gerecht. Bij ontbreken er van is het waardeloos en smaakt het naar niets. Is het aanwezig dan smaakt het naar meer, werkt het als stimulans en geeft het energie. Het is echter niet eenvoudig om de juiste kruiden bij het juiste gerecht te vinden.

Een basis van peper en zout is er nagenoeg altijd echter kun je niet altijd kurkuma, steranijs, gember of koriander inzetten om de boost te geven. Je moet met zorg een combinatie selecteren om je gerecht echt smaakvol te maken. Zo is het ook bij de tools die je onderdeel wilt maken van je continuous delivery pipeline.

Een continuous delivery pipeline is niet zomaar iets, het kan geen verzameling van tools zijn zoals de kruidenla in je keuken. Afhankelijk van de doelen die een team heeft kies je bepaalde tools wel en niet. In deze post deel ik 7 suggesties met je om een echte chef te worden.

  1. Voorkom de creatie van een monoliet
  2. Balanceer tussen verplichte en vrijwillige componenten
  3. Benader een CD pipeline niet als een verzameling tech tools maar als een value stream
  4. Gebruik de MVP approach in de opbouw van je pipeline
  5. Omarm een model waarin experimenten eenvoudig te realiseren zijn
  6. Limiteer het bouwen van eigen oplossingen, er is zo veel goeds op de markt
  7. Richt je CD pipeline in alsof het de meest kritische software is

Suggestie 1: Voorkom de creatie van een monoliet

Applicaties als monolieten zijn mogelijk ergens achterin je IT landschap nog best wel hanteerbaar. Hoe meer je naar de voorkant gaat en interactie zoekt met je klanten hoe meer last je krijgt van die grote monolieten in je landschap. Ze kunnen je wendbaarheid soms lastig in de weg zitten.

Ga je aan de slag met het maken van een CD pipeline bedenk dan goed dat deze pipeline misschien wel DE omgeving is die het hardste gaat veranderen in de komende tijd. Tools komen en gaan, frameworks dwingen je om je aan te passen en compliancy zit niet alleen meer bij een afdeling maar is als zuurstof voor je organisatie geworden. Een monoliet is maar weinig wendbaar weten we uit het verleden. Voorkom dus de creatie van een CD Pipeline als monoliet.

Suggestie 2: Balanceer tussen verplichte en vrijwillige componenten

Elke organisatie of het nu een verzekeraar, bank of overheid is ontkomt niet aan bepaalde verplichtte nummertjes. Mijn suggestie is dan ook om je pipeline met een dubbele focus in te richten.

Een zo klein als mogelijk verplicht component waarin je diverse zaken afvangt. Je kunt hier denken aan version control, 4-eye principle, peer review en secure code review. Je ontkomt er eenvoudigweg niet aan om al je code op weg naar productie hier doorheen te halen. Zie dit als de peper en zout die de basis vormen van de smaak aan je gerecht. User access management op je CD-Pipeline zou ook langs deze route moeten lopen.

Het vrijwillige deel zou veel meer modulair moeten zijn. Mensen moeten hier kunnen  kiezen uit een set van tools die je eenvoudig koppelt in je pipeline. Niet elk team wil dezelfde performance test tool bijvoorbeeld. Afhankelijk van je technology, het moment waarop je wilt testen en de volwassenheid van je team wil je bijvoorbeeld kunnen kiezen uit 5 verschillende performance test tools. Door er verschillende aan te bieden geef je teams keuze, door ze centraal te beheren reduceer je de lasten van beheer en kun je ook een community opbouwen.

Suggestie 3: Benader een CD pipeline niet als een verzameling tech tools maar als een value stream

Het is van groot belang voortdurend je CD Pipeline te optimaliseren. Je moet een pipeline dan ook niet zien als een verzameling tech tools die wat magisch doet. Zie het als een value stream. Door je doorlooptijden te visualiseren ga je ontdekken waar de volgende optimalisatie moet plaatsvinden. Een gevisualiseerde pipeline zorgt er daarnaast voor dat hij veel meer gaat leven bij de teams.

Hoe korter een release duurt van een “Merge in Master” naar “Deployment in Production” hoe sneller je feedback gaat stromen op de diverse lagen. Daarnaast wordt de drempel daarmee lager en lager om ook bij een emergency fix je code volledig door de pipeline te halen.

Suggestie 4: Gebruik de MVP approach in de opbouw van je pipeline

Heb niet de illusie dat je een pipeline in een paar dagen bouwt, of teams die geheel onbekend zijn heel eenvoudig op een complexe pipeline kan onboarden. Door een flexibele schil te hebben kun je starten met de verplichtte basis en keer op keer vrijwillige componenten toevoegen.

Het is net alsof je aan het koken bent. Als je start koop je een Honig pakje met alles er op en er aan, groei je verder dan koop je losse kruiden en volg je het recept. Ben je naar expert level aan het groeien en snap je wat kruiden doen dan kun je zelf variëren en zelf experimenteren.

Suggestie 5: Omarm een model waarin experimenten eenvoudig te realiseren zijn

Ook in je pipeline moet je eenvoudig de mogelijkheid hebben om diverse experimenten naast elkaar te kunnen doen. Laten we eerlijk zijn naar elkaar, tools zijn als Romeinse keizers ze Komen op-Blinken-Verzinken. Je moet eenvoudig kunnen experimenteren door tools in bijvoorbeeld Docker containers te kunnen toevoegen en onderdeel te laten zijn van je pipeline zonder dat daarmee je basis proces vestoord wordt.

Een visuele samenvatting van de bovenstaande suggesties

 schaalbare continuous delivery pipeline

Suggestie 6: Limiteer het bouwen van eigen oplossingen, er is zo veel goeds op de markt

Wat moet ik hier nog meer over zeggen? Het is mijn overtuiging dat het bouwen van eigen tools bouwen voor (in) je CD-Pipeline (nog) niet nodig is. Er is zoveel op de markt beschikbaar dat je robuuste pipelines kunt samenstellen die passen binnen de andere principes. Deze regel zal niet voor je opgaan als je doel is om nieuwe IT tools aan bedrijven te leveren.

Suggestie 7: Richt je CD pipeline in alsof het de meest kritische software is

Soms hoor ik nog wel eens de opmerking dat bij Prio 1 incidenten de pipeline wordt overgeslagen en een wijziging direct in productie wordt gezet. De pipeline of het proces daar omheen is te langzaam is dan het argument.

Het is mijn suggestie om je pipeline:
  • zo stabiel te maken dat het altijd werkt in welke kritieke situatie dan ook,
  • zo omvangrijk dat het je zekerheid geeft dat als de wijziging er doorheen komt de software ook echt goed is,
  • zo snel is dat er geen enkele verleiding is om een manueel proces te volgen.
Dit vraagt nog al wat van je pipeline als het gaat om je beschikbaarheid, je integriteit en betrouwbaarheid. Dat is waar een vaste kern (zie figuur 2) in je pipeline je kan helpen.

Heb jij nog andere suggesties die zorgen voor een stabiele en tegelijk schaalbare continuous delivery pipeline? Laat ze dan hieronder achter.

whatsapp meWil je een WhatsApp bericht ontvangen bij een nieuwe blog?
Stuur dan even een berichtje naar +31645112490