Exercice 08 : Projet Capstone - Pipeline de Déploiement avec Secrets, Matrices et Environnements

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

• ✅ Configurer des secrets dans GitHub et les injecter dans le pipeline
• ✅ Utiliser une matrice pour tester sur Node.js 18, 20 et 22 simultanément
• ✅ Créer des environnements (staging, production) avec des règles de protection
• ✅ Simuler un déploiement blue-green avec les sorties de jobs (outputs)
• ✅ Déclencher un workflow manuellement avec workflow_dispatch et des inputs

Durée estimée : 1h

Difficulté : ⭐⭐⭐⭐⭐ (Expert)

Prérequis :

• Exercices 06 et 07 complétés
• Module CI/CD Avancé complété (secrets, matrices, environnements, déploiement)

📖 Contexte

Votre application est prête pour la production. Vous devez maintenant mettre en place un pipeline de déploiement mature : tests multi-versions pour garantir la compatibilité, gestion sécurisée des secrets, environnements de staging et production avec protection, et stratégie de déploiement progressive.

📋 Énoncé

Construisez un pipeline complet test → build → deploy-staging → deploy-production avec matrice, secrets, et environnements protégés.

🧭 Déroulement de l'exercice

Tâche 1 : Configurer les secrets dans GitHub

Dans les settings du repository GitHub, créez les secrets suivants :

• REGISTRY_TOKEN : un token simulé (valeur : fake-token-12345)
• STAGING_URL : https://staging.monapp.dev
• PROD_URL : https://monapp.dev

Ajoutez également des variables (pas des secrets) :

• APP_NAME : devops-ci-demo
• DOCKER_REGISTRY : ghcr.io

Indice : Settings → Secrets and variables → Actions → "New repository secret". Les secrets sont masqués dans les logs (*). Les variables** sont visibles.

Vérification : Dans Settings → Actions secrets, les 3 secrets sont listés (valeurs masquées).

Tâche 2 : Créer un job de test avec matrice

Créez un job test-matrix qui teste l'application sur Node.js [18, 20, 22] simultanément. Chaque version tourne dans son propre runner en parallèle.

Indice :

`yaml

strategy:

matrix:

node-version: [18, 20, 22]

fail-fast: false

`

fail-fast: false permet à toutes les versions de terminer même si l'une échoue, pour avoir un rapport complet. ${{ matrix.node-version }} accède à la valeur courante de la matrice.

Vérification : Le workflow affiche 3 jobs test-matrix (18), test-matrix (20), test-matrix (22) qui s'exécutent en parallèle.

Tâche 3 : Injecter des secrets dans le job de build

Ajoutez un job build (après test-matrix) qui simule un push d'image Docker vers un registry privé. Injectez REGISTRY_TOKEN comme variable d'environnement. Vérifiez que le token est masqué dans les logs.

Indice : env: REGISTRY_TOKEN: ${{ secrets.REGISTRY_TOKEN }}. N'essayez jamais d'afficher directement un secret avec echo $SECRET - GitHub le masque automatiquement, mais c'est une mauvaise pratique. Utilisez echo "Token is set: $([ -n "$REGISTRY_TOKEN" ] && echo yes || echo no)".

Vérification : Dans les logs du job build, la valeur du token n'est jamais affichée en clair. Le log affiche Token is set: yes.

Tâche 4 : Créer les environnements avec protection

Dans GitHub Settings → Environments, créez 2 environnements :

• staging : aucune restriction (déploiement automatique)
• production : ajoutez un "Required reviewer" (vous-même)

Ajoutez un job deploy-staging qui référence l'environnement staging et simule un déploiement.

Indice : Dans le job, environment: staging crée une association avec l'environnement configuré dans GitHub. L'URL de l'environnement peut être définie avec url: ${{ secrets.STAGING_URL }}.

Vérification : Dans l'interface GitHub Actions, le job deploy-staging affiche un badge "Environment: staging" cliquable.

Tâche 5 : Implémenter le déploiement production avec approbation

Ajoutez un job deploy-production qui :

1. Dépend de deploy-staging
2. Référence l'environnement production
3. S'exécute uniquement sur main
4. Produit un output avec la version déployée

Indice : Comme l'environnement production a un reviewer requis, GitHub mettra le workflow en attente à ce job jusqu'à validation manuelle. Les outputs de job : outputs: deployed-version: ${{ steps.deploy.outputs.version }}.

Vérification : Le workflow se met en pause sur deploy-production avec un bouton "Review deployments". Après approbation, le job s'exécute.

Tâche 6 : Ajouter un déclencheur manuel avec workflow_dispatch

Ajoutez workflow_dispatch comme déclencheur avec deux inputs : environment (choix entre staging et production) et force-deploy (booléen). Adaptez la logique de déploiement en fonction de ces inputs.

Indice :

`yaml

workflow_dispatch:

inputs:

environment:

description: 'Environnement cible'

required: true

default: 'staging'

type: choice

options: [staging, production]

force-deploy:

description: 'Forcer le déploiement sans tests'

type: boolean

default: false

`

Accès : ${{ inputs.environment }}, ${{ inputs.force-deploy }}.

Vérification : Dans l'onglet Actions → ci.yml, un bouton "Run workflow" apparaît avec les champs de saisie.

🗂️ Mini-Projet : Pipeline de déploiement mature

Graphe du pipeline :

[test-matrix (18/20/22)] ──→ [build] ──→ [deploy-staging] ──→ [deploy-production ⏸️]
                                                                        ↑
                                                                 (approbation requise)

Checkpoints de validation :

• Les 3 jobs de la matrice s'exécutent en parallèle
• Le token dans les logs est masqué (***)
• deploy-staging est associé à l'environnement GitHub staging
• deploy-production se met en pause pour approbation
• Le bouton "Run workflow" est visible dans l'onglet Actions
• fail-fast: false permet de voir les résultats des 3 versions même si l'une échoue