Préparez le retour arrière d’un déploiement : compatibilité des données, critères d’arrêt, responsabilités et répétition avant la production.
Remettre l’ancienne version du code ne suffit pas si la nouvelle a modifié les données qu’elle doit lire. Le plan de retour arrière doit décrire l’état dans lequel l’application retrouvera sa base, ses fichiers et ses échanges avec les autres services.
Cette question se pose dès qu’une livraison change un format ou une règle de traitement. Une petite équipe peut la traiter avec une fiche de déploiement courte, à condition d’en vérifier les étapes sur un environnement adapté.
Recenser les changements qui persistent
Avant la livraison, demandez ce qui restera après l’arrêt du nouveau code. Cela peut être une colonne renommée, un fichier écrit dans un nouveau format, un événement déjà envoyé ou une tâche en attente dans une file.
Inscrivez ces changements à côté de la version applicative. Un redéploiement ne retire pas automatiquement un email déjà envoyé ni une opération acceptée par un système extérieur. La reprise de ces effets demande une procédure métier distincte.
AWS recommande de préparer et tester les scénarios de changement infructueux dans sa pratique Plan for unsuccessful changes. La version de ce document est datée ; le principe utilisé ici est la préparation explicite du retour arrière ou de la correction en avant.
Maintenir une période de compatibilité
Prenons un exemple fictif : l’application remplace un champ libre adresse par plusieurs champs structurés. Si l’ancien programme dépend encore du champ libre, sa suppression immédiate peut empêcher tout retour à cette version.
Une approche possible consiste à ajouter les nouveaux champs, déployer une version capable de gérer la transition, puis effectuer la reprise des données. La suppression de l’ancien format vient après vérification des consommateurs et de la fenêtre de retour prévue.
Cette séquence demande un choix explicite sur les écritures. Quel format fait référence pendant la transition ? Comment éviter que deux versions modifient différemment la même adresse ? Les réponses dépendent de votre application ; recopier les données dans deux champs sans règle de cohérence ajoute une nouvelle source d’erreurs.
Écrire les critères de décision
Définissez les signaux que l’équipe surveillera après le déploiement. Reliez-les à un parcours : création de commande, ouverture d’un dossier ou synchronisation avec le CRM. Une page d’accueil accessible ne prouve pas que ces opérations fonctionnent.
| Décision | Information à préparer |
|---|---|
| Continuer l’observation | Durée prévue et personne chargée du suivi |
| Arrêter la progression | Signal d’alerte et composant concerné |
| Revenir au code précédent | Version cible et compatibilité vérifiée |
| Corriger en avant | Incident identifié et délai acceptable |
| Suspendre certaines écritures | Périmètre et consigne pour les utilisateurs |
Un seuil d’erreur doit être interprétable. Sur un petit volume, une seule opération peut changer fortement un pourcentage. Regardez les événements concernés et leur gravité, en plus de l’indicateur agrégé.
Répéter le scénario avec des données représentatives
En préproduction, installez l’ancienne version puis exécutez la migration et le nouveau programme. Faites fonctionner les parcours modifiés. Revenez ensuite selon la procédure prévue et contrôlez les opérations produites pendant la transition.
Incluez les traitements différés. Un message créé par la nouvelle version peut être consommé plus tard par l’ancienne. Si leur contrat diffère, le problème apparaîtra après un redémarrage apparemment réussi.
Consignez les versions exactes des composants et la durée de chaque étape. Pour les données sensibles, utilisez un jeu de test ou une copie préparée conformément aux règles de l’entreprise. La personne qui réalise l’essai doit disposer de droits comparables à ceux prévus pour l’intervention.
Distinguer retour du code et restauration des données
Restaurer une sauvegarde ramène les données à un état antérieur. Les opérations intervenues depuis cet état peuvent alors disparaître du système restauré tout en restant présentes ailleurs. Avant de choisir cette option, prévoyez comment les retrouver et les rapprocher.
Notre méthode de test de restauration aide à vérifier la récupération. Le plan de déploiement doit en plus préciser qui autorise une interruption et qui informe les utilisateurs concernés.
Pour une livraison à faible impact, la fiche peut rester brève. Pour une modification de données partagées, prévoyez une revue avec les responsables des applications consommatrices. Le temps consacré à cette préparation dépend du changement, pas du nombre de lignes de code.
Sky Vaults accompagne le cadrage des pipelines et des procédures de livraison dans son offre DevOps et cloud au Maroc. Décrivez-nous votre prochaine évolution, les systèmes qui lisent les mêmes données et les contraintes de disponibilité.