IT Toolbox AI
CI/CD · Déploiement

Déploiement

Promouvez un artifact vers DEV, TEST, STAGING puis PROD avec une stratégie et des validations adaptées.

Leçon disponible
20 min

Objectifs

  • Distinguer les environnements DEV, TEST/REC, STAGING/PREPROD et PROD.
  • Comparer rolling, blue/green et canary.
  • Lire deux commandes Kubernetes de déploiement.
  • Séparer artifact, configuration, secrets et approbations.

Déploiement

Un deployment installe une version d’artifact et sa configuration dans un environment. DEV accélère le retour développeur, TEST ou REC valide l’intégration, STAGING ou PREPROD rapproche les conditions de production, et PROD sert les utilisateurs réels.

La progression ne doit pas recréer l’artifact. Elle applique une configuration explicitement versionnée ou gérée, injecte les secrets depuis un store et vérifie la santé après chaque étape.

Promotion entre environnements

Les validations deviennent généralement plus représentatives et plus strictes en approchant de PROD. Une approbation manuelle peut être utile pour une production critique, une fenêtre de changement ou une obligation réglementaire.

Chemin de promotion
Artifact
   ↓
DEV
   ↓
Tests
   ↓
STAGING
   ↓
Validation
   ↓
PROD

Rolling, blue/green ou canary

Le rolling deployment remplace progressivement les instances : il consomme peu de capacité supplémentaire, mais mélange temporairement deux versions. Blue/green prépare un environnement parallèle et bascule le trafic : le retour est rapide, au prix de ressources supplémentaires et d’une bascule maîtrisée.

Le canary expose d’abord une petite part du trafic à la nouvelle version : il limite l’impact initial et fournit des signaux réels, mais exige un routage, des métriques et des critères d’arrêt solides.

  • Rolling : progressif et courant, attention à la compatibilité entre versions.
  • Blue/green : bascule rapide, coût d’un environnement parallèle.
  • Canary : risque limité à une fraction du trafic, observabilité plus exigeante.
  • Aucune stratégie n’élimine le besoin de smoke tests et de rollback.

Exemple Kubernetes pédagogique

La première commande soumet le manifeste au cluster configuré ; la seconde attend l’état du rollout. Elles sont uniquement affichées et ne sont jamais exécutées par les tests.

Appliquer le manifeste
kubectl apply -f deployment.yaml
Suivre le rollout
kubectl rollout status deployment/myapp

Avant kubectl, vérifiez le contexte, le namespace, le diff, l’artifact référencé et vos autorisations. IT Toolbox AI ne contacte aucun cluster.

Séparer configuration et artifact

L’artifact reste identique ; la configuration varie de manière contrôlée selon l’environnement. Les secrets ne sont ni intégrés à l’image, ni écrits dans le manifeste public, ni affichés dans les logs.

  • Utiliser des références de versions immuables plutôt qu’un tag flottant.
  • Protéger PROD avec droits minimaux et approvals proportionnées au risque.
  • Vérifier readiness, erreurs, latence et métriques métier après déploiement.
  • Préparer le rollback avant la mise en production.

Mini résumé

  • DEV, TEST/REC, STAGING/PREPROD et PROD répondent à des validations différentes.
  • Rolling, blue/green et canary présentent des compromis de capacité, risque et complexité.
  • L’artifact reste identique tandis que configuration et secrets sont injectés séparément.
  • Approbations, observabilité et rollback s’adaptent à la criticité.

Outils associés

Générer un manifeste Kubernetes

Utilisez Kubernetes YAML Generator pour préparer localement une base de manifeste, puis faites-la relire avant tout déploiement.

Ouvrir l’outil

Construire une commande kubectl

Utilisez kubectl Command Builder pour composer une commande de déploiement ou de diagnostic sans contacter de cluster.

Ouvrir l’outil

Mini quiz

Trois questions pour vérifier les notions essentielles de la leçon.

1. Que fait un rolling deployment ?
2. Quel est l’intérêt principal d’un déploiement canary ?
3. Comment gérer la configuration entre STAGING et PROD ?