Pipeline CI/CD pour une application Next.js : de la pull request à la production

Un pipeline CI/CD, c'est la chaîne automatisée qui transforme une modification de code en fonctionnalité en production. Bien conçu, il donne à l'équipe la confiance nécessaire pour livrer plusieurs fois par jour. Mal conçu, il devient une file d'attente de 40 minutes que tout le monde contourne.

Après avoir mis en place ce type de pipeline sur Azure DevOps et GitHub Actions, voici la structure que je recommande pour une application Next.js.

Les deux moitiés : CI et CD

• L'intégration continue (CI) vérifie chaque pull request : le code compile, respecte les conventions et ne casse rien.
• Le déploiement continu (CD) livre automatiquement le code fusionné : d'abord en prévisualisation, puis en production.

Étape 1 : les vérifications rapides

Les contrôles les moins coûteux passent en premier, pour échouer vite : lint, vérification des types et tests unitaires. Sur une application de taille moyenne, ils doivent tenir en moins de trois minutes. Ils peuvent tourner en parallèle.

# .github/workflows/ci.yml
name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm tsc --noEmit
      - run: pnpm test -- --ci

Étape 2 : le build et les tests end-to-end

Une fois les bases validées, on construit l'application (next build) puis on lance les tests end-to-end (Playwright) sur le build de production, pas sur le serveur de développement. C'est la seule façon de détecter les erreurs de rendu statique ou de configuration.

  e2e:
    needs: quality
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: pnpm }
      - run: pnpm install --frozen-lockfile
      - run: pnpm build
      - run: pnpm exec playwright install --with-deps chromium
      - run: pnpm exec playwright test
      - uses: actions/upload-artifact@v4
        if: failure()
        with: { name: playwright-report, path: playwright-report }

Conserver le rapport Playwright en artefact en cas d'échec fait gagner un temps précieux : on voit la trace, les captures et la vidéo du test qui a cassé.

Étape 3 : un environnement de prévisualisation par pull request

C'est la fonctionnalité qui change le plus la collaboration. Chaque pull request obtient sa propre URL (Vercel, Netlify ou Azure Static Web Apps le font nativement). Le product owner et le designer valident sur un vrai déploiement, avant la fusion, sans installer quoi que ce soit.

Étape 4 : la mise en production

• Déclenchée par la fusion sur `main`, jamais à la main depuis un poste de développeur.
• Les secrets (clés d'API, URL de base de données) sont stockés dans le gestionnaire de secrets de la plateforme CI, jamais dans le dépôt.
• Les migrations de base de données s'exécutent avant le déploiement du code et doivent rester compatibles avec la version précédente (ajouter une colonne avant de l'utiliser, supprimer après).
• Un retour arrière en un clic : garder les builds précédents permet de revenir en arrière en quelques secondes en cas de problème.

Garder un pipeline rapide

• Le cache : dépendances (cache: pnpm), cache de build Next.js (.next/cache) et navigateurs Playwright.
• La parallélisation : lint, types et tests unitaires dans des jobs séparés ; tests E2E répartis avec --shard.
• Le filtrage : dans un monorepo, ne tester que les projets impactés par la modification.
• `concurrency` : annuler automatiquement l'exécution précédente quand un nouveau commit est poussé sur la même branche.

Conclusion

Un bon pipeline n'est pas celui qui a le plus d'étapes, mais celui auquel l'équipe fait confiance. Des vérifications rapides en premier, des tests E2E sur le build réel, une URL de prévisualisation par pull request et un déploiement automatique réversible : avec ces quatre briques, livrer en production devient un non-événement.