Projet final : une chaîne DevOps complète du commit à la production

Ce que vous allez apprendre dans ce TP

• Enchaîner CI, sécurité et GitOps
• Vérifier et revenir en arrière automatiquement
• Mesurer la chaîne avec DORA

Introduction #

Ce que vous allez apprendre dans cette section

• Enchaîner CI, sécurité et GitOps
• Vérifier et revenir en arrière automatiquement
• Mesurer la chaîne avec DORA

Contexte. Vous présentez à votre direction une chaîne de livraison de bout en bout pour un nouveau service. Chaque étape reprend un TP de la formation ; l'objectif est de les enchaîner sans intervention manuelle entre le commit et le cluster.

Prérequis : un compte GitHub, Docker, kubectl et kind ; avoir suivi les TP Git, CI/CD, GitOps et DevSecOps  ·  Durée estimée : 120 min

Un commit sur main arrive en production en quelques minutes, de façon vérifiée, traçable et réversible.

Mise en place #

Étapes guidées, avec leur correction.

1. 1. Deux dépôts

   Pourquoi ? Séparer le code et la description du déploiement donne des droits et des historiques distincts.

   Créez shop-api (code, Dockerfile, tests, workflow) et shop-deploy (manifestes Kustomize base et overlays/staging, overlays/production). Protégez main sur les deux dépôts.

2. 2. Pipeline CI

   Pourquoi ? Le pipeline reprend les leçons du chapitre CI/CD : échouer vite, construire une fois, sécuriser.

   Dans shop-api, écrivez un workflow : lint et tests, Gitleaks et Trivy, build et push sur GHCR tagué par le SHA, SBOM et signature Cosign sans clé.

3. 3. Mise à jour automatique du dépôt de déploiement

   Pourquoi ? La CI n'a besoin que d'écrire dans Git : elle ne détient aucun accès au cluster.

   Ajoutez un job qui met à jour le tag de staging dans shop-deploy avec kustomize edit set image et pousse le commit (jeton à droits limités ou GitHub App).

4. 4. Déploiement GitOps

   Pourquoi ? Argo CD applique chaque commit du dépôt de déploiement et corrige toute dérive.

   Sur un cluster kind avec Argo CD (TP GitOps), créez deux Applications shop-staging et shop-production pointant vers les overlays, en synchronisation automatique.

5. 5. Vérifier et promouvoir

   Pourquoi ? La production reçoit exactement l'image validée en staging, par une pull request relue.

   Après synchronisation de staging, lancez un smoke test ; s'il réussit, ouvrez automatiquement une pull request qui reporte le même tag dans l'overlay de production.

6. 6. Incident et retour arrière

   Pourquoi ? Un retour arrière par Git est rapide, tracé et ne demande aucun accès au cluster.

   Livrez une version qui renvoie des erreurs 500 sur /health, constatez l'échec du smoke test en staging (pas de promotion), puis simulez un incident en production et revenez en arrière avec git revert dans shop-deploy. Rédigez un court post-mortem.

7. 7. Mesurer

   Pourquoi ? Les métriques DORA montrent si la chaîne tient ses promesses.

   Déployez cinq petites modifications et calculez la fréquence de déploiement, le délai commit → production, le taux d'échec et le temps de restauration (méthode du TP DORA). Présentez le résultat et la prochaine amélioration.

Niveau de difficulté : ●●●●○ (4/5)