Comment les environnements de transfert sur mon hôte ont arrêté la synchronisation des bases de données et le flux de travail de fusion manuelle qui maintenait la cohérence des versions

La gestion d'applications Web complexes implique souvent l'utilisation de plusieurs environnements (développement, transfert et production) pour tester les fonctionnalités et détecter les bogues avant qu'ils n'atteignent les utilisateurs. Pour de nombreux développeurs et équipes, maintenir la synchronisation entre ces environnements est la clé d’un processus de déploiement sain. Mais que se passe-t-il lorsque ces systèmes ne communiquent plus correctement ?

TL;DR

Lorsque les environnements de test ont cessé de synchroniser automatiquement les bases de données, l'équipe a mis en œuvre une stratégie de fusion manuelle pour maintenir des données cohérentes tout au long du développement et du transfert. Ce flux de travail garantissait que les conflits de versions étaient minimisés et que tous les membres de l'équipe restaient alignés. Bien que plus long, le processus manuel a amélioré l’intégrité de la base de données et la connaissance des versions. Une liste de contrôle structurée et une communication claire ont été essentielles au succès.

Ce qui n'a pas fonctionné : l'échec de la synchronisation automatisée

Le fournisseur d'hébergement proposait autrefois une synchronisation transparente entre les environnements : le code et les bases de données pouvaient passer du développement à la préparation avec une seule commande ou action d'interface utilisateur. Cependant, après une mise à jour de routine début 2023, le processus de synchronisation des bases de données sur plusieurs environnements de test a soudainement cessé de fonctionner. Le pipeline d'automatisation a renvoyé des erreurs obscures ou n'a synchronisé que partiellement le contenu.

Les efforts visant à résoudre le problème avec l’assistance ont été lents et peu concluants. Le problème découlait des politiques de traitement des données récemment mises en œuvre qui limitaient intentionnellement l'écrasement automatique des bases de données intermédiaires par mesure de sécurité.

L'équipe n'avait pas le choix : si elle voulait que ses environnements de développement et de préparation aient des structures de base de données et des échantillons de données correspondants, elle aurait besoin d'un nouveau flux de travail.

Pourquoi la synchronisation des bases de données est plus importante que le code

Contrairement au code, dont la version est contrôlée via Git ou un autre système, les bases de données sont plus fragiles. Ils contiennent du contenu dynamique créé par les utilisateurs, des configurations changeantes, des données mises en cache, etc. Si la base de données de pré-production n'a pas suivi les modifications du schéma de développement (ou pire, si elle présente des structures conflictuelles), elle peut complètement anéantir les cycles de test. Les développeurs peuvent résoudre des bogues fantômes causés par des incompatibilités de schéma ou des données manquantes.

[p]Image montrant côte à côte un environnement de préparation et de développement, tous deux connectés à une base de données centralisée[/p]

Le workflow de fusion manuelle qui a sauvé l'équipe

Confrontée à un processus de synchronisation interrompu, l'équipe de développement a mis en place un flux de travail manuel de fusion de bases de données. Même si elle n’est pas idéale en termes de rapidité, la nouvelle approche constitue une méthode de sécurité pour que tout le monde reste sur la même longueur d’onde.

Étape 1 : Exportation depuis l'environnement de développement

Chaque fois que des progrès significatifs se produisaient dans l'environnement de développement, tels que des modifications de table ou des ajouts importants de données de départ, le développeur responsable exportait la dernière base de données à l'aide d'outils de ligne de commande ou d'un outil GUI tel que phpMyAdmin ou Sequel Pro .

• MySQL : mysqldump -u user -p dev_db > dev_db.sql
• PostgreSQL : pg_dump dev_db > dev_db.sql

Étape 2 : Vérifier les modifications avant l'importation

Plutôt que d'importer immédiatement vers la zone intermédiaire, le dump SQL a été examiné dans un référentiel dédié. La différence entre la base de données intermédiaire actuelle et le nouveau fichier SQL a été évaluée par l'équipe.

Ce processus a permis à l'équipe de :

• Détecter les collisions de schéma
• Identifier les tables ou champs obsolètes
• Empêcher l'écrasement des données spécifiques à la préparation

Étape 3 : Sauvegarder la base de données intermédiaire existante

Aucune modification n'a été apportée avant la sauvegarde de la base de données intermédiaire actuelle. Ce cycle complet de tests prudents a permis de garantir qu'en cas de mauvaise fusion ou de problème inattendu, l'équipe pourrait revenir à une version stable précédente sans perdre de données critiques.

Étape 4 : importation contrôlée

Le fichier SQL examiné issu du développement serait ensuite importé dans l'environnement de test, mais avec une utilisation prudente des commandes pour éviter les suppressions massives, sauf en cas d'absolue nécessité. Dans certains cas, les importations spécifiques aux tables ont été préférées pour conserver intacts certains ensembles de données. Pour les applications plus dynamiques, des insertions et des mises à jour sélectives ont été écrites et testées manuellement avant la soumission complète.

Outils et bonnes pratiques utilisés

Pour réussir ce processus manuel, l'équipe s'est fortement appuyée sur la cohérence, d'excellents outils et une documentation interne. Voici quelques-uns des faits saillants :

• Gestion des versions SQL : en validant les deltas du schéma .sql dans le contrôle de version, les modifications apportées à la structure de la base de données ont été traitées de la même manière que les modifications du code.
• Outils de comparaison de bases de données : des applications telles que DBSchemaetRedGate SQL Compareont mis en évidence les différences entre deux versions d'une base de données, réduisant ainsi les incertitudes.
• Affectations de rotation d'équipe : pour éviter de surcharger une seule personne, les rôles d'exportation, de révision et d'application des modifications ont été alternés chaque semaine.

Défis et limites auxquels l'équipe a été confrontée

Ce processus de fusion manuelle n'était pas parfait. Cela nécessitait une communication élevée et un timing précis. Si ne serait-ce qu’une étape était ignorée, comme oublier de sauvegarder, les résultats étaient risqués. Certains inconvénients comprenaient :

• Prend beaucoup de temps : chaque processus de fusion a pris de 30 à 90 minutes, en fonction des modifications et du temps de révision.
• Sujet aux erreurs humaines : une ligne manquée dans une instruction d'insertion ou une mise à jour de schéma conflictuelle pourrait entraîner des bogues.
• Pas de véritable historique des états des données : contrairement à Git, les restaurations reposaient entièrement sur des copies de fichiers et des journaux manuels.

Malgré ces inconvénients, l’équipe a remarqué un effet secondaire précieux : elle a compris la structure de sa base de données de manière beaucoup plus détaillée et les bugs liés à la synchronisation aveugle ont pratiquement disparu.

Le résultat : plus de sensibilisation, moins de bugs cachés

Après plusieurs mois d'utilisation du workflow de fusion manuelle, l'équipe a constaté que les conflits de bases de données lors du déploiement avaient considérablement diminué. Même lorsque le fournisseur d’hébergement a finalement rétabli la synchronisation, l’équipe a choisi de conserver certains aspects du processus manuel en raison de sa transparence et de sa fiabilité.

Un avantage involontaire était également une meilleure discipline de test. Étant donné que l'environnement de test reflétait des choix intentionnels (et pas seulement un écrasement aveugle), les tests d'assurance qualité manuels ont identifié des bogues de niveau supérieur plutôt que des écarts au niveau du schéma.

Conclusion : transformer l'échec en croissance du flux de travail

Même si la perte de la synchronisation automatisée a perturbé le flux de travail initial de l'équipe, elle a obligé l'équipe à revoir des pratiques qu'elle considérait autrefois comme allant de soi. Grâce à des vérifications manuelles, des importations sélectives et une discipline stricte concernant l’état de la base de données, l’équipe est ressortie plus forte et mieux alignée. Cette histoire témoigne d’une réorientation créative lorsque les outils et les systèmes échouent et d’une adaptation avec des méthodes qui, bien que démodées, favorisent la clarté et le contrôle.

FAQ

Q : Pourquoi la synchronisation d'origine de la base de données de préparation vers le développement a-t-elle cessé de fonctionner ?

Un changement mis en œuvre par le fournisseur d'hébergement a introduit des politiques plus strictes en matière d'écrasement des bases de données intermédiaires, probablement pour des raisons de sécurité. Le résultat était des tentatives de synchronisation partielles ou infructueuses.

Q : Une fusion manuelle est-elle une bonne solution à long terme ?

Bien qu’elle ne soit pas idéale pour tous les scénarios, elle peut être efficace lorsqu’elle est associée à de bons outils et à une bonne communication. Pour certaines équipes, la clarté et le contrôle qu’elle offre l’emportent sur les risques liés à l’automatisation.

Q : À quelle fréquence ces fusions manuelles doivent-elles avoir lieu ?

Ils doivent coïncider avec des étapes de développement majeures, des fonctionnalités terminées ou des modifications de schéma. Les fusions trop fréquentes consomment des ressources de l'équipe, tandis que les fusions peu fréquentes provoquent des conflits importants.

Q : Quel est le plus grand risque lié à la synchronisation manuelle des bases de données ?

Le plus grand risque est l’erreur humaine : écrasement ou omission de données critiques. Les pratiques de sauvegarde et les listes de contrôle atténuent la plupart de ces problèmes.

Q : Et si nous utilisions un CMS au lieu d’une plateforme personnalisée ?

Même avec un CMS, les plugins et les configurations personnalisées introduisent des modifications de schéma. La synchronisation manuelle est toujours utile pour garantir le maintien de la parité des versions.