Exercice 04 : Implémenter des stratégies de déploiement

🎯 Objectifs

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

✅ Simuler un déploiement blue-green (deux slots, basculement du trafic)
✅ Implémenter un déploiement canary progressif par étapes
✅ Déclencher un rollback automatique si un health check échoue
✅ Utiliser concurrency: pour éviter les déploiements parallèles

Durée estimée : 30 min | Difficulté : ⭐⭐⭐⭐☆

📖 Contexte

Déployer directement sur 100% du trafic sans filet est risqué. Les stratégies de déploiement avancées réduisent ce risque :

Blue-Green : deux environnements identiques (blue = actif, green = nouveau). On déploie sur green, on valide, puis on bascule le trafic. Rollback instantané en repoussant vers blue.
Canary : déploiement progressif. On commence par 10% du trafic, on vérifie les métriques, puis on monte à 50%, puis 100%.

Ces stratégies peuvent être simulées dans GitHub Actions avec des jobs séquentiels et des health checks.

📋 Énoncé

Vous allez créer deux workflows : un déploiement blue-green avec bascule de trafic simulée, et un déploiement canary avec rollback automatique si le health check échoue.

Résultat attendu :

Le workflow blue-green déploie sur green, vérifie, puis bascule
Le workflow canary s'arrête et effectue un rollback si un health check échoue
concurrency: empêche deux déploiements de tourner simultanément

🧭 Déroulement

Tâche 1 : Configurer la concurrence du workflow

Ajoutez un bloc concurrency: au niveau du workflow pour annuler les runs précédents si un nouveau déploiement est déclenché.

Indice :
`yaml
concurrency:
group: deploy-${{ github.ref }}
cancel-in-progress: true
`
Si deux pushs arrivent rapidement, le premier déploiement est annulé pour laisser la place au second. cancel-in-progress: false (défaut) mettrait le second en file d'attente.

Vérification : En déclenchant deux runs rapidement, le premier passe en statut "Cancelled".

Tâche 2 : Implémenter le déploiement blue-green

Créez un workflow avec deux jobs : deploy-green (déploiement sur le slot inactif) et switch-traffic (basculement du trafic vers green). Simulez les opérations avec des echo.

Indice :
`yaml
deploy-green:
runs-on: ubuntu-latest
steps:
- run: echo "Déploiement de la version ${{ github.sha }} sur le slot green"
- run: echo "Health check green... OK"

switch-traffic:
needs: deploy-green
runs-on: ubuntu-latest
steps:
- run: echo "Basculement du trafic : blue → green"
- run: echo "Green est maintenant actif"
`

Vérification : Le graphe du workflow affiche deploy-green → switch-traffic.

Tâche 3 : Ajouter un rollback en cas d'échec

Ajoutez un job rollback qui ne s'exécute que si deploy-green échoue. Il simule le retour vers le slot blue.

Indice :
`yaml
rollback:
needs: deploy-green
runs-on: ubuntu-latest
if: failure()
steps:
- run: echo "ROLLBACK : retour au slot blue (version stable)"
`
if: failure() sur un job vérifie si l'un des jobs dans needs: a échoué.

Vérification : En forçant un échec dans deploy-green, le job rollback s'exécute automatiquement.

Tâche 4 : Implémenter le déploiement canary

Créez un second workflow avec trois jobs séquentiels : canary-10 (10% du trafic), canary-50 (50%), canary-100 (100%). Chaque job simule un health check avec un délai.

Indice :
`yaml
canary-10:
runs-on: ubuntu-latest
steps:
- run: echo "Canary 10% - déploiement en cours"
- run: sleep 5 && echo "Health check 10% : OK"

canary-50:
needs: canary-10
runs-on: ubuntu-latest
steps:
- run: echo "Canary 50% - montée en charge"
- run: sleep 5 && echo "Health check 50% : OK"
`

Vérification : Les logs affichent l'avancement progressif du déploiement canary.

Tâche 5 : Rollback canary automatique

Ajoutez un job canary-rollback qui s'exécute si l'un des jobs canary échoue, et qui simule la remise à zéro du trafic vers la version stable.

Indice :
`yaml
canary-rollback:
needs: [canary-10, canary-50, canary-100]
runs-on: ubuntu-latest
if: failure()
steps:
- run: echo "ROLLBACK CANARY : retour à 0% sur la nouvelle version"
- run: echo "Trafic redirigé vers la version stable"
`

Vérification : En forçant l'échec de canary-50, le job canary-rollback s'exécute et les logs confirment le rollback.

🗂️ Mini-Projet : Pipeline de déploiement avec stratégie

yaml

# Checkpoints à valider :
# [ ] concurrency annule les runs en cours sur le même ref
# [ ] deploy-green → switch-traffic sont séquentiels
# [ ] rollback s'exécute si deploy-green échoue (if: failure())
# [ ] Le canary progresse en 3 étapes : 10% → 50% → 100%
# [ ] canary-rollback s'exécute si une étape canary échoue
# [ ] Bonus : ajoutez une approbation manuelle entre canary-50 et canary-100

Exercice 04 : Implémenter des stratégies de déploiement

🎯 Objectifs

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

✅ Simuler un déploiement blue-green (deux slots, basculement du trafic)
✅ Implémenter un déploiement canary progressif par étapes
✅ Déclencher un rollback automatique si un health check échoue
✅ Utiliser concurrency: pour éviter les déploiements parallèles

Durée estimée : 30 min | Difficulté : ⭐⭐⭐⭐☆

📖 Contexte

Déployer directement sur 100% du trafic sans filet est risqué. Les stratégies de déploiement avancées réduisent ce risque :

Blue-Green : deux environnements identiques (blue = actif, green = nouveau). On déploie sur green, on valide, puis on bascule le trafic. Rollback instantané en repoussant vers blue.
Canary : déploiement progressif. On commence par 10% du trafic, on vérifie les métriques, puis on monte à 50%, puis 100%.

Ces stratégies peuvent être simulées dans GitHub Actions avec des jobs séquentiels et des health checks.

📋 Énoncé

Vous allez créer deux workflows : un déploiement blue-green avec bascule de trafic simulée, et un déploiement canary avec rollback automatique si le health check échoue.

Résultat attendu :

Le workflow blue-green déploie sur green, vérifie, puis bascule
Le workflow canary s'arrête et effectue un rollback si un health check échoue
concurrency: empêche deux déploiements de tourner simultanément

🧭 Déroulement

Tâche 1 : Configurer la concurrence du workflow

Ajoutez un bloc concurrency: au niveau du workflow pour annuler les runs précédents si un nouveau déploiement est déclenché.

Indice :
`yaml
concurrency:
group: deploy-${{ github.ref }}
cancel-in-progress: true
`
Si deux pushs arrivent rapidement, le premier déploiement est annulé pour laisser la place au second. cancel-in-progress: false (défaut) mettrait le second en file d'attente.

Vérification : En déclenchant deux runs rapidement, le premier passe en statut "Cancelled".

Tâche 2 : Implémenter le déploiement blue-green

Créez un workflow avec deux jobs : deploy-green (déploiement sur le slot inactif) et switch-traffic (basculement du trafic vers green). Simulez les opérations avec des echo.

Indice :
`yaml
deploy-green:
runs-on: ubuntu-latest
steps:
- run: echo "Déploiement de la version ${{ github.sha }} sur le slot green"
- run: echo "Health check green... OK"

switch-traffic:
needs: deploy-green
runs-on: ubuntu-latest
steps:
- run: echo "Basculement du trafic : blue → green"
- run: echo "Green est maintenant actif"
`

Vérification : Le graphe du workflow affiche deploy-green → switch-traffic.

Tâche 3 : Ajouter un rollback en cas d'échec

Ajoutez un job rollback qui ne s'exécute que si deploy-green échoue. Il simule le retour vers le slot blue.

Indice :
`yaml
rollback:
needs: deploy-green
runs-on: ubuntu-latest
if: failure()
steps:
- run: echo "ROLLBACK : retour au slot blue (version stable)"
`
if: failure() sur un job vérifie si l'un des jobs dans needs: a échoué.

Vérification : En forçant un échec dans deploy-green, le job rollback s'exécute automatiquement.

Tâche 4 : Implémenter le déploiement canary

Créez un second workflow avec trois jobs séquentiels : canary-10 (10% du trafic), canary-50 (50%), canary-100 (100%). Chaque job simule un health check avec un délai.

Indice :
`yaml
canary-10:
runs-on: ubuntu-latest
steps:
- run: echo "Canary 10% - déploiement en cours"
- run: sleep 5 && echo "Health check 10% : OK"

canary-50:
needs: canary-10
runs-on: ubuntu-latest
steps:
- run: echo "Canary 50% - montée en charge"
- run: sleep 5 && echo "Health check 50% : OK"
`

Vérification : Les logs affichent l'avancement progressif du déploiement canary.

Tâche 5 : Rollback canary automatique

Ajoutez un job canary-rollback qui s'exécute si l'un des jobs canary échoue, et qui simule la remise à zéro du trafic vers la version stable.

Indice :
`yaml
canary-rollback:
needs: [canary-10, canary-50, canary-100]
runs-on: ubuntu-latest
if: failure()
steps:
- run: echo "ROLLBACK CANARY : retour à 0% sur la nouvelle version"
- run: echo "Trafic redirigé vers la version stable"
`

Vérification : En forçant l'échec de canary-50, le job canary-rollback s'exécute et les logs confirment le rollback.

🗂️ Mini-Projet : Pipeline de déploiement avec stratégie

yaml

# Checkpoints à valider :
# [ ] concurrency annule les runs en cours sur le même ref
# [ ] deploy-green → switch-traffic sont séquentiels
# [ ] rollback s'exécute si deploy-green échoue (if: failure())
# [ ] Le canary progresse en 3 étapes : 10% → 50% → 100%
# [ ] canary-rollback s'exécute si une étape canary échoue
# [ ] Bonus : ajoutez une approbation manuelle entre canary-50 et canary-100