Denk je dat het correct is om het bouwen, testen en publiceren van de afbeelding in één workflow te combineren, evenals stappen toe te voegen voor deployment in verschillende omgevingen?

Dit is niet altijd optimaal. Hoewel een dergelijke aanpak handig kan zijn voor kleine projecten of lokale testbuilds, heeft het combineren van alle stappen in één workflow nadelen:

• Verminderde flexibiliteit: Deployments naar verschillende omgevingen (dev, staging, productie) vereisen verschillende parameters en vaak verschillende toegangsrechten. Het samenvoegen bemoeilijkt het beheer van deze verschillen.
• Afhankelijkheid van de omgeving: Als een deployment in een van de omgevingen faalt, wordt de hele build als mislukt beschouwd, zelfs als het maken van de afbeelding en de tests succesvol waren.
• Moeilijkheid van rollback: Het terugdraaien van een deployment wordt minder eenvoudig, omdat de hele workflow moet worden teruggedraaid.
• Toename in uitvoeringstijd: De hele pipeline duurt langer, wat de feedback voor ontwikkelaars vertraagt.
• Minder schaalbaarheid: Naarmate het project groeit en het aantal deployment-omgevingen toeneemt, wordt deze workflow onhandig en moeilijk te beheren.

Een meer gangbare en flexibele praktijk is het opsplitsen van deze fasen:

1. Build & Test Pipeline: Verantwoordelijk voor het bouwen van de code, testen, het maken van de afbeelding en het plaatsen in een artefact-repository (bijvoorbeeld Docker Registry, Nexus). Deze workflow wordt gestart bij elke commit of pull request.
2. Deployment Pipelines: Gescheiden workflows voor deployment naar elke omgeving. Ze halen de al gebouwde en geteste afbeelding uit de artefact-repository en implementeren deze in de doelomgeving. Deze workflows kunnen handmatig, volgens schema of automatisch worden gestart na succesvolle voltooiing van de vorige fase (bijvoorbeeld succesvolle deployment in staging).

Dit stelt je in staat om:

• Sneller feedback te krijgen over de codekwaliteit (build & test).
• Onafhankelijk te deployen naar verschillende omgevingen.
• De deploymentparameters voor elke omgeving flexibeler te beheren.
• Het rollback-proces te vereenvoudigen.

Een uitzondering kunnen kleine pet-projecten of monolithische applicaties zijn met een eenvoudig deploymentproces, waar de kosten van opsplitsing de voordelen overschrijden. Maar in de meeste bedrijfsomgevingen is het opsplitsen van workflows een best practice.