Gestion de la migration des modifications de base de données de rupture vers 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 fonctionnant côte à côte avec l'ancienne version. Le hic, 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 significatif aux tables de base de données. Je souhaite que la nouvelle version de l'application soit déployée au fil du temps et que je puisse revenir à l'ancienne version si j'en avais besoin.

Oren avait une bonne post la mise en place de la question, mais il a fini avec:

« Nous sommes encore dans l'eau un peu boueuse en ce qui concerne le déploiement à la production en ce qui concerne les changements qui affectent l'ensemble du système, à savoir, Je vais discuter du fait que dans le prochain épisode, celui-ci a pris un peu de retard, j'en ai peur. "

Le post suivant n'est jamais venu ;-). Comment procéderiez-vous à la gestion de la migration des modifications de base de données de rupture vers 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 avez besoin de revenir en arrière, il vraiment aide si vous pouvez laisser la base de données telle qu'elle est. De toute évidence, cela comporte d'importants handicaps architecturaux, et vous aurez presque certainement une base de données qui montrera sa lignée, pour ainsi dire - mais les avantages du déploiement valent généralement la peine, selon mon expérience.

Cela aide si vous avez une collection solide de tests d'intégration pour chaque ancienne version concernée. Vous devriez être en mesure de les exécuter sur votre base de données de test migrée pour chaque version qui est toujours considérée comme "éventuellement en ligne", ce qui peut être "toutes les versions" dans certains cas. Si vous êtes en mesure de contrôler le déploiement de façon raisonnablement stricte, vous pouvez vous contenter d'avoir une compatibilité pour trois ou quatre versions - dans ce cas, vous pouvez planifier la suppression progressive des tables/colonnes obsolètes, etc. s'il y a un réel besoin. Gardez à l'esprit la complexité d'une telle planification par rapport aux avantages accumulés.

Answer 2

Lire le livre de Scott Ambler "Refactoring Databases"; 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 la nouvelle conception
• créer une vue avec l'ancien nom de la table qui recueille des données de la nouvelle table (s)
• créer « au lieu de » se déclenche sur le point de vue de mettre à jour les nouvelles tables au lieu de la vue

Dans certaines circonstances, vous n'avez pas besoin d'une nouvelle table - vous aurez juste besoin déclencheurs.

Answer 3

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

Vous pouvez gérer le contrat entre l'ancienne et la nouvelle application derrière les vues sur les nouvelles tables. Utilise avant/à la place des déclencheurs pour gérer les écritures dans les "anciennes" vues qui sont réellement écrites dans les nouvelles tables.

Vous maintenez 2 versions de code et devez toujours développer votre ancienne application mais elle est inévitable. De cette façon, il n'y a pas de problèmes de synchronisation, vous devrez donc gérer les conflits de réplication entre les anciens et les nouveaux schémas.

Plus de 2 versions se complique comme mentionné ...

Answer 4

D'abord, je voudrais dire que ce problème est très difficile et vous ne pourriez pas trouver une réponse complète. Dernièrement, j'ai participé à la maintenance d'une ancienne application métier, qui pourrait bientôt évoluer vers une nouvelle version. La maintenance inclut la résolution de bogues, l'optimisation de l'ancien code et de nouvelles fonctionnalités, qui ne peuvent parfois pas s'intégrer facilement dans l'architecture actuelle de l'application. Le principal problème avec notre application est qu'elle était mal documentée, qu'il n'y a aucune trace de changements et que nous sommes en fait la 5ème équipe de rotation travaillant sur ce projet (nous y sommes relativement nouveaux). En laissant les détails extérieurs sur le côté (code, calques, etc.), j'essaierai d'expliquer un peu comment nous gérons actuellement les changements de la base de données.

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

1. Tout d'abord, est que l'ancien code (SQL, procédures stockées, fonction, etc.) fonctionne comme il est et doit être conservé tel quel , sans trop modifier à moins qu'il y ait le cas (bug ou changement de fonctionnalité), et bien sûr, essayez de documenter autant que possible (en particulier les problèmes comme: "WTF !, pourquoi at-il fait cela au lieu de cela?"). Deuxièmement, chaque nouvelle fonctionnalité doit utiliser les meilleures pratiques connues à ce stade et modifier l'ancienne structure de base de données aussi peu que possible. Cela introduirait certaines options de refactorisation de base de données comme l'utilisation de vues modifiables sur le dessus de l'ancienne structure, l'introduction de nouvelles tables d'extension pour celles déjà existantes, la normalisation de la structure et de fournir la structure ancienne à travers des vues, etc.

De plus, nous Nous essayons d'écrire autant de tests unitaires que possible, les analystes 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 rapidement. Il ya beaucoup de livres qui répondent à tous vos problèmes, one http://databaserefactoring.com/ étant pointé dans l'un des answers. Modification ultérieure: J'espère que la deuxième règle répondra également au traitement des changements de rupture.