CI/CD — intégrer et livrer en continu

1. Les notions — CI, CD, et l’autre CD

Sigle	Nom	La règle
CI	Intégration continue	Chaque push est construit et testé automatiquement. Une branche qui casse les tests ne se merge pas.
CD	Livraison continue (delivery)	Chaque version qui passe les tests est prête à déployer — le déploiement reste un choix humain.
CD	Déploiement continu (deployment)	Le choix humain disparaît : ce qui passe les tests part en production.

La CI répond à la question « est-ce que ce commit casse quelque chose ? » — et elle y répond en minutes, pas à la mise en production. C’est le facteur clé qui fait tomber le mur de la confusion : plus la boucle de retour est courte, moins un défaut coûte cher.

Schéma de la chaîne

Le schéma d’ensemble de la chaîne CI/CD de la formation est en préparation (demandé à Thibaut) — il sera inséré ici.

2. Anatomie d’un pipeline

Quel que soit l’outil, un pipeline se décompose pareil :

flowchart LR
    push[Push Git] --> lint[Lint] --> test[Tests] --> build[Build image] --> scan[Scan sécurité] --> deploy[Déploiement]

Brique	Rôle
Pipeline	L’enchaînement complet, déclenché par un événement (push, MR, tag, planification)
Étape (stage)	Un groupe ordonné : test ne démarre que si lint a réussi
Job	Une tâche concrète, exécutée dans un conteneur propre (Docker, encore lui)
Runner	La machine qui exécute les jobs
Artefact	Ce qu’un job produit et transmet au suivant (binaire, image, rapport)

3. GitLab CI — l’outil du module

Le pipeline vit dans .gitlab-ci.yml, à la racine du dépôt, versionné avec le code (le pipeline suit les branches, comme tout le reste).

stages: [test, build, deploy]

test:
  stage: test
  image: node:22-alpine          # chaque job démarre dans une image propre
  script:
    - npm ci
    - npm test

build:
  stage: build
  image: docker:27
  services: [docker:27-dind]
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

deploy:
  stage: deploy
  script: ./deploy.sh            # ou un déclencheur Dokploy — cf. GitOps
  environment: production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"   # on ne déploie que main

C’est exactement le mécanisme qui publie ce site : voir GitOps Workflow pour le pipeline réel de la documentation.

4. GitHub Actions — le même concept, vocabulaire décalé

GitLab CI	GitHub Actions
.gitlab-ci.yml (un fichier)	.github/workflows/*.yml (un fichier par workflow)
Pipeline	Workflow
Stage / job	Job / step
Runner	Runner
Include / template	Action réutilisable (place de marché)

name: ci
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4        # une "action" du marché
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm ci && npm test

La force de GitHub Actions est sa place de marché d’actions prêtes à l’emploi ; sa contrepartie est la chaîne d’approvisionnement : chaque uses: exécute du code tiers dans votre CI — épinglez les versions, lisez ce que vous importez.

5. Dagger — exécuter sa CI en local

Le supplice classique : corriger un .gitlab-ci.yml en poussant dix commits « fix ci » pour voir ce que dit le runner. Dagger attaque ce problème : le pipeline s’écrit en code (Go, Python, TypeScript) et s’exécute dans des conteneurs sur votre poste — exactement comme il s’exécutera chez le fournisseur de CI.

dagger call test        # le même pipeline, sur votre machine, avant de pousser

	.gitlab-ci.yml / workflow YAML	Dagger
S’exécute	Chez le fournisseur uniquement	En local et chez n’importe quel fournisseur
S’écrit en	YAML	Un vrai langage, testable
Verrouillage	Syntaxe propre à chaque plateforme	Le YAML se réduit à dagger call ...

À retenir pour le module : Dagger est l’illustration que la CI n’est qu’un programme — si votre pipeline ne tourne que sur le runner distant, c’est un problème de conception, pas une fatalité.

6. Écrire son premier scénario — la méthode

1. À la main d’abord. Déroulez la séquence complète dans un terminal (installer, tester, construire). Ce qui n’est pas reproductible à la main ne le sera pas en CI.
2. Un script par étape. Mettez chaque séquence dans un script versionné (scripts/test.sh) — le YAML doit rester un enchaînement d’appels, pas un programme.
3. Le squelette minimal. Un seul stage, un seul job, l’image la plus simple qui marche. Poussez, regardez-le passer au vert.
4. Ajoutez une étape à la fois. Lint, puis tests, puis build ; chaque ajout doit passer avant le suivant — votre pipeline suit la même discipline que votre code.
5. Verrouillez les règles. Quelles branches déclenchent quoi (rules:), qu’est-ce qui bloque un merge, qu’est-ce qui part en prod. C’est là que la CI devient une politique, plus un confort.

7. Autour de la chaîne — planifier et prévenir

La boucle DevOps ne commence pas au push et ne s’arrête pas au déploiement :

• Plane (auto-hébergeable) : la brique Plan — issues, cycles, roadmap. L’alternative open source à Jira, à côté des issues GitLab que vous utilisez déjà.
• Mattermost (auto-hébergeable) : la messagerie d’équipe où la chaîne parle — un webhook suffit pour que chaque pipeline raté, chaque déploiement, chaque alerte arrive dans le bon canal. C’est le début du ChatOps : l’état du système visible là où l’équipe discute, au lieu d’une boîte mail que personne ne lit.

Le point commun — et le fil rouge de la formation : auto-hébergeables, donc souverains.

Pour aller plus loin

• Xavki — playlists GitLab CI : du premier .gitlab-ci.yml aux runners
• Stéphane Robert — CI/CD et chaîne d’approvisionnement
• Dans ce wiki : GitOps (le pipeline réel de ce site), Dokploy (le déploiement), Dockhand (l’exploitation)