Data Dude/VS Team 系统数据库 - 与多项目数据库一起使用
我当前的项目使用 Visual Studio Team System for Database Professionals GDR2（又名 DataDude）。我们是唯一使用使用 DataDude 建模的数据库的应用程序。
我的公司希望考虑在我们的所有项目中全面使用 DataDude。但是，我不确定这对于共享数据库的项目（这是我们的大部分应用程序）来说效果如何。
例如：ApplicationA、ApplicationB 和 ApplicationC 都共享 Server1 上的 Database1。 （它们不共享源代码，只共享数据库。）所有三个应用程序都处于当前开发状态（如果重要的话，使用 Scrum）。
当 ApplicationB 需要发布到我们的测试环境时，问题就出现了。 DataDude的自动部署/脚本功能将捕获ApplicationA和ApplicationC的当前开发更改。 （现在对每个应用程序进行数据库更改是一个手动过程）。
那么，当每个应用程序共享相同的数据库时，如何将它们与其他应用程序隔离呢？
注意：我并不担心此问题的冲突更改（即，如果 ApplicationA 进行的数据库更改会破坏 ApplicationC）。我们可以在测试中找到它们。我只需要确保不会将任何不属于我当前发布的应用程序一部分的数据库更改移至我的测试/生产环境。
是否有任何最佳实践或功能可以帮助我解决这个问题？
My current project uses Visual Studio Team System for Database Professionals GDR2 (aka DataDude). We are the only application using the database that we model using DataDude.
My company would like to consider using DataDude across the board on all our projects. However, I am not sure how well this will work with projects that share a database (which is the bulk of our applications).
For example: ApplicationA, ApplicationB and ApplicationC all share Database1 on Server1. (They don't share source code, just the database.) All three applications are under current development (using Scrum if it matters).
The problem comes when ApplicationB needs to release to our test environment. The auto deployment/scripting features of DataDude would catch the current dev changes of ApplicationA and ApplicationC. (Right now making the Database changes for each application is a manual process).
So, how can I insulate each Application from the other while they share the same database?
Note: I am not as concerned about conflicting changes for this question (ie if ApplicationA makes a DB change that breaks ApplicationC). We can find those in testing. I just need to make sure I don't move any Database Changes that are not part of my currently releasing Application to my Test/Production environments.
Are there any best practices or features that can help me out with this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们也面临着类似的情况。我们有许多应用程序访问同一个数据库，并且我们的数据库受 DBPro 源代码控制。我们通过让各种应用程序在各自的数据库源代码分支中工作来处理这个问题。每个应用程序都会定期从主分支合并，以便其分支知道其他应用程序所做的更改。然后，当其中一个应用程序需要部署到测试时，会先合并到主分支，然后再部署到测试服务器。
We are in a similar situation. We have many applications hitting the same database, and our database is under DBPro source control. We handle this by having various applications work in their own branch of the database source code. Each application will merge down from the main branch on a regular basis so its branch is aware of changes made by others. Then, when one of the applications needs to deploy to testing, a merge up to the main branch is done and then a deployment to the testing server is done.