Cet article detaille l'installation et la configuration de GitLab CI/CD selon une approche industrialisee : reproductible, versionnee et prete pour la production des le depart.

Role : que fait GitLab CI/CD ?

GitLab CI/CD est le moteur d'integration et de livraison continues integre nativement a GitLab. Le pipeline est decrit dans un fichier .gitlab-ci.yml versionne, execute par des Runners (shell, Docker, Kubernetes). Il couvre tout le cycle DevSecOps : build, tests, SAST/DAST, conteneurisation, environnements dynamiques (review apps), deploiements multi-stages et Auto DevOps. Son integration registre/Container Registry, environnements et approbations en fait une plateforme de bout en bout, largement utilisee pour industrialiser des dizaines d'applications Spring Boot sur Kubernetes.

Cet article fait partie d'une serie de cinq consacree a GitLab CI/CD, abordant successivement les fondamentaux, l'installation, l'integration CI/CD, la production et le depannage. Chaque volet est autonome et orienté pratique d'ingenierie.

Installation et configuration

Une installation 'qui marche' ne suffit pas : viser des le depart une mise en place reproductible, versionnee et conforme aux contraintes de production.

Installer gitlab-runner (paquet ou binaire), l'enregistrer avec un token de projet/groupe, choisir l'executor adapte (Docker recommande). Bien maitrise, cet aspect reduit les interventions manuelles et securise les cycles de deploiement, ce qui est precisement l'objectif d'une demarche DevOps mature. La regle pratique est de rendre l'operation deterministe : memes entrees, meme resultat, quel que soit l'environnement. Neglige, ce point cree un point de defaillance unique et une dependance a la connaissance tacite d'un individu. On documente la decision et son contexte afin qu'un nouvel arrivant puisse la comprendre sans solliciter l'auteur. C'est precisement ce qui distingue une automatisation robuste d'un assemblage fragile de scripts difficilement maintenable. Il doit rester observable : expose en metriques et en alerting pour ne jamais sortir du champ de controle.

Configurer config.toml : concurrent, limites, tags des runners, volumes Docker, cache distribue S3 pour des builds rapides. Ignore, il devient une source recurrente d'incidents difficiles a tracer, car la cause racine est souvent loin du symptome observe. Le bon reflexe est de separer clairement configuration et code, et d'externaliser tout ce qui varie par environnement. L'absence de maitrise ici se paie en incidents de production et en perte de confiance dans la chaine de livraison. En mise en oeuvre, on commence par le formaliser dans un environnement de recette avant toute promotion vers la production. A l'echelle de dizaines d'applications, cet ecart de rigueur se traduit en jours d'exploitation economises chaque mois. Il gagne a etre standardise via un template, un role ou une bibliotheque partagee pour passer a l'echelle sans duplication.

Pour Kubernetes, deployer le GitLab Runner via Helm avec autoscaling des pods de build selon la file. C'est l'un des leviers les plus rentables pour fiabiliser des environnements multi-equipes ou la moindre divergence de configuration coute cher. Il convient d'appliquer le moindre privilege : n'accorder que les droits strictement necessaires a l'execution. Le danger est d'introduire une faille de securite ou une non-conformite qui ne sera detectee qu'a l'audit. La regle d'or est de valider ce comportement par un test automatise qui echoue explicitement en cas de regression. C'est aussi un facteur de serenite pour les equipes d'astreinte, qui passent moins de nuits sur des incidents evitables. Il se documente et s'accompagne d'un runbook : la connaissance operationnelle ne doit pas dependre d'une seule personne.

Definir un .gitlab-ci.yml minimal (stages, image par defaut, cache) puis enrichir par include de templates partages. Dans un contexte reglemente (bancaire / PCI DSS), c'est aussi une exigence d'auditabilite : ce qui n'est pas tracable n'est pas conforme. L'approche saine consiste a echouer vite et explicitement plutot qu'a masquer une erreur qui resurgira plus tard. Le risque, sinon, est une derive silencieuse de configuration entre environnements (le fameux 'ca marche chez moi'). Concretement, on l'inscrit dans la revue de code et dans la definition of done de l'equipe, pas dans une procedure orale. L'impact se mesure directement sur les indicateurs DORA : lead time, frequence de deploiement, taux d'echec des changements et MTTR. Cet element s'integre naturellement dans un pipeline industrialise, revu en code et versionne avec l'application.

Activer un cache distribue (S3/MinIO) et un registre proxy pour eviter de re-telecharger les dependances a chaque job. Ce point fait souvent la difference entre une plateforme que l'on subit et une plateforme que l'on pilote. Sur le plan operationnel, la mise en oeuvre doit etre idempotente : pouvoir etre rejouee sans effet de bord ni divergence d'etat. A defaut, on s'expose a des deploiements non reproductibles, impossibles a rejouer a l'identique en cas d'incident. On le rend mesurable : un indicateur dedie dans le tableau de bord permet d'en suivre l'evolution dans le temps. L'effet est tangible sur le temps de mise en production et sur la qualite percue par les equipes de developpement. Il se traite comme du code : versionne, teste, et promu a l'identique d'un environnement a l'autre, sans reconstruction.

Concepts et architecture

Avant toute mise en oeuvre, il faut un modele mental correct de GitLab CI/CD. Les points suivants constituent la base sans laquelle l'outil reste une boite noire fragile.

Le pipeline est un graphe de jobs groupes en stages ; par defaut les stages s'executent en sequence, les jobs d'un stage en parallele. Le negliger revient a accumuler une dette technique invisible jusqu'au jour ou elle bloque une livraison critique. Le principe directeur reste l'immuabilite : on remplace plutot qu'on modifie en place, ce qui rend chaque etat reproductible. Sans cette discipline, le rollback devient incertain, ce qui allonge dangereusement le temps de reprise en cas de panne. Le bon niveau d'automatisation consiste a ce qu'aucune action manuelle non tracee ne soit necessaire pour le garantir. Le retour sur investissement apparait des les premiers cycles de livraison automatises, puis se compose dans la duree. Il s'inscrit dans une demarche GitOps/DevSecOps de bout en bout, ou Git reste l'unique source de verite.

Les Runners executent les jobs : l'executor Docker fournit une image propre par job, l'executor Kubernetes provisionne un pod ephemere. Concretement, ce point conditionne la fiabilite et la reproductibilite de toute la chaine de livraison : un ecart ici se propage a l'ensemble des environnements. La regle pratique est de rendre l'operation deterministe : memes entrees, meme resultat, quel que soit l'environnement. Neglige, ce point cree un point de defaillance unique et une dependance a la connaissance tacite d'un individu. On documente la decision et son contexte afin qu'un nouvel arrivant puisse la comprendre sans solliciter l'auteur. La consequence est une plateforme plus previsible, plus sure et nettement moins couteuse a operer au quotidien. Il doit rester observable : expose en metriques et en alerting pour ne jamais sortir du champ de controle.

rules/only/except controlent quand un job s'execute (branche, tag, MR, changements de fichiers, variables). En pratique, c'est un facteur direct de stabilite en production et de reduction du temps de diagnostic lorsqu'un incident survient. Le bon reflexe est de separer clairement configuration et code, et d'externaliser tout ce qui varie par environnement. L'absence de maitrise ici se paie en incidents de production et en perte de confiance dans la chaine de livraison. En mise en oeuvre, on commence par le formaliser dans un environnement de recette avant toute promotion vers la production. C'est precisement ce qui distingue une automatisation robuste d'un assemblage fragile de scripts difficilement maintenable. Il gagne a etre standardise via un template, un role ou une bibliotheque partagee pour passer a l'echelle sans duplication.

needs cree un DAG : un job demarre des que ses dependances sont pretes, sans attendre tout le stage — pipelines plus rapides. Bien maitrise, cet aspect reduit les interventions manuelles et securise les cycles de deploiement, ce qui est precisement l'objectif d'une demarche DevOps mature. Il convient d'appliquer le moindre privilege : n'accorder que les droits strictement necessaires a l'execution. Le danger est d'introduire une faille de securite ou une non-conformite qui ne sera detectee qu'a l'audit. La regle d'or est de valider ce comportement par un test automatise qui echoue explicitement en cas de regression. A l'echelle de dizaines d'applications, cet ecart de rigueur se traduit en jours d'exploitation economises chaque mois. Il se documente et s'accompagne d'un runbook : la connaissance operationnelle ne doit pas dependre d'une seule personne.

Resume des commandes essentielles

Aide-memoire operationnel des commandes et configurations les plus utilisees au quotidien. Chaque entree indique la commande puis son role.

Cas concret (contexte projet)

Sur le projet Worldline OMS (modules XMLCONV, BWB Web Statements, FileNet Archiving), ce type de mise en oeuvre a permis d'industrialiser des pipelines multi-environnements (Dev/Recette/Prod) avec build, tests, packaging et rollbacks automatises, contribuant a la reduction de 40% du temps de deploiement. Le retour sur investissement apparait des les premiers cycles de livraison automatises, puis se compose dans la duree.

Synthese : bonnes pratiques

• Fail fast et stages ordonnes par cout ; lint et tests rapides avant build d'image.
• Un seul .gitlab-ci.yml lisible s'appuyant sur des templates testes et versionnes par tag.
• Immutabilite : taguer les images par CI_COMMIT_SHA et promouvoir le meme artefact d'un environnement a l'autre.
• Environnements declares pour tracabilite, approbations et rollback audit-friendly.
• Mesurer DORA metrics (lead time, deploy frequency, MTTR, change failure rate) a partir des donnees pipeline.

Conclusion

Maitriser GitLab CI/CD ne se limite pas a connaitre des commandes : il s'agit de l'integrer dans une demarche d'ingenierie reproductible, observable et securisee. Applique avec rigueur, GitLab CI/CD devient un levier mesurable de fiabilite et de velocite des cycles de livraison.