CI/CD de zéro

Automatiser tout ce qu'un humain oublie de vérifier.

Deux sigles, trois idées

Le flux

flowchart LR
  A[git push] --> B[Lint]
  B --> C[Types]
  C --> D[Tests]
  D --> E[Build]
  E --> F[Déploiement]

Si une étape échoue, la suite ne s'exécute pas.

Pourquoi c'est utile

• Les erreurs sont détectées minutes après leur introduction
• Les revues portent sur la logique, pas sur le style
• La branche principale reste toujours saine
• Chacun voit le même résultat, sur une machine propre

Un premier workflow

name: CI
on: [push, pull_request]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run check

Une commande, deux endroits

npm run check lance lint, types et tests.

• En local, avant de rendre la main
• En CI, à chaque push

Aucune dérive entre ce que vous testez et ce que la CI vérifie.

Que doit vérifier un pipeline ?

1. Le code compile
2. Le style est respecté (lint)
3. Les types sont cohérents
4. Les tests passent
5. L'application se construit
6. Pas de dépendance vulnérable

Les pièges classiques

• Pipeline trop lent : plus personne ne l'attend
• Tests instables : on finit par les ignorer
• Secrets affichés dans les logs
• Une CI rouge qu'on laisse rouge

À retenir

1. Commencez simple : une étape qui lance check
2. Gardez-la rapide et fiable
3. Ajoutez le déploiement quand la base est solide