Pipeline : valider, builder, déployer

Prérequis (cursus dev) : git et versions, pipeline et déploiement, tests.

Pourquoi

Sans CI (intégration continue : chaque push est vérifié automatiquement), les erreurs se découvrent en prod ; sans CD (déploiement continu : la mise en prod est un non-événement), les déploiements sont des cérémonies stressantes du vendredi soir. Le pipeline rend les deux ennuyeux — et l'ennuyeux, en prod, c'est le bonheur.

Concepts

• MR (Merge Request, demande de fusion) : proposition de fusion d'une branche, relue avant intégration. Rien ne part en prod sans MR relue.
• Runner : l'agent qui exécute les jobs du pipeline. Un runner shell tourne directement sur une machine (ici le serveur, tag [stasis]) : il a Docker sous la main et déploie en local.
• Les trois étages : validate (lint, tests, build — à chaque push et MR, feedback en minutes), build_images (sur main : construit et pousse), deploy (uniquement sur tag vX.Y.Z : créer le tag, c'est la décision explicite « cette version part »).

Exemple

stages: [validate, build_images, deploy_production]
validate:
  script:
    - npm ci
    - npm run lint && npm run typecheck && npm test && npm run build
build_images:   # sur main : docker build + push registry/...:$VERSION
deploy_production:  # sur tag : pull + up -d + healthcheck

Version unique (package.json) : le pipeline refuse un tag v1.4.3 si le code dit 1.4.2 — garde-fou contre le « je croyais avoir bump ». Secrets en variables CI masquées, jamais en clair dans le YAML.

Cas réel

Pipeline qui déploie sur chaque push main « pour aller vite » : un commit de debug à 18h part sans relecture, casse le login, et personne ne sait quelle version tourne. Avec tag + version vérifiée, le même commit attend sagement son tag — et son relecteur.

Pièges

• Tags de runner mélangés (build et deploy sur les mêmes) : une MR peut déclencher un déploiement.
• validate qui ne teste pas vraiment (tests vides, lint désactivé) : du théâtre de sécurité.
• Déployer depuis une branche feature « juste pour voir » : c'est comme ça que la démo devient la prod.

À retenir

Valider toujours (MR relue), builder sur main, déployer sur tag versionné et vérifié.