Préparer une version logicielle avec changement de base
Revenir à l’ancien code ne rétablit pas automatiquement sa compatibilité avec la base. Un cas complet montre quoi vérifier avant le changement et le retour.
Une version logicielle modifie parfois l’application et la base de données ensemble. Le retour doit donc prendre en compte davantage que l’ancienne version du programme. Consignez la combinaison de code, configuration et structure de données qui fonctionne.
L’exemple de portail fictif suivant est un cas de test prévu. Il ne décrit pas une modification d’une base client réelle.
Tester le retour sur le même état des données
L’application actuelle V1 lit les noms clients dans customer_name. La nouvelle application V2 doit lire display_name. Dans le scénario initial, l’ancienne colonne est supprimée. La nouvelle application ne démarre ensuite pas, car une configuration manque.
Étape | Base après l’étape | Résultat dans l’exemple |
|---|---|---|
Avant le changement | Ancienne colonne de nom présente | L’application actuelle fonctionne |
Après la modification prévue | Seule la nouvelle colonne existe | La nouvelle application ne démarre pas à cause de la configuration |
Redéployer seulement l’ancien code | Toujours uniquement la nouvelle colonne | L’ancienne application ne trouve pas la colonne attendue |
Redéployer l’ancien code ne rétablit pas la structure précédente. Un bouton de retour dans l’outil de déploiement ne résout pas seul cette incompatibilité.
Planifier une transition compatible
Une solution possible est progressive : conserver d’abord l’ancienne colonne et ajouter la nouvelle. Les valeurs existantes sont transférées de façon traçable. L’équipe définit quel champ fait autorité et comment maintenir la cohérence des changements pendant la transition.
Dans un environnement distinct, testez les deux versions sur cet état intermédiaire. Cela comprend la modification d’un nom et sa lecture correcte dans les deux versions. Une copie unique ne suffit pas si les valeurs suivantes n’alimentent qu’un seul champ.
La suppression de l’ancien champ n’est planifiée qu’après validation de la transition, lorsque l’ancienne version n’est plus nécessaire au retour. Cela modifie encore les versions anciennes utilisables. Cette étape demande une décision propre.
Tenir compte des données reçues ensuite
Une sauvegarde ancienne peut contenir la structure précédente. Si de nouvelles commandes ont été acceptées entre-temps, elles peuvent manquer dans cette sauvegarde. Une restauration ne doit pas les supprimer silencieusement. Les données arrivées ensuite et leur rapprochement relèvent du plan de reprise.
Selon le changement, une fenêtre de maintenance ou une correction ciblée de la nouvelle version peut être plus adaptée. La transition progressive ne promet pas globalement une mise à jour sans interruption.
Consigner le résultat de l’essai
Documentez version testée, configuration, état des données et personne décisionnaire en cas d’échec. En test, suivez une commande jusqu’à sa confirmation dans la cible, puis jouez le retour prévu. Notez données conservées et limites.
Avant le passage en production, vous voyez ainsi si le retour prévu convient réellement à l’application et à ses données.
Sources
Écrit par
- Philipp ReuterRédacteur qualité logiciellePhilipp Reuter écrit chez ASES sur les tests logiciels et la préparation des nouvelles versions. Ses articles portent sur l’analyse des erreurs, les tests de recette et la vérification des modifications apportées aux applications existantes.
À lire aussi
Tous les articles
Cloud & exploitation avec ASES
Hébergement, déploiement, maintenance et suivi