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 build2. 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 pipeline4. 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 buildBashbash
# .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: 205. 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ème6. 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-allpar défaut - Timeout : ajouter
timeout-minutes: 10aux jobs - Pas de secrets en dur : toujours via
secrets.XXX - Documenter : un commentaire en haut du YAML expliquant le pipeline
- Tester le workflow : utiliser
actpour 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'aventureDéjà membre ?Connecte-toi