Pipeline GitHub Actions complet

Objectifs

À la fin de cette leçon, vous saurez :

• écrire un workflow CI/CD réel de bout en bout ;
• gérer les secrets et environnements ;
• conditionner le déploiement staging/production.

🔗 Pour vous rafraîchir la mémoire : package.json et scripts npm

Le workflow complet

# .github/workflows/ci.yml
name: CI/CD

on:
  push:
    branches: [main]
  pull_request:

jobs:
  qualite:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: npm }
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck --if-present
      - run: npm test

  image:
    needs: qualite
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

  deploy-staging:
    needs: image
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - name: Déploiement staging
        run: |
          ssh deployer@staging.monsite.fr \
            "cd /srv/app && ./deploy.sh ${{ github.sha }}"

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Déploiement production
        run: |
          ssh deployer@monsite.fr \
            "cd /srv/app && ./deploy.sh ${{ github.sha }}"

Lire ce pipeline

Le déploiement lui-même reste votre deploy.sh du chapitre manuel — la CI n'invente rien, elle exécute les mêmes étapes vérifiées.

Les secrets : ce qui va où

GITHUB_TOKEN            → fourni automatiquement (push vers ghcr.io)
SSH_PRIVATE_KEY         → secret GitHub, autorisé sur le serveur via authorized_keys
DATABASE_URL de prod    → JAMAIS dans GitHub : il vit dans /srv/app/.env

Règle absolue : la CI pousse le CODE ; les secrets de connexion restent SUR le serveur. Le pipeline connaît le chemin, pas les valeurs. Côté serveur, le compte deployer est restreint (ForceCommand ou droits sudo ciblés sur restart uniquement).

Environnements et approbations

Dans les settings GitHub, un environment peut exiger une approbation humaine :

staging     → déploiement automatique après CI verte
production  → attend une approbation manuelle (bouton Review)

C'est la garde-fou qui empêche « main cassée mais déployée quand même » : la prod ne reçoit qu'un code validé en staging ET approuvé.

Exercice

1. Créez ce workflow sur un repo de test ; observez chaque job.
2. Cassez volontairement un test : vérifiez que l'image ne se construit PAS.
3. Ajoutez l'environnement production avec approbation obligatoire.
4. Pourquoi tagger l'image avec le sha plutôt que latest ?

Résumé

• Chaîne qualité → image → staging → production, chaque maillon bloquant.
• Secrets : code en CI, valeurs sur serveur.
• Environments + approbation = prod jamais accidentelle.