Choisir un modèle de CI / CD peut être complexe et structurant pour garantir une stabilité et la sécurité de ses infras.
Elle doit s’intégrer dans les processus opérationnels sans ajouter des frictions et ralentir les équipes.
Dans cet article je vais vous présenter plusieurs façons de mettre en place une CI / CD sur son repo d’infrastructure et je pèserai ensuite leurs avantages et inconvénients.
De cette façon, vous pourrez faire le choix qui sera le plus aligné en fonction de vos contraintes et de votre projet.
Dans cet article nous partirons du principe que :
Le code de l’infrastructure est totalement séparé du code applicatif.
Il y a donc un ou plusieurs repos pour les composants applicatifs qui seront chargés de tester et release le code sous forme d’artefacts (image docker, binaire…) dans des registres et un repo dédié au code de l’infrastructure.
Le code de l’infrastructure contient un dossier par environnement et plusieurs sous layer de code pour respecter les pratiques GitOps et Terraform comme l’exemple montré ci-dessous :
master|main en branche de référence
Ce premier workflow consiste à définir la branche master|main comme étant la branche de référence du code. Chaque nouveauté sur le code est testée et validée lors d’une pull-request et appliquée automatiquement ou manuellement lors du merge sur la branche de référence.
Voici un résumé du comportement du workflow en lui-même :
Si push sur master :
- Pour chaque env/dossier :
- Job (Plan) : Vérifie si y a des changements à apply
- Job (Validate) : Valide que le code Terraform est fonctionnel
- Job (Apply) : Apply les modifs si y a des changements à appliquer.
^ Ce job aura un condition approval en fonction du nom de l'env
Si merge request :
- Pour chaque env :
- Job (Plan) : Vérifie si y a des changements à appliquer
- Job (Validate) : Valide que le code Terraform est fonctionnel
master est la single source of truth, tout ce qui n’est pas sur master peut être considéré comme du drift d’infrastructure