GitHub Actions avancé : secrets, matrices et déploiement

🎯 Objectifs

À la fin de ce module, vous serez capable de :

✅ Gérer les secrets et variables d'environnement
✅ Créer des pipelines multi-jobs avec dépendances
✅ Utiliser les matrices pour tester sur plusieurs versions
✅ Configurer des environnements (staging, production)
✅ Appliquer les stratégies de déploiement (blue-green, canary)

📋 Prérequis

Requis	Niveau
CI/CD Introduction	Complété
GitHub Actions Intermédiaire	Complété (module précédent)
Docker (images, registry)	Intermédiaire

🔐 Secrets et Variables

Ne jamais exposer un secret dans le code

yaml

# ❌ INTERDIT
env:
  API_KEY: "sk-1234567890abcdef"

# ✅ CORRECT
env:
  API_KEY: ${{ secrets.API_KEY }}

Configurer un secret

Settings → Secrets and variables → Actions
Cliquez New repository secret
Nommez-le (ex: DOCKER_PASSWORD) et entrez la valeur

Variables d'environnement

Trois niveaux de portée :

yaml

env:
  GLOBAL_VAR: "disponible partout"    # Niveau workflow

jobs:
  build:
    env:
      JOB_VAR: "disponible dans ce job" # Niveau job
    steps:
      - env:
          STEP_VAR: "disponible dans ce step" # Niveau step
        run: echo "$STEP_VAR"

⚠️ Les secrets sont masqués dans les logs - GitHub les remplace par ***.

🧮 Matrices (Matrix Strategy)

Testez votre code sur plusieurs versions et OS en une seule config :

yaml

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        node-version: [18, 20, 22]
        os: [ubuntu-latest, macos-latest]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

Cela crée 6 jobs (3 versions × 2 OS) automatiquement.

	ubuntu-latest	macos-latest
Node 18	✅ Job 1	✅ Job 2
Node 20	✅ Job 3	✅ Job 4
Node 22	✅ Job 5	✅ Job 6

💡 Ajoutez fail-fast: false pour continuer les autres jobs même si un échoue.

🌍 Environnements

Les environnements séparent staging et production avec des règles de protection.

yaml

jobs:
  deploy-staging:
    environment: staging
    runs-on: ubuntu-latest
    steps:
      - run: echo "Déploiement sur staging"

  deploy-production:
    environment: production
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - run: echo "Déploiement en production"

Règles de protection

Configurez dans Settings → Environments :

Règle	Description
Required reviewers	Approbation manuelle avant déploiement
Wait timer	Délai d'attente (ex: 5 min)
Branch restrictions	Seule `main` peut déployer en production
Secrets d'environnement	Secrets spécifiques à l'environnement

💡 Utilisez des secrets d'environnement pour avoir des credentials différents en staging et production.

📦 Artefacts

Les artefacts permettent de partager des fichiers entre jobs.

Upload un artefact

yaml

- uses: actions/upload-artifact@v4
  with:
    name: build-output
    path: dist/

Download un artefact

yaml

- uses: actions/download-artifact@v4
  with:
    name: build-output
    path: dist/

Cas d'usage typique

Build une seule fois, déployer l'artefact dans plusieurs environnements - évite de rebuild à chaque étape.

🔗 Pipeline Complet Multi-Jobs

Un pipeline réaliste avec dépendances entre jobs :

yaml

name: Pipeline Complet

on:
  push:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: app-build
          path: dist/

  deploy:
    needs: build
    if: github.ref == 'refs/heads/main'
    environment: production
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: app-build
      - run: echo "Déploiement en production..."

Flux d'exécution

lint → test → build → deploy
                        ↑
              (seulement sur main)

Mot-clé	Rôle
`needs: lint`	Le job attend que `lint` réussisse
`if: github.ref == '...'`	Condition d'exécution
`environment: production`	Active les règles de protection

🎯 Stratégies de Déploiement

Rolling Update

Remplace les instances une par une. C'est le défaut de Kubernetes.

[v1] [v1] [v1] → [v2] [v1] [v1] → [v2] [v2] [v1] → [v2] [v2] [v2]

Blue-Green

Deux environnements identiques. On déploie sur le green, puis on bascule le trafic.

Trafic → [Blue v1]    |  [Green v2] (déploiement)
Trafic → [Green v2]   |  [Blue v1] (standby)

Canary

Déploiement progressif - on augmente le trafic graduellement.

5% trafic  → v2  |  95% → v1
25% trafic → v2  |  75% → v1
100% trafic → v2

Comparaison

Stratégie	Downtime	Risque	Rollback	Complexité
Rolling	Aucun	Moyen	Moyen	Faible
Blue-Green	Aucun	Faible	Instantané	Moyenne
Canary	Aucun	Très faible	Rapide	Élevée

⚡ Cache et Performance

Mettre en cache les dépendances

yaml

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

Groupes de concurrence

Annulez les exécutions redondantes quand un nouveau push arrive :

yaml

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

💡 Cela évite de gaspiller des minutes d'exécution sur des commits intermédiaires.

🔔 Notifications

Envoyez une alerte Slack ou Discord en cas d'échec :

yaml

- name: Notifier Slack en cas d'échec
  if: failure()
  uses: slackapi/slack-github-action@v1
  with:
    payload: |
      {"text": "❌ Pipeline échoué sur ${{ github.repository }}"}
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

💡 if: failure() s'exécute uniquement quand un step précédent a échoué.

✅ Bonnes Pratiques

Pratique	Pourquoi
Pipelines < 10 min	Feedback rapide, développeurs contents
Fail fast - lint avant test	Échoue vite sur les erreurs simples
Épinglez les versions (`@v4`)	Évite les breaking changes
Branch protection rules	Empêche le merge sans CI verte
Secrets jamais dans le code	Sécurité de base
Cache les dépendances	Réduit le temps de build
Concurrency groups	Annule les runs obsolètes

📌 Points Clés

🔐 Les secrets se configurent dans les Settings GitHub, jamais dans le code
🧮 Les matrices testent automatiquement sur plusieurs versions/OS
🌍 Les environnements séparent staging et production avec des protections
📦 Les artefacts partagent des fichiers entre jobs
🔗 Le mot-clé needs crée des dépendances entre jobs
🎯 Choisissez votre stratégie de déploiement selon le risque acceptable

📚 Ressources

🚀 Prochaines étapes

Vous maîtrisez GitHub Actions. Découvrez une autre plateforme CI/CD majeure :

Créer son premier pipeline CI/CD avec GitLab CI - Pipelines, stages et jobs avec GitLab CI
Découvrir Kubernetes : pods, services et kubectl - Orchestrez vos conteneurs à l'échelle

GitHub Actions avancé : secrets, matrices et déploiement

🎯 Objectifs

À la fin de ce module, vous serez capable de :

✅ Gérer les secrets et variables d'environnement
✅ Créer des pipelines multi-jobs avec dépendances
✅ Utiliser les matrices pour tester sur plusieurs versions
✅ Configurer des environnements (staging, production)
✅ Appliquer les stratégies de déploiement (blue-green, canary)

📋 Prérequis

Requis	Niveau
CI/CD Introduction	Complété
GitHub Actions Intermédiaire	Complété (module précédent)
Docker (images, registry)	Intermédiaire

🔐 Secrets et Variables

Ne jamais exposer un secret dans le code

yaml

# ❌ INTERDIT
env:
  API_KEY: "sk-1234567890abcdef"

# ✅ CORRECT
env:
  API_KEY: ${{ secrets.API_KEY }}

Configurer un secret

Settings → Secrets and variables → Actions
Cliquez New repository secret
Nommez-le (ex: DOCKER_PASSWORD) et entrez la valeur

Variables d'environnement

Trois niveaux de portée :

yaml

env:
  GLOBAL_VAR: "disponible partout"    # Niveau workflow

jobs:
  build:
    env:
      JOB_VAR: "disponible dans ce job" # Niveau job
    steps:
      - env:
          STEP_VAR: "disponible dans ce step" # Niveau step
        run: echo "$STEP_VAR"

⚠️ Les secrets sont masqués dans les logs - GitHub les remplace par ***.

🧮 Matrices (Matrix Strategy)

Testez votre code sur plusieurs versions et OS en une seule config :

yaml

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        node-version: [18, 20, 22]
        os: [ubuntu-latest, macos-latest]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

Cela crée 6 jobs (3 versions × 2 OS) automatiquement.

	ubuntu-latest	macos-latest
Node 18	✅ Job 1	✅ Job 2
Node 20	✅ Job 3	✅ Job 4
Node 22	✅ Job 5	✅ Job 6

💡 Ajoutez fail-fast: false pour continuer les autres jobs même si un échoue.

🌍 Environnements

Les environnements séparent staging et production avec des règles de protection.

yaml

jobs:
  deploy-staging:
    environment: staging
    runs-on: ubuntu-latest
    steps:
      - run: echo "Déploiement sur staging"

  deploy-production:
    environment: production
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - run: echo "Déploiement en production"

Règles de protection

Configurez dans Settings → Environments :

Règle	Description
Required reviewers	Approbation manuelle avant déploiement
Wait timer	Délai d'attente (ex: 5 min)
Branch restrictions	Seule `main` peut déployer en production
Secrets d'environnement	Secrets spécifiques à l'environnement

💡 Utilisez des secrets d'environnement pour avoir des credentials différents en staging et production.

📦 Artefacts

Les artefacts permettent de partager des fichiers entre jobs.

Upload un artefact

yaml

- uses: actions/upload-artifact@v4
  with:
    name: build-output
    path: dist/

Download un artefact

yaml

- uses: actions/download-artifact@v4
  with:
    name: build-output
    path: dist/

Cas d'usage typique

Build une seule fois, déployer l'artefact dans plusieurs environnements - évite de rebuild à chaque étape.

🔗 Pipeline Complet Multi-Jobs

Un pipeline réaliste avec dépendances entre jobs :

yaml

name: Pipeline Complet

on:
  push:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: app-build
          path: dist/

  deploy:
    needs: build
    if: github.ref == 'refs/heads/main'
    environment: production
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: app-build
      - run: echo "Déploiement en production..."

Flux d'exécution

lint → test → build → deploy
                        ↑
              (seulement sur main)

Mot-clé	Rôle
`needs: lint`	Le job attend que `lint` réussisse
`if: github.ref == '...'`	Condition d'exécution
`environment: production`	Active les règles de protection

🎯 Stratégies de Déploiement

Rolling Update

Remplace les instances une par une. C'est le défaut de Kubernetes.

[v1] [v1] [v1] → [v2] [v1] [v1] → [v2] [v2] [v1] → [v2] [v2] [v2]

Blue-Green

Deux environnements identiques. On déploie sur le green, puis on bascule le trafic.

Trafic → [Blue v1]    |  [Green v2] (déploiement)
Trafic → [Green v2]   |  [Blue v1] (standby)

Canary

Déploiement progressif - on augmente le trafic graduellement.

5% trafic  → v2  |  95% → v1
25% trafic → v2  |  75% → v1
100% trafic → v2

Comparaison

Stratégie	Downtime	Risque	Rollback	Complexité
Rolling	Aucun	Moyen	Moyen	Faible
Blue-Green	Aucun	Faible	Instantané	Moyenne
Canary	Aucun	Très faible	Rapide	Élevée

⚡ Cache et Performance

Mettre en cache les dépendances

yaml

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

Groupes de concurrence

Annulez les exécutions redondantes quand un nouveau push arrive :

yaml

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

💡 Cela évite de gaspiller des minutes d'exécution sur des commits intermédiaires.

🔔 Notifications

Envoyez une alerte Slack ou Discord en cas d'échec :

yaml

- name: Notifier Slack en cas d'échec
  if: failure()
  uses: slackapi/slack-github-action@v1
  with:
    payload: |
      {"text": "❌ Pipeline échoué sur ${{ github.repository }}"}
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

💡 if: failure() s'exécute uniquement quand un step précédent a échoué.

✅ Bonnes Pratiques

Pratique	Pourquoi
Pipelines < 10 min	Feedback rapide, développeurs contents
Fail fast - lint avant test	Échoue vite sur les erreurs simples
Épinglez les versions (`@v4`)	Évite les breaking changes
Branch protection rules	Empêche le merge sans CI verte
Secrets jamais dans le code	Sécurité de base
Cache les dépendances	Réduit le temps de build
Concurrency groups	Annule les runs obsolètes

📌 Points Clés

🔐 Les secrets se configurent dans les Settings GitHub, jamais dans le code
🧮 Les matrices testent automatiquement sur plusieurs versions/OS
🌍 Les environnements séparent staging et production avec des protections
📦 Les artefacts partagent des fichiers entre jobs
🔗 Le mot-clé needs crée des dépendances entre jobs
🎯 Choisissez votre stratégie de déploiement selon le risque acceptable

📚 Ressources

🚀 Prochaines étapes

Vous maîtrisez GitHub Actions. Découvrez une autre plateforme CI/CD majeure :

Créer son premier pipeline CI/CD avec GitLab CI - Pipelines, stages et jobs avec GitLab CI
Découvrir Kubernetes : pods, services et kubectl - Orchestrez vos conteneurs à l'échelle

GitHub Actions avancé : secrets, matrices et déploiement

🎯 Objectifs

📋 Prérequis

🔐 Secrets et Variables

Ne jamais exposer un secret dans le code

Configurer un secret

Variables d'environnement

🧮 Matrices (Matrix Strategy)

🌍 Environnements

Règles de protection

📦 Artefacts

Upload un artefact

Download un artefact

Cas d'usage typique

🔗 Pipeline Complet Multi-Jobs

Flux d'exécution

🎯 Stratégies de Déploiement

Rolling Update

Blue-Green

Canary

Comparaison

⚡ Cache et Performance

Mettre en cache les dépendances

Groupes de concurrence

🔔 Notifications

✅ Bonnes Pratiques

📌 Points Clés

📚 Ressources

🚀 Prochaines étapes

Exercices Pratiques

GitHub Actions avancé : secrets, matrices et déploiement

🎯 Objectifs

📋 Prérequis

🔐 Secrets et Variables

Ne jamais exposer un secret dans le code

Configurer un secret

Variables d'environnement

🧮 Matrices (Matrix Strategy)

🌍 Environnements

Règles de protection

📦 Artefacts

Upload un artefact

Download un artefact

Cas d'usage typique

🔗 Pipeline Complet Multi-Jobs

Flux d'exécution

🎯 Stratégies de Déploiement

Rolling Update

Blue-Green

Canary

Comparaison

⚡ Cache et Performance

Mettre en cache les dépendances

Groupes de concurrence

🔔 Notifications

✅ Bonnes Pratiques

📌 Points Clés

📚 Ressources

🚀 Prochaines étapes

Exercices Pratiques