Data Dude/VS Team System Base de données - Utilisation avec des bases de données multi-projets

Question

Mon projet actuel utilise Visual Studio Team System pour Database Professionals GDR2 (également appelé DataDude). Nous sommes la seule application utilisant la base de données que nous modélisons en utilisant DataDude.

Mon entreprise aimerait utiliser DataDude dans tous ses projets. Cependant, je ne suis pas sûr à quel point cela fonctionnera avec les projets qui partagent une base de données (qui est la majeure partie de nos applications). Par exemple: ApplicationA, ApplicationB et ApplicationC partagent tous Database1 sur Serveur1. (Ils ne partagent pas le code source, seulement la base de données.) Les trois applications sont en cours de développement (en utilisant Scrum si c'est important).

Le problème survient lorsque ApplicationB doit être libéré dans notre environnement de test. Les fonctionnalités de déploiement automatique/script de DataDude captureraient les changements de développement actuels de ApplicationA et ApplicationC. (À l'heure actuelle, la modification de la base de données pour chaque application est un processus manuel). Alors, comment puis-je isoler chaque application de l'autre alors qu'ils partagent la même base de données?

Remarque: Je ne suis pas aussi préoccupé par les changements contradictoires pour cette question (c'est-à-dire si ApplicationA effectue une modification de DB qui casse ApplicationC). Nous pouvons trouver ceux qui sont en test. Je dois juste m'assurer que je ne déplace aucun changement de base de données qui ne fait pas partie de mon application libérant actuellement dans mes environnements de test/production.

Y at-il des meilleures pratiques ou des fonctionnalités qui peuvent m'aider avec cela?

Answer 1

Nous sommes dans une situation similaire. De nombreuses applications utilisent la même base de données et notre base de données est sous contrôle de source DBPro. Nous gérons cela en faisant fonctionner diverses applications dans leur propre branche du code source de la base de données. Chaque application fusionnera régulièrement de la branche principale afin que sa branche soit informée des modifications apportées par d'autres. Ensuite, lorsque l'une des applications doit être déployée pour le test, une fusion vers la branche principale est effectuée, puis un déploiement sur le serveur de test est effectué.