CI/CD (1/5): principios y anatomía de un pipeline

1. CI, CD et CD #

Trois pratiques, souvent confondues.

Définitions #

La CI répond à « mon code s'intègre-t-il avec celui des autres ? », la livraison continue à « puis-je livrer maintenant ? », le déploiement continu supprime la question.

Pourquoi c'est rentable #

• Des lots plus petits : chaque déploiement change peu de choses, donc casse peu et se diagnostique vite.
• Un retour rapide : un développeur apprend en minutes qu'il a cassé quelque chose, pas en semaines.
• Un processus reproductible : la mise en production devient un non-événement.
• Des métriques DORA meilleures : fréquence de déploiement, délai, taux d'échec et temps de restauration.

2. Anatomie d'un pipeline #

Les étapes du commit à la production.

Les étapes #

Les briques techniques #

3. Les principes fondamentaux #

Ce qui rend un pipeline fiable.

Build once, deploy many #

On construit l'artefact une seule fois, on lui donne une version immuable (le SHA du commit), et c'est ce même artefact qui est testé puis promu de staging en production. Reconstruire pour la production, c'est déployer quelque chose qui n'a jamais été testé.

Erreur Courante : Une image taguée latest ou reconstruite par environnement casse la traçabilité : impossible de savoir exactement ce qui tourne en production ni de revenir à la version précédente.

Les autres règles #

1. Pipeline as code : la définition du pipeline est versionnée avec le code (.github/workflows, .gitlab-ci.yml, Jenkinsfile).
2. Échouer vite : les contrôles rapides d'abord, les plus longs ensuite.
3. Le pipeline rouge est prioritaire : on répare (ou on annule le commit) avant de continuer.
4. Configuration externe : l'artefact est identique partout, seule la configuration change (variables, secrets, 12 facteurs).
5. Reproductibilité : versions d'outils et de dépendances figées, runners éphémères.
6. Tout passe par le pipeline, y compris les correctifs urgents : sinon le pipeline cesse d'être la source de vérité.

4. Un premier pipeline #

La même logique avec deux outils.

GitHub Actions #

# .github/workflows/ci.yml
name: ci
on:
  push: { branches: [main] }
  pull_request: {}
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12", cache: pip }
      - run: pip install -r requirements.txt
      - run: pytest -q
  build:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t app:${{ github.sha }} .

GitLab CI #

# .gitlab-ci.yml
stages: [test, build]
test:
  stage: test
  image: python:3.12
  script:
    - pip install -r requirements.txt
    - pytest -q
build:
  stage: build
  image: docker:27
  services: [docker:27-dind]
  rules: [{ if: '$CI_COMMIT_BRANCH == "main"' }]
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .

Suite du chapitre : Les quatre leçons suivantes détaillent chaque partie : intégration continue et tests, artefacts et environnements, stratégies de déploiement, puis outils.