Module 4 – Pipelines CI/CD et stratégie de déploiement

Les pipelines CI/CD orchestrent vos builds, tests, scans et déploiements. Ce module couvre GitHub Actions, GitLab CI et Jenkins avec stratégies de promotion et de qualité.

Objectifs

• Configurer des pipelines multi-étapes (build, test, sécurité, déploiement) pour une application de référence.
• Mettre en place des stratégies de promotion (dev → staging → prod) et des gates de qualité.
• Standardiser la configuration des runners et secrets pour une exécution reproductible.

1. Exemple GitHub Actions

name: ci-cd
on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: golangci/golangci-lint-action@v3
  test:
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: go test ./...
  build:
    runs-on: ubuntu-latest
    needs: test
    permissions:
      id-token: write
      contents: read
      packages: write
    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@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
  deploy-staging:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: staging
      url: https://staging.example.com
    steps:
      - uses: actions/checkout@v4
      - name: Promote via Argo CD
        run: argocd app sync webapp-staging --revision ${{ github.sha }}
  deploy-prod:
    runs-on: ubuntu-latest
    needs: deploy-staging
    environment:
      name: production
      url: https://app.example.com
    concurrency:
      group: prod-deploy
      cancel-in-progress: false
    steps:
      - name: Manual approval
        uses: softprops/action-gh-release@v1
        if: ${{ github.event_name == 'workflow_dispatch' }}
      - name: promote
        run: argocd app sync webapp-prod --revision ${{ github.sha }}

2. GitLab CI (auto DevOps)

stages:
  - lint
  - test
  - build
  - security
  - deploy
variables:
  DOCKER_DRIVER: overlay2
lint:
  stage: lint
  image: python:3.11
  script:
    - pip install yamllint
    - yamllint .
unit:
  stage: test
  image: golang:1.22
  script:
    - go test ./...
  coverage: '/total:\s+\(statements\)\s+(\d+\.\d+%)/'
container-image:
  stage: build
  image: gcr.io/kaniko-project/executor:latest
  script:
    - /kaniko/executor --context $CI_PROJECT_DIR --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
security:
  stage: security
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
prod:
  stage: deploy
  image: alpine:3.19
  when: manual
  environment:
    name: production
  script:
    - ./scripts/deploy.sh prod $CI_COMMIT_SHA

3. Jenkinsfile

pipeline {
  agent any
  environment {
    REGISTRY = "ghcr.io/acme/webapp"
  }
  stages {
    stage('Checkout') {
      steps { checkout scm }
    }
    stage('Lint & Test') {
      parallel {
        stage('Lint') { steps { sh './scripts/lint.sh' } }
        stage('Unit tests') { steps { sh 'go test ./...' } }
      }
    }
    stage('Build & Push') {
      when { branch 'main' }
      steps {
        sh 'docker build -t $REGISTRY:${GIT_COMMIT} .' 
        sh 'docker push $REGISTRY:${GIT_COMMIT}'
      }
    }
    stage('Deploy Prod') {
      when { branch 'main' }
      steps {
        input message: 'Deploy to production?', ok: 'Deploy'
        sh './scripts/deploy.sh prod ${GIT_COMMIT}'
      }
    }
  }
  post {
    success { slackSend channel: '#devops', message: "Build ${env.BUILD_NUMBER} succeeded" }
    failure { slackSend channel: '#devops', message: "Build ${env.BUILD_NUMBER} failed" }
  }
}

4. Gestion des secrets

• Utilisez OIDC ou Vault pour distribuer les credentials (évitez GITHUB_TOKEN longue durée).
• Sur GitLab : CI_JOB_TOKEN, variables protégées, masked.
• Jenkins : plugin Credentials + Shared Libraries.

5. Environnements et gates

• Créez des environnements GitHub/GitLab avec URL et approbations manuelles.
• Ajoutez des tests e2e post-déploiement : k6, postman/newman, pytest.
• Intégrer les tests de sécurité (Trivy, Snyk, Semgrep) et compliance (Checkov, tfsec) sur chaque merge request.

6. Lab guidé

1. Créer un pipeline GitHub Actions (ou GitLab/Jenkins) reprenant les étapes ci-dessus pour l’application web de référence.
2. Configurer des environnements staging/prod avec approbations manuelles.
3. Ajouter un job smoke test (scripts/smoke.sh) qui vérifie /healthz après déploiement.
4. Publier les rapports (coverage, tests, scanning) en artefacts, conserver 30 jours.
5. Mettre en place un tableau de bord (GitHub Insights / GitLab Value Stream) pour suivre DORA metrics.

Challenge optionnel

• Implémenter une stratégie canary avec Argo Rollouts déclenchée depuis la pipeline.
• Ajouter un job chaos test (LitmusChaos) dans la pipeline staging.
• Déployer Jenkins sur Kubernetes avec pipelines as code et agents dynamiques (kubernetes plugin).

Solution détaillée

1. Pipelines verts : chaque job (lint, test, build, security) doit réussir avant déploiement. Si Trivy détecte des vulnérabilités hautes, la pipeline doit échouer.
2. Déploiement : staging se promeut automatiquement; prod nécessite validation. Vérifiez l’URL de l’environnement.
3. Logs : conservez les logs pipelines et tests. Export possible avec gh run download ou gitlab-ci yml artifacts.
4. DORA metrics : configurez la collecte du lead time & fréquence de déploiement (GitLab natif, ou script StatsD).
5. Smoke test : ./scripts/smoke.sh renvoie 0. En cas d’échec, la pipeline doit stopper le déploiement prod.

Documentez la pipeline dans docs/pipeline.md avec capture d’écran des étapes.

Pièges fréquents

• Ne pas versionner les actions/plugins → builds non reproductibles.
• Secrets stockés en clair dans les workflows. Utilisez les secrétariats dédiés.
• Double-build : contrôlez que la pipeline ne build qu’une fois (évitez les déclenchements sur push + PR dupliqués).

Ressources

• GitHub Actions
• GitLab CI/CD
• Jenkins Pipeline

Checklist

• ✅ Pipeline multi-étapes opérationnelle.
• ✅ Gates de qualité et approbations manuelles configurées.
• ✅ Rapports (tests, scan) stockés en artefacts.
• ✅ DORA metrics suivis.