CI/CD-pipeline met Docker en een Git branching-strategie

In deze post ga ik in op het beheren van een CI/CD-pipeline met Docker, met de nadruk op een Git branching-strategie met een development- (DEV), staging- (STAGING) en production-branch (LIVE). Het doel is duidelijk maken welke rol elke branch speelt in het proces, en vooral hoe Docker-artifacts binnen dat stramien worden aangemaakt en beheerd.

Docker-deployments met Git Flow en meerdere branches

De kern van onze branching-strategie bestond uit drie branches:

DEV: Hier gebeurt alle ontwikkeling. Elke nieuwe feature, bugfix of verbetering start in een feature branch, afgesplitst van DEV. Is het werk af, gereviewd en voldoet het aan de Definition of Done (DoD), dan wordt het gemerged naar DEV.
STAGING: Deze branch spiegelt een pre-productieomgeving. Hier worden geïntegreerde features uit DEV als geheel getest en door stakeholders geaccepteerd, zodat we zeker weten dat alles samenwerkt.
MASTER: De branch die de huidige staat van onze live-omgeving weerspiegelt. Alleen grondig geteste en door stakeholders goedgekeurde wijzigingen uit STAGING halen het tot Productie.

Git Branching and Branching StrategyIn this post, we will go over why branching is required, the difference between development, staging…

DEV CommunityPreetham

Dit was onze variant op een Git Flow-strategie, die we tot nu toe gebruikten. Zodra je met artifacts gaat werken, verandert dat allemaal terug naar een normale Git Flow-structuur. We hebben nog steeds omgevingen die draaien (Dev, Staging en Prod). Het echte verschil is dat code nu één keer gecommit wordt, in plaats van gemerged te worden naar een branch die op Staging of in Productie draait.

In plaats daarvan hebben we nu één branch, die we Main noemen. Daar wordt na een geslaagde code merge met Docker images een runnable artifact aangemaakt. Alles wat we op Staging of in Productie deployen is een specifieke versie van een eerder aangemaakt artifact.

Het grootste verschil: STAGING en PROD zijn geen branches meer waar je code in merged. Het zijn omgevingen geworden die een specifieke versie van een Docker image draaien. Dat brengt eigen uitdagingen met zich mee, zeker bij een hotfix. Hotfixen krijgt een eigen post, die je na deze kunt lezen. Ik loop het nu eerst stap voor stap door, zonder de hotfix erbij. Het is al omvangrijk genoeg zo.

Wat is een artifact?

Een Docker-artifact, vaak door elkaar gehaald met een Docker image, is een lichtgewicht, zelfstandig uitvoerbaar package dat alles bevat wat nodig is om een stuk software te draaien: de code, een runtime, libraries, omgevingsvariabelen en configuratiebestanden. Simpel gezegd: een snapshot van je applicatie én de omgeving eromheen, samen verpakt, klaar om overal gedeployed en gedraaid te worden waar Docker is geïnstalleerd. Zo weet je dat alles in verschillende omgevingen consistent werkt.

Het belang van de DoD bij het mergen van code

Een volledige en heldere Definition of Done (DoD) speelt in dit nieuwe proces een sleutelrol, zeker nu alle wijzigingen in één enkele branch gemerged worden die een Docker image moet opleveren die runnable en deployable is:

Kwaliteitsborging: De DoD zorgt dat alle wijzigingen — nieuwe features, verbeteringen en hotfixes — die terug in MAIN gemerged worden aan een consistent kwaliteitsniveau voldoen. Denk aan code quality checks, succesvol doorlopen geautomatiseerde tests en het volgen van security best practices.
Regressie voorkomen: Door de DoD toe te passen op alle merges naar MAIN voorkomt het team regressies en zorgt het dat nieuwe wijzigingen bestaande functionaliteit niet breken. Cruciaal voor de integriteit en stabiliteit van de codebase.
Deployments soepeler laten verlopen: Een duidelijke en volledige DoD maakt deployments makkelijker, omdat alleen volledig gecontroleerde, deploy-klare wijzigingen in MAIN gemerged worden. Zo verspil je geen resources aan het bouwen van Docker images met bugs of die helemaal niet werken, en dat levert efficiëntere en betrouwbaardere artifacts op.

Hier een grafische weergave van onze Git Flow-strategie en hoe die door de verschillende omgevingen loopt.

Artifacts aanmaken en beheren

De eerste voorwaarde om dit proces te laten werken: zodra een afgesplitste branch terug in MAIN gemerged wordt, start dat een geautomatiseerd proces in onze CI/CD-pipeline. Dit gebeurt er:

Geautomatiseerde tests: Eerst draaien de geautomatiseerde tests om te checken of de nieuwe wijzigingen aan onze kwaliteitsnormen voldoen. Cruciaal voor een stabiele branch.
Docker-artifact aanmaken: Zijn alle tests geslaagd, dan wordt er een Docker image (ons artifact) van de MAIN-branch gebouwd. MAIN is immers de enige branch die de laatste staat van alle afgeronde ontwikkeling vertegenwoordigt. Van daaruit genereren we artifacts die “shippable” producten kunnen worden.
Waarom MAIN voor Docker-artifacts?: Door artifacts op dit moment aan te maken vangen we integratieproblemen vroeg op. Omdat elke feature die in MAIN gemerged wordt als release-klaar wordt beschouwd, heb je door hier een artifact te genereren altijd een geteste en potentieel deploybare versie van je product bij de hand.

Van branches naar omgevingen

In traditionele Git-workflows staan branches als STAGING en PROD voor verschillende fasen in het ontwikkelproces, van testen tot productie. In een Docker-gecentreerde CI/CD-pipeline verschuift de focus: deze branches dienen niet langer voor code-integratie, maar als referentie voor deployment-omgevingen.

Deployen naar STAGING

Docker-artifacts aanmaken: zodra de ontwikkeling klaar is en gemerged is naar de MAIN-branch, wordt er automatisch een Docker-artifact aangemaakt. Dat artifact is een snapshot van je applicatie op dat moment, met alle wijzigingen die gemerged zijn.
Deployen in plaats van mergen: de rol van de STAGING-omgeving is om dit Docker-artifact te testen onder omstandigheden die sterk lijken op productie. In plaats van code van MAIN naar een STAGING-branch te mergen, deploy je het Docker-artifact naar een STAGING-omgeving. De code zelf beweegt dus niet tussen branches; het is de gecompileerde en gecontaineriseerde versie van je applicatie die getest wordt.
Het doel van STAGING: de STAGING-omgeving is essentieel voor uitgebreide tests, waaronder performance- en security-assessments. Het is een laatste check om te verifiëren dat alles werkt zoals verwacht in een productie-achtige omgeving, zonder je echte gebruikers direct te raken.

Naar productie

Goedkeuring van stakeholders: zodra je Docker-artifact grondig getest is in STAGING en goedgekeurd is door de stakeholders, is het klaar voor productie. Deze stap is cruciaal om te garanderen dat alle features, fixes en updates aan de nodige standaarden en verwachtingen voldoen.
Deployen naar productie: de overgang van STAGING naar PROD betekent dat je het geteste Docker-artifact deployt naar je productieomgeving. Dit deploymentproces garandeert consistentie: het exacte artifact dat in STAGING getest is, wordt naar PROD gedeployd. Zo zijn er geen verschillen tussen geteste en gedeployde code.

Belangrijkste punten

Geen branch-merges meer voor deployment: in deze gestroomlijnde workflow worden STAGING- en PROD-branches niet meer gebruikt om code te mergen. In plaats daarvan verwijzen ze naar specifieke deployment-omgevingen waar Docker-artifacts voor tests en productie gedeployd worden.
Focus op artifacts: de nadruk ligt op het aanmaken, testen en deployen van Docker-artifacts. Deze artifacts vertegenwoordigen stabiele versies van je applicatie, klaar voor STAGING en uiteindelijk voor PROD.
Consistentie en betrouwbaarheid: door hetzelfde Docker-artifact van STAGING naar PROD te deployen, weet je zeker dat wat getest is exact is wat er uitgebracht wordt. Dat vergroot de betrouwbaarheid en voorspelbaarheid van je deployments.

Deze aanpak vereenvoudigt het deploymentproces, verkleint het risico op fouten en zorgt ervoor dat elke release grondig getest wordt in een omgeving die productie zo nauw mogelijk benadert.

Zijn meerdere branches nog nodig?

In deze nieuwe workflow hebben de STAGING- en PROD-branches in de Git branching strategy geen actieve functie meer en zijn ze dus overbodig geworden. Ze hielpen om bij te houden welke versies van de code naar welke omgeving gedeployd waren. Dat probleem hebben we nu opgelost door een specifieke versie van een artifact te draaien.

Conclusie

Door Docker op te nemen in onze Git branching strategy stroomlijnen we het hele traject van development tot deployment: elke merge naar MAIN triggert een Docker-image met de potentie om naar productie te gaan. De sleutel van deze strategie is het vroeg in de developmentcyclus aanmaken van Docker-artifacts, zodat continuous integration en delivery mogelijk blijven zonder in te leveren op kwaliteit en stabiliteit.

Door de veranderingen aan de Git-branches te begrijpen en het proces van het aanmaken en deployen van Docker-artifacts, kunnen we met vertrouwen omgaan met de complexiteit van CI/CD. Zo leveren we alle nieuwe features en fixes zo efficiënt en betrouwbaar mogelijk af bij de gebruikers.

Hotfixes

We hebben het nog niet gehad over hotfixes. Zoals ik al zei, verdient dit een eigen post. Je leest hier alles over hotfixes en de valkuilen die daarbij komen kijken.