Mijn deploymentpipeline heropbouwen

Ik heb de deploymentpipeline van deze blog opnieuw opgebouwd. De vorige setup bewees dat ik de site vanuit Forgejo kon bouwen en publiceren, maar ik wilde een duidelijkere flow voor dagelijks werk, releases en rollback.

De nieuwe opzet splitst die verantwoordelijkheden beter op. Developmentwijzigingen kunnen snel naar een lokale testomgeving, terwijl productiebuilds bewust worden gestart en gekoppeld zijn aan een specifieke commit hash.

Developmentdeploys

De development branch heeft nu een automatische deploymentroute. Wanneer ik naar development push, draait Forgejo de developmentworkflow, bouwt de Astro-site en deployt het resultaat naar een lokaal gehoste developmentomgeving.

Dat geeft mij een korte feedbackloop. Ik kan een wijziging pushen, de runner de build laten doen in een omgeving die dichter bij de echte pipeline ligt, en daarna het resultaat buiten mijn lokale machine controleren.

Het houdt development ook gescheiden van productie. De developmentomgeving mag vaak veranderen, omdat die bedoeld is om layoutproblemen, contentfouten, workflowproblemen en buildfouten te vinden voordat iets een release wordt.

Getriggerde productiebuilds

Productie begint nu op een bewuster punt. Zodra de laatste wijzigingen in main zijn gemerged, gebruik ik een trigger workflow in plaats van elke merge meteen de live site te laten publiceren.

Die workflow start een pipeline in een parent repository. De trigger geeft de branch, een optionele buildnaam en de commit hash mee die gebouwd moet worden. Als ik de hash leeg laat, kan de workflow de huidige head gebruiken, maar het belangrijkste is dat de releaseflow aan een specifieke source revision gekoppeld kan worden.

De parent pipeline neemt die hash, haalt de juiste source state op, maakt een verse build en pusht de output naar de build repository.

Buildhashes en rollback

De build repository is nu een onderdeel van het deploymentmodel. Ik denk niet meer alleen in termen van “deploy de laatste source”, maar kan een specifieke build repository hash deployen.

Dat is belangrijk voor rollback. Als een nieuwe build een probleem heeft, hoef ik niet het hele project opnieuw te bouwen of te gokken welke source state de vorige werkende site opleverde. Ik kan de deploymentpipeline naar een bekende buildhash laten wijzen en snel teruggaan.

Het maakt release testing ook eenvoudiger. Een build kan bestaan als concreet artifact voordat die de live versie wordt. Daardoor krijgt de pipeline een duidelijkere grens tussen sourcewijzigingen, buildoutput en deployment.

Wat nog volgt

De volgende grote stap is Docker images. Het systeem is nu al opgesplitst in developmentdeploys, getriggerde builds, buildopslag en deploy-by-hash, maar Docker moet het proces nog netter maken.

Met images kan ik de build- en deploymentomgeving verder standaardiseren, minder setup in elke workflow doen en de pipeline makkelijker verplaatsen of herhalen. Het zou ook performance moeten helpen zodra de herhaalde install- en toolingstappen kleiner worden.

Dat is het laatste grote stuk voordat dit deploymentsysteem compleet aanvoelt. De huidige versie geeft mij al veel meer controle dan de eerste pipeline: development is automatisch, productie is bewust, builds zijn adresseerbaar en rollback is geen speciaal geval meer.