BaliseTonSite

Bonnes pratiques CI/CD

Les règles d'or pour un pipeline fiable, rapide et maintenable.

1. Pipeline rapide

Bashbash
# Objectif : pipeline < 5 minutes
# Chaque minute en plus = friction = moins de commits

# Techniques d'accélération :
# - Cache npm/pnpm (actions/setup-node cache: 'npm')
# - Paralléliser les jobs (lint | typecheck | tests en parallèle)
# - concurrency: cancel-in-progress pour éviter les doublons
# - Skip les étapes inutiles (deploy seulement sur main)
# - Utiliser des images plus légères (ubuntu-latest suffit)

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci
      - run: npm run lint

  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci
      - run: npx tsc --noEmit

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci
      - run: npm run test

  build:
    needs: [lint, typecheck, test]   # Attend les 3 jobs
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci
      - run: npm run build

2. Branch protection

Empêcher de merger du code cassé dans la branche principale :

  • Required status checks : le pipeline CI doit passer avant de merger
  • Required reviews : au moins 1 review approuvée
  • No force push : interdire les force push sur main
  • Linear history : forcer les merge via PR (pas de push direct)

3. Monorepo : filtrer les paths

Bashbash
# Ne déclencher le pipeline que si les fichiers concernés changent :
name: CI Frontend

on:
  push:
    branches: [main]
    paths:
      - 'frontend/**'          # Seulement si frontend/ change
      - '.github/workflows/**' # Ou si les workflows changent
  pull_request:
    paths:
      - 'frontend/**'

# Utile dans un monorepo :
# frontend/ -> pipeline frontend
# backend/  -> pipeline backend
# docs/     -> pas de pipeline

4. Workflows réutilisables

Bashbash
# .github/workflows/reusable-ci.yml
name: Reusable CI

on:
  workflow_call:
    inputs:
      working-directory:
        type: string
        default: '.'
      node-version:
        type: number
        default: 20

jobs:
  ci:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ${{ inputs.working-directory }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npx tsc --noEmit
      - run: npm run build
Bashbash
# .github/workflows/ci-frontend.yml
name: CI Frontend

on:
  push:
    paths: ['frontend/**']

jobs:
  ci:
    uses: ./.github/workflows/reusable-ci.yml
    with:
      working-directory: frontend
      node-version: 20

5. Matrix strategy

Bashbash
# Tester sur plusieurs versions de Node en parallèle :
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm run test

# Résultat : 3 jobs en parallèle (Node 18, 20, 22)
# Si l'un échoue, tu sais exactement quelle version pose problème

6. Bonnes pratiques générales

  • Nommer les steps : chaque step a un name: clair
  • Épingler les versions : actions/checkout@v4, pas @main
  • Limiter les permissions : permissions: read-all par défaut
  • Timeout : ajouter timeout-minutes: 10 aux jobs
  • Pas de secrets en dur : toujours via secrets.XXX
  • Documenter : un commentaire en haut du YAML expliquant le pipeline
  • Tester le workflow : utiliser act pour tester localement

7. Checklist pipeline production

  • Lint + TypeScript + Tests + Build dans le pipeline
  • Cache activé pour les dépendances npm
  • Concurrency configurée (cancel-in-progress)
  • Branch protection activée sur main
  • Secrets stockés dans GitHub Secrets (jamais dans le code)
  • Deploy conditionnel (seulement sur main, après tous les checks)
  • Preview deployments pour les PR
  • Notifications configurées (Discord, Slack ou email)
  • Timeout sur les jobs (éviter les pipelines infinis)
  • README avec badge de statut CI

Ce que tu as débloqué

  • Construire un pipeline rapide (< 5 min) avec parallélisme
  • Protéger la branche principale avec des rules GitHub
  • Filtrer les déclenchements par path (monorepo)
  • Créer des workflows réutilisables
  • Utiliser les matrix builds pour tester sur plusieurs versions
  • Appliquer la checklist pipeline production

Verifie tes acquis

5 questions pour valider ce chapitre

1. Quel est l'objectif de temps raisonnable pour un pipeline CI ?

Valide et sauvegarde ce chapitre

Ne perds pas le fil de ton apprentissage. Chaque QCM terminé sauvegarde ton score. Crée ton profil gratuitement pour débloquer toutes les évaluations du site et retrouver tes résultats plus tard.

Commencer l'aventure
Déjà membre ?Connecte-toi