Modifiez un système existant en sécurité

Identifiez les contrats autour de la modification

Un logiciel existant a des appelants, des données stockées, des tâches planifiées et des procédures d’exploitation. Certaines dépendances ne sont pas visibles dans le fichier à modifier. Un agent peut produire une modification localement correcte qui rompt l’un de ces contrats.

Avant l’implémentation, identifiez les composants qui lisent et écrivent les données concernées. Inspectez les routes, les tâches en arrière-plan, les rapports et les intégrations externes. Vérifiez si d’autres équipes ou d’anciennes versions de clients dépendent du comportement actuel.

Demandez à l’agent les preuves qui étayent cette cartographie. Un résultat de recherche est un point de départ utile. Les appels dynamiques et les consommateurs externes peuvent toutefois nécessiter la confirmation d’un responsable.

Rendez le comportement actuel observable

Pour un module mal documenté, ajoutez des contrôles ciblés sur le comportement qui doit rester stable. Ils décrivent le contrat actuel. Ils ne prouvent pas que tout comportement existant est souhaitable.

Si le comportement actuel contredit une exigence, consignez le conflit. Ne conservez pas un défaut de sécurité au seul motif qu’un test l’a enregistré. Obtenez la décision nécessaire pour distinguer le comportement voulu d’un défaut.

Utilisez des fixtures réalistes sans données sensibles. Incluez d’anciennes structures de données et des enregistrements incomplets lorsqu’ils peuvent exister. Tester un nouveau schéma uniquement avec des données nouvellement créées peut masquer les problèmes de migration.

Examinez la transition entre versions

Prenons le renommage fictif de customer_name en display_name. Un renommage immédiat peut faire échouer une ancienne instance de l’application pendant le déploiement. Modifier les deux fichiers dans une seule pull request ne rend pas le déploiement atomique.

Une approche par étapes peut préserver la compatibilité :

1. Ajoutez le nouveau champ sans supprimer l’ancien.
2. Définissez comment les nouvelles écritures maintiennent la cohérence des valeurs nécessaires.
3. Complétez les enregistrements existants avec un processus qui peut reprendre après interruption.
4. Vérifiez que toutes les données ont été traitées et que les lectures fonctionnent.
5. Faites lire le nouveau champ aux composants concernés.
6. Supprimez l’ancien champ uniquement lorsque plus aucun composant ne l’utilise.

La méthode exacte dépend de la base de données et des modes d’écriture. Une double écriture peut créer une incohérence si l’une des écritures échoue. Une transaction de base de données ou une autre méthode explicite de synchronisation peut être nécessaire. N’appliquez pas cet exemple sans vérifier les garanties du système.

Martin Fowler décrit cette transition générale sous le nom de parallel change, aussi appelée expand-and-contract. L’idée principale est d’assurer une transition compatible avant la suppression.

Planifiez la restauration séparément du rollback

Un rollback du code rétablit une version antérieure de l’application. Il n’annule pas automatiquement une migration de données. L’ancienne version peut ne pas comprendre les nouvelles données. Une migration destructive peut supprimer des informations qu’un rollback du code ne peut pas récupérer.

Identifiez l’action de restauration pour chaque étape. Le remplissage des données anciennes peut reprendre sans danger si le processus le permet. Une transformation erronée peut nécessiter une correction à partir des données source conservées. Une opération destructive peut exiger une procédure de restauration vérifiée.

Demandez qui décide de la restauration et combien de temps elle peut prendre. Ne considérez pas « nous avons des sauvegardes » comme une preuve que la restauration satisfait l’exigence du service.

Gardez la modification facile à examiner

Séparez les nettoyages sans rapport de la modification fonctionnelle. Incluez dans la pull request le plan de compatibilité, les résultats de vérification et les conditions de suppression. Indiquez le point après lequel le rollback exige du travail supplémentaire.

Un agent peut aider à inspecter les consommateurs et à préparer le code de migration. Un responsable doit toujours accepter le plan de transition et de restauration. La conception finale n’est qu’une partie d’une modification sûre.