views:

255

answers:

1

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?

+2  A: 

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.

Randy Minder
Using a solution like looks like a good solution. The main problem I see is that you cannot deploy to your Development environment using DBPro. (Because one branch would stomp on the other branches.)
Vaccano
But the ability to deploy to the test environment using DBPro is a big plus for this solution.
Vaccano
@Vaccano - DBPro really encourages isolated development, where each developer has their own separate development database (probably local database). I agree with this approach. I just don't see how multiple developers, all developing against the same database, works very well.
Randy Minder
@Randy - turns out DBPro supports partial projects to help with this issue: http://blogs.msdn.com/gertd/archive/2008/10/05/partial-projects.aspx
Vaccano