Déploiement et stratégies

Déploiement et stratégies

1. Environnements et configuration

   Un environnement est un déploiement avec ses propres données et sa propre configuration. Trois environnements minimum : développement, préproduction, production.

   La règle : le même artefact est déployé partout. Reconstruire par environnement casse la reproductibilité — ce qui est validé en préproduction n'est alors plus l'artefact qui part en production.

   Configuration par variable d'environnement

   Le code ne contient ni clé ni adresse de production : il lit des variables, injectées par la plateforme selon l'environnement.

   # developpement, dans un fichier local non versionne
   DATABASE_URL=postgresql://localhost:5432/app
   
   # production, dans les variables de l'hebergeur
   DATABASE_URL=postgresql://...:...@db.interne:5432/app

   Ce qui change d'un environnement à l'autre : adresses, identifiants, seuils, activation de fonctionnalités. Ce qui ne change pas : le code et la version de l'artefact.

2. Stratégies de déploiement

   Choisir une stratégie, c'est choisir un compromis entre la rapidité du retour arrière et la disponibilité pendant la bascule.

   Stratégie	Principe	Retour arrière
   Arrêt / démarrage	on arrête, on met à jour, on démarre	immédiat mais coupure de service
   Défilant (rolling)	instances remplacées par lots successifs	possible tant qu'aucun lot n'est terminé
   Bleu / vert	deux environnements identiques, bascule du trafic	immédiat, on rebascule le trafic
   Canari	petite fraction du trafic vers la nouvelle version	on retire les canaris, effet local

   Migrer la base : le vrai piège

   Le déploiement du code est réversible ; une migration de base ne l'est pas toujours. Trois règles :

   1. Compatible dans les deux sens : la nouvelle version du code doit fonctionner avec l'ancien schéma, et l'ancienne avec le nouveau.
   2. En deux temps : on ajoute ce qui manque (colonne, table), on déploie le code qui l'utilise, puis on supprime l'ancien élément au déploiement suivant.
   3. Sauvegarde vérifiée avant toute migration destructive, et restauration testée.

   Une migration destructive dans le même déploiement que la mise à jour du code, c'est le meilleur moyen de ne pas pouvoir revenir en arrière.

3. Retour arrière et bascule progressive

   Le retour arrière doit avoir été préparé avant le déploiement : c'est une décision et une procédure, pas une improvisation.

         - name: Déployer la version preparee
           run: kubectl apply -f manifeste.yaml
   
         - name: Vérifier la sante
           run: ./verification-sante.sh
   
         - name: Revenir en arriere si la verification echoue
           if: failure()
           run: kubectl rollout undo deployment/mon-service

   Le déploiement progressif consiste à étaler la bascule : une fraction du trafic d'abord, on observe, puis on élargit. L'observation porte sur des signaux métier — taux d'erreur, latence, et si possible une métrique qualitative du produit — pas seulement sur « le processus répond ».

   Runbook

   Un runbook écrit avant l'incident vaut dix minutes gagnées pendant : dernière version saine, commande de retour arrière, personnes à prévenir, critères de décision. Il doit être dans le dépôt, versionné comme le reste.

4. Exercices

   1. Scénario de migration : votre table a une colonne telephone à supprimer et une table factures à créer. Écrivez les étapes de déploiement dans l'ordre, en indiquant à chaque fois ce qui reste réversible.
   2. Runbook : écrivez le runbook de retour arrière de votre application, en moins d'une page.
   3. Stratégie : pour un site à fort trafic, quelle stratégie choisissez-vous, et quel indicateur vous ferait basculer sur l'autre ?