Gestion de la migration des modifications de la base de données dans une base de données partagée par l'ancienne version de la même application

Question

L'un de mes objectifs est de pouvoir déployer une nouvelle version d'une application Web qui exécute côte à côte l'ancienne version. Le problème, c'est que tout partage une base de données. Une base de données qui, dans la nouvelle version, a tendance à inclure un refactoring important des tables de base de données. J'aimerais déployer progressivement la nouvelle version de l'application auprès des utilisateurs et pouvoir les remettre à l'ancienne si besoin est.

Oren avait un bon post pour configurer le problème, mais s'est terminé par:

"Nous sommes toujours dans une eau un peu boueuse en ce qui concerne le déploiement en production des modifications qui affectent l'ensemble du système, à savoir la modification des modifications de la base de données. Je crains que je ne discute de cela dans le prochain épisode, celui-ci n’ayant qu’un peu de marge de manoeuvre. "

Le post suivant n'est jamais arrivé ;-). Comment feriez-vous pour gérer la migration des modifications de la base de données dans une base de données partagée par l'ancienne version de la même application? Comment garderiez-vous les données synchronisées?

Answer 1

Si l'ancienne version doit être conservée, les modifications ne peuvent tout simplement pas être rompues. Cela aide également lors du déploiement d'une nouvelle version d'une application Web. Si vous devez restaurer des versions antérieures, cela est également utile si vous pouvez laisser la base de données telle quelle.

Évidemment, cela présente des handicaps architecturaux importants, et vous allez certainement vous retrouver avec une base de données qui montre sa lignée, pour ainsi dire - mais les avantages du déploiement valent généralement la peine, selon mon expérience.

Cela peut être utile si vous disposez d'une collection solide de tests d'intégration pour chaque ancienne version impliquée. Vous devriez pouvoir les exécuter sur votre base de test test migrée pour chaque version toujours considérée comme "éventuellement vivante". - qui pourrait bien être "chaque version de notre vie" dans certains cas. Si vous êtes en mesure de contrôler le déploiement de manière raisonnablement stricte, il est possible que la compatibilité ne soit disponible que pour trois ou quatre versions. Dans ce cas, vous pouvez planifier la suppression progressive des tables / colonnes obsolètes, etc. si vous en avez réellement besoin. Il suffit de garder à l’esprit la complexité d’une telle planification par rapport aux avantages acquis.

Answer 2

Lisez le livre de Scott Ambler & Refactoring des bases de données " ;; prendre avec une pincée de sel, mais il y a beaucoup de bonnes idées là-dedans.

Les détails des solutions disponibles dépendent du SGBD que vous utilisez. Cependant, vous pouvez faire des choses comme:

• créer une nouvelle table (ou plusieurs nouvelles tables) pour le nouveau design
• créer une vue avec l'ancien nom de la table qui collecte les données de la ou des nouvelles tables
• crée des déclencheurs "au lieu de" sur la vue pour mettre à jour les nouvelles tables au lieu de la vue

Dans certaines circonstances, vous n'avez pas besoin d'une nouvelle table - vous pouvez simplement avoir besoin de déclencheurs.

Answer 3

En supposant seulement 2 versions de votre client, je ne conserverais qu'une copie des données dans les nouvelles tables.

Vous pouvez gérer le contrat entre les anciennes et les nouvelles applications derrière des vues situées au-dessus des nouvelles tables. Utilisez avant / au lieu de déclencheurs pour gérer les écritures dans le "vieux". les vues qui écrivent dans les nouvelles tables.

Vous maintenez deux versions de code et devez toujours développer votre ancienne application, mais cela est inévitable.

De cette manière, il n'y a pas de problème de synchronisation, vous devrez effectivement gérer les conflits de réplication entre " ancien " et " new " schémas.

Plus de 2 versions deviennent compliquées, comme mentionné ...

Answer 4

Tout d'abord, je voudrais dire que ce problème est très difficile et que vous ne trouverez peut-être pas de réponse complète.

Dernièrement, je me suis occupé de la maintenance d’une gamme d’applications métier héritée, qui pourrait bientôt évoluer vers une nouvelle version. La maintenance inclut la résolution de bugs, l’optimisation de l’ancien code et de nouvelles fonctionnalités, qui ne peuvent parfois pas s’intégrer facilement dans l’architecture actuelle des applications. Le principal problème de notre application est qu’elle a été mal documentée, qu’il n’ya aucune trace de changements et que nous sommes essentiellement l’équipe de 5ème rotation travaillant sur ce projet (nous sommes relativement nouveaux pour lui).

En laissant de côté les détails extérieurs (code, couches, etc.), je vais essayer d'expliquer un peu comment nous gérons actuellement les modifications de la base de données.

Nous avons en ce moment deux règles que nous essayons de suivre:

1. Tout d’abord, l’ancien code (sql, les procédures stockées, la fonction, etc.) fonctionne-t-il tel quel et doit-il être conservé tel quel, sans trop modifier, sauf en cas de changement de casse (bug ou de fonctionnalité), et de Bien sûr, essayez de le documenter autant que possible (en particulier les problèmes tels que: "WTF !, pourquoi at-il fait cela à la place de cela?").

2. Deuxièmement, chaque nouvelle fonctionnalité introduite doit utiliser les meilleures pratiques connues à ce jour et modifier aussi peu que possible l'ancienne structure de la base de données. Cela introduirait certaines options de refactoring de la base de données, telles que l’utilisation de vues modifiables au-dessus de l’ancienne structure, l’introduction de nouvelles tables d’extension pour les tables existantes, la normalisation de la structure et la fourniture de l’ancienne structure par le biais de vues, etc.

En outre, nous essayons d'écrire autant de tests unitaires que possible, à condition que les analystes métier travaillent côte à côte et documentent les règles métier.

Le refactoring de base de données est un domaine très complexe auquel il faut répondre dans une réponse courte. Il existe de nombreux livres qui répondent à tous vos problèmes, un http://databaserefactoring.com/ pointé en un. des réponses .

Éditer plus tard: espérons que la deuxième règle réponde également au traitement des modifications importantes.