Conception de Pipeline de Déploiement

Modèles architecturaux pour les pipelines CI/CD multi-étages avec portes d'approbation, stratégies de déploiement et flux de promotion d'environnements.

Objectif

Concevoir des pipelines de déploiement robustes et sécurisés qui équilibrent la rapidité et la sécurité par une organisation adéquate des étapes, des portes de qualité automatisées et des stratégies de livraison progressive. Cette compétence couvre à la fois la conception structurelle de l'architecture du pipeline et les modèles opérationnels pour des déploiements fiables en production.

Entrée / Sortie

Ce que vous fournissez

• Type d'application : Langage/runtime, conteneurisé ou bare-metal, monolithe ou microservices
• Cible de déploiement : Kubernetes, ECS, VMs, serverless ou plateforme en tant que service
• Topologie d'environnement : Nombre d'environnements (dev/staging/prod), disposition géographique, exigences d'air-gap
• Exigences de déploiement : Temps d'arrêt acceptable, SLA de rollback, besoins de division de trafic, préférence canary vs blue-green
• Contraintes de portes : Équipes d'approbation, seuils de couverture de test requis, scans de conformité (SAST, DAST, SCA)
• Stack de monitoring : Prometheus, Datadog, CloudWatch ou autres sources de métriques utilisées pour les décisions de promotion automatisées

Ce que produit cette compétence

• Configuration du pipeline : Définitions des étapes, dépendances de tâches, parallélisme et stratégie de cache
• Stratégie de déploiement : Modèle de déploiement choisi avec configuration annotée (poids canary, basculement blue-green, paramètres de rolling)
• Configuration des contrôles de santé : Sondes de readiness superficielles vs approfondies, scripts de smoke test post-déploiement
• Définitions des portes : Seuils de métriques automatisés et flux de travail d'approbation manuelle
• Plan de rollback : Déclencheurs de rollback automatisés et étapes du runbook manuel

Quand utiliser

• Concevoir l'architecture CI/CD pour un nouveau service ou une migration de plateforme
• Implémenter des portes de déploiement entre les environnements
• Configurer des pipelines multi-environnements avec scans de sécurité obligatoires
• Établir une livraison progressive avec des stratégies canary ou blue-green
• Déboguer les pipelines où les étapes réussissent mais le comportement en production est incorrect
• Réduire le MTTR en automatisant le rollback lors de la dégradation des métriques

Étapes du Pipeline

Flux de Pipeline Standard

┌─────────┐   ┌──────┐   ┌─────────┐   ┌────────┐   ┌──────────┐
│  Build  │ → │ Test │ → │ Staging │ → │ Approve│ → │Production│
└─────────┘   └──────┘   └─────────┘   └────────┘   └──────────┘

Détail des Étapes

1. Source - Récupération du code, résolution du graphe de dépendances
2. Build - Compilation, empaquetage, conteneurisation, signature des artifacts
3. Test - Tests unitaires, d'intégration, scans de sécurité SAST/SCA
4. Déploiement Staging - Déploiement en environnement staging avec smoke tests
5. Tests d'Intégration - Tests E2E, tests de contrat, baselines de performance
6. Porte d'Approbation - Porte manuelle ou automatisée basée sur métriques
7. Déploiement Production - Stratégie canary, blue-green ou rolling
8. Vérification - Contrôles de santé approfondis, monitoring synthétique
9. Rollback - Rollback automatique sur signaux d'erreur

Modèles de Portes d'Approbation

Modèle 1 : Approbation Manuelle (GitHub Actions)

production-deploy:
  needs: staging-deploy
  environment:
    name: production
    url: https://app.example.com
  runs-on: ubuntu-latest
  steps:
    - name: Deploy to production
      run: kubectl apply -f k8s/production/

Les règles de protection d'environnement dans GitHub imposent des relecteurs requis avant le démarrage de cette tâche. Configurez les relecteurs à Settings → Environments → production → Required reviewers.

Modèle 2 : Approbation basée sur le Temps (GitLab CI)

deploy:production:
  stage: deploy
  script:
    - deploy.sh production
  environment:
    name: production
  when: delayed
  start_in: 30 minutes
  only:
    - main

Modèle 3 : Approbations Multiples (Azure Pipelines)

stages:
  - stage: Production
    dependsOn: Staging
    jobs:
      - deployment: Deploy
        environment:
          name: production
          resourceType: Kubernetes
        strategy:
          runOnce:
            preDeploy:
              steps:
                - task: ManualValidation@0
                  inputs:
                    notifyUsers: "team-leads@example.com"
                    instructions: "Review staging metrics before approving"

Modèle 4 : Porte de Métrique Automatisée

Utilisez un AnalysisTemplate (Argo Rollouts) ou un script de porte personnalisé pour bloquer la promotion si les taux d'erreur dépassent un seuil :

# Argo Rollouts AnalysisTemplate — bloque automatiquement la promotion canary
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    interval: 60s
    successCondition: "result[0] >= 0.95"
    failureCondition: "result[0] < 0.90"
    inconclusiveLimit: 3
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(http_requests_total{status!~"5..",job="my-app"}[2m]))
          / sum(rate(http_requests_total{job="my-app"}[2m]))

Stratégies de Déploiement

Tableau de Décision

1. Déploiement Rolling

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2         # au maximum 12 pods pendant le déploiement
      maxUnavailable: 1   # au minimum 9 pods toujours en service

Caractéristiques : déploiement graduel, zéro temps d'arrêt, rollback facile, meilleur pour la plupart des applications.

2. Déploiement Blue-Green

# Basculer le trafic de blue à green
kubectl apply -f k8s/green-deployment.yaml
kubectl rollout status deployment/my-app-green

# Basculer le sélecteur de service
kubectl patch service my-app -p '{"spec":{"selector":{"version":"green"}}}'

# Rollback instantané si nécessaire
kubectl patch service my-app -p '{"spec":{"selector":{"version":"blue"}}}'

Caractéristiques : basculement instantané, rollback facile, double le coût d'infrastructure temporairement, bon pour les déploiements à haut risque avec temps de warm-up longs.

3. Déploiement Canary (Argo Rollouts)

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    canary:
      analysis:
        templates:
          - templateName: success-rate
        startingStep: 2
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 25
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100

Caractéristiques : décalage progressif du trafic, validation des métriques d'utilisateurs réels, promotion ou rollback automatisés, requiert Argo Rollouts ou une service mesh.

4. Feature Flags

from flagsmith import Flagsmith

flagsmith = Flagsmith(environment_key="API_KEY")

if flagsmith.has_feature("new_checkout_flow"):
    process_checkout_v2()
else:
    process_checkout_v1()

Caractéristiques : déployer sans libérer, tests A/B, rollback instantané par segment d'utilisateurs, contrôle granulaire indépendant du déploiement.

Orchestration du Pipeline

Exemple de Pipeline Multi-Étapes (GitHub Actions)

name: Production Pipeline

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image: ${{ steps.build.outputs.image }}
    steps:
      - uses: actions/checkout@v4
      - name: Build and push Docker image
        id: build
        run: |
          IMAGE=myapp:${{ github.sha }}
          docker build -t $IMAGE .
          docker push $IMAGE
          echo "image=$IMAGE" >> $GITHUB_OUTPUT

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Unit tests
        run: make test
      - name: Security scan
        run: trivy image ${{ needs.build.outputs.image }}

  deploy-staging:
    needs: test
    environment:
      name: staging
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to staging
        run: kubectl apply -f k8s/staging/

  integration-test:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - name: Run E2E tests
        run: npm run test:e2e

  deploy-production:
    needs: integration-test
    environment:
      name: production        # bloque ici jusqu'à l'approbation des relecteurs requis
    runs-on: ubuntu-latest
    steps:
      - name: Canary deployment
        run: |
          kubectl apply -f k8s/production/
          kubectl argo rollouts promote my-app

  verify:
    needs: deploy-production
    runs-on: ubuntu-latest
    steps:
      - name: Deep health check
        run: |
          for i in {1..12}; do
            STATUS=$(curl -sf https://app.example.com/health/ready | jq -r '.status')
            [ "$STATUS" = "ok" ] && exit 0
            sleep 10
          done
          exit 1
      - name: Notify on success
        run: |
          curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
            -d '{"text":"Production deployment successful: ${{ github.sha }}"}'

Contrôles de Santé

Endpoints de Santé Superficiels vs Approfondis

Un /ping superficiel retourne 200 même quand les dépendances en aval sont cassées. Utilisez une sonde de readiness approfondie qui vérifie les dépendances réelles avant de promouvoir le trafic.

# /health/ready — vérifie les vraies dépendances, utilisé par la porte du pipeline
@app.get("/health/ready")
async def readiness():
    checks = {
        "database": await check_db_connection(),
        "cache":    await check_redis_connection(),
        "queue":    await check_queue_connection(),
    }
    status = "ok" if all(checks.values()) else "degraded"
    code = 200 if status == "ok" else 503
    return JSONResponse({"status": status, "checks": checks}, status_code=code)

Script de Vérification Post-Déploiement

#!/usr/bin/env bash
# verify-deployment.sh — à exécuter après chaque déploiement en production
set -euo pipefail

ENDPOINT="${1:?usage: verify-deployment.sh <base-url>}"
MAX_ATTEMPTS=12
SLEEP_SECONDS=10

for i in $(seq 1 $MAX_ATTEMPTS); do
  STATUS=$(curl -sf "$ENDPOINT/health/ready" | jq -r '.status' 2>/dev/null || echo "unreachable")
  if [ "$STATUS" = "ok" ]; then
    echo "Health check passed after $((i * SLEEP_SECONDS))s"
    exit 0
  fi
  echo "Attempt $i/$MAX_ATTEMPTS: status=$STATUS — retrying in ${SLEEP_SECONDS}s"
  sleep "$SLEEP_SECONDS"
done

echo "Health check failed after $((MAX_ATTEMPTS * SLEEP_SECONDS))s"
exit 1

Stratégies de Rollback

Rollback Automatisé dans le Pipeline

deploy-and-verify:
  steps:
    - name: Deploy new version
      run: kubectl apply -f k8s/

    - name: Wait for rollout
      run: kubectl rollout status deployment/my-app --timeout=5m

    - name: Post-deployment health check
      id: health
      run: ./scripts/verify-deployment.sh https://app.example.com

    - name: Rollback on failure
      if: failure()
      run: |
        kubectl rollout undo deployment/my-app
        echo "Rolled back to previous revision"

Commandes de Rollback Manuel

# Lister l'historique des révisions avec annotations change-cause
kubectl rollout history deployment/my-app

# Rollback à la version précédente
kubectl rollout undo deployment/my-app

# Rollback à une révision spécifique
kubectl rollout undo deployment/my-app --to-revision=3

# Vérifier que le rollback est terminé
kubectl rollout status deployment/my-app

Pour les stratégies de rollback avancées incluant les rollbacks de migrations de base de données et les flux d'abandon d'Argo Rollouts, voir references/advanced-strategies.md.

Monitoring et Métriques

Métriques DORA clés à tracker

Vérification des Métriques Post-Déploiement

- name: Verify error rate post-deployment
  run: |
    sleep 60  # permettre aux métriques de s'accumuler

    ERROR_RATE=$(curl -sf "$PROMETHEUS_URL/api/v1/query" \
      --data-urlencode 'query=sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))' \
      | jq '.data.result[0].value[1]')

    echo "Current error rate: $ERROR_RATE"
    if (( $(echo "$ERROR_RATE > 0.01" | bc -l) )); then
      echo "Error rate $ERROR_RATE exceeds 1% threshold — triggering rollback"
      exit 1
    fi

Bonnes Pratiques du Pipeline

1. Échouer rapidement — Exécuter les vérifications rapides (lint, tests unitaires) avant les lentes (E2E, scans de sécurité)
2. Exécution parallèle — Exécuter les tâches indépendantes concurremment pour minimiser le temps total du pipeline
3. Cache — Mettre en cache les couches de dépendances et les artifacts de build entre les exécutions
4. Promotion d'artifacts — Construire une fois, promouvoir le même artifact dans tous les environnements
5. Parité d'environnement — Garder l'infrastructure de staging aussi proche que possible de la production
6. Gestion des secrets — Utiliser des magasins de secrets (Vault, AWS Secrets Manager, secrets chiffrés GitHub) — ne jamais coder en dur
7. Fenêtres de déploiement — Préférer les fenêtres à faible trafic ; imposer les périodes de gel des changements via les politiques de portes
8. Déploiements idempotents — S'assurer que réexécuter un déploiement produit le même résultat
9. Automatisation du rollback — Déclencher le rollback automatiquement sur l'échec du contrôle de santé ou du seuil de métrique
10. Annoter les déploiements — Envoyer des marqueurs de déploiement aux outils de monitoring (Datadog, Grafana) pour la corrélation

Dépannage

Le contrôle de santé réussit dans le pipeline mais le service n'est pas sain en production

Le contrôle de santé du pipeline frappe un endpoint /ping superficiel qui retourne 200 même quand la base de données est inaccessible. Utilisez un contrôle de readiness approfondie qui vérifie les vraies dépendances (voir la section Contrôles de Santé ci-dessus).

Le déploiement canary ne promeut jamais à 100%

Argo Rollouts requiert un AnalysisTemplate valide pour l'auto-promotion. Si la requête Prometheus retourne aucune donnée (ex. nom de métrique changé), l'analyse reste inconclusante et la promotion stagne. Ajoutez inconclusiveLimit pour que le déploiement échoue rapidement plutôt que de rester bloqué :

spec:
  metrics:
  - name: error-rate
    failureCondition: "result[0] > 0.05"
    inconclusiveLimit: 2   # échouer après 2 résultats inconclus, pas rester indéfiniment bloqué
    provider:
      prometheus:
        query: |
          sum(rate(http_requests_total{status=~"5.."}[2m]))
          / sum(rate(http_requests_total[2m]))

Le déploiement staging réussit mais le travail production ne commence jamais

Vérifiez que les règles de protection d'environnement production sont configurées — une assignation de relecteur manquante signifie que la porte d'approbation attend indéfiniment sans notification. Dans GitHub Actions, assurez-vous que Required reviewers est défini sur un utilisateur ou une équipe existante dans Settings → Environments → production.

Le cache de couche Docker est éjecté à chaque exécution causant des builds lents

Si COPY . . apparaît avant l'installation des dépendances, tout changement de fichier source invalide la couche de dépendance. Réorganisez pour copier d'abord les manifestes de dépendances :

# Bon : dépendances cachées séparément du code source
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

Le rollback laisse les migrations de base de données appliquées au code ancien

Un rollback de service sans un rollback de migration cause des erreurs de non-correspondance schéma/code. Toujours rendre les migrations rétro-compatibles (additives uniquement) pendant au moins un cycle de libération, et garder les scripts d'annulation versionnés aux côtés de la migration :

# migrations/V20240315__add_nullable_column.sql       (forward)
# migrations/V20240315__add_nullable_column.undo.sql  (backward)

Ne jamais exécuter de migrations destructives (DROP COLUMN, ALTER NOT NULL) jusqu'à ce que l'ancienne version du code soit complètement retirée de tous les environnements.

Sujets Avancés

Pour les configurations de pipeline spécifiques à la plateforme, les flux de promotion multi-régions et les modèles Argo Rollouts avancés, voir :

• references/advanced-strategies.md — Exemples YAML étendus, configurations spécifiques à la plateforme (GitHub Actions, GitLab CI, Azure Pipelines), modèles canary multi-régions et stratégies de rollback de migrations de base de données

Compétences Associées

• github-actions-templates - Pour les modèles d'implémentation GitHub Actions et les workflows réutilisables
• gitlab-ci-patterns - Pour l'implémentation de pipelines GitLab CI/CD
• secrets-management - Pour la gestion des secrets dans les pipelines CI/CD