locked
Merging Databases Questions

    Question

  • Hi.

    I am fairly new to VSTS Database edition (TFS 2008 SP1, SQL 2005/2008, single server install).

    We will begin branching our database code very soon.  While I've done many merges with C# code, I've never done or even considered doing database merges.  As such I have a few questions about this:

    1)  Does anyone have any articles or info that is specific to database merges (I get the principles behind merges in general and do this often with our app code)?
    2)  Are doing database merges any different than doing application (C#) merges?
    3)  How best should I prep my databases prior to a merge?
    4)  What problems am I likely to encounter if I merge databases?
    5)  What's the best way to verify that the merge results?

    Please note that I am a CM person and not a DBA, and I'm not well versed in databases (though I can enlist the help of our DBAs any time).  And as mentioned above, I have not been using VSTS Database Edition for very long. 

    I could really use some specific advice on merging databases if the process and pitfalls are different than merging application (C#) code.

    Thanks everyone.


    Logan
    Monday, September 21, 2009 5:59 PM

Answers

  • We use branching and merging for database and code projects. Doing a merge for a database project is exactly the same as doing a merge for code projects. You dont need to do anything special to the database projects or databases in preparation for a merge.

    One of the simplest  ways to ensure the merge has worked ok is to do a build immediately afterwards. If there are any major problems, the build will not work. This can be done using continuous integration.

    The major problem we have had with database merges compared to code merges is the frequency of changes (though with correct processes it isnt a big problem).

    Our code gets released roughly every 5 weeks which means merges for code only happen around then. Our database changes often happen a lot more frequently - for instance if we notice a badly performing query in our production systems and add an index to help it, this needs doing quickly rather than waiting for the next code release.

    We add the index to the database project in a 'bug fix', test and release it. This changes the dbproj file (as there is a new file that has been added to the project). The issues arise when we merge this change back to our development branches (we have a few development branches working on different features). 
    As we have added an item to the database project, and there are quite likely new items added in the development branches, there will quite likely be a conflict on the dbproj file when doing the merge. Most of the time these can be resolved using the automerge in visual studio, although a few times this has resulted in a broken dbproj file. Using continuous integration any broken dbproj files are picked up straight away and we go and fix them. The best way we have found of doing this is by rolling back the dbproj file to the previous version and then adding the new file for the index in manually.

    • Marked as answer by Logan Therrion Tuesday, September 22, 2009 11:34 AM
    Tuesday, September 22, 2009 7:17 AM

All replies

  • In our team we treat database code the same way as C# and C++ code, we use source code branching inside TFS.
    I found this to be a great reference http://www.codeplex.com/BranchingGuidance

    GertD @ www.DBProj.com
    Monday, September 21, 2009 7:17 PM
  • We use branching and merging for database and code projects. Doing a merge for a database project is exactly the same as doing a merge for code projects. You dont need to do anything special to the database projects or databases in preparation for a merge.

    One of the simplest  ways to ensure the merge has worked ok is to do a build immediately afterwards. If there are any major problems, the build will not work. This can be done using continuous integration.

    The major problem we have had with database merges compared to code merges is the frequency of changes (though with correct processes it isnt a big problem).

    Our code gets released roughly every 5 weeks which means merges for code only happen around then. Our database changes often happen a lot more frequently - for instance if we notice a badly performing query in our production systems and add an index to help it, this needs doing quickly rather than waiting for the next code release.

    We add the index to the database project in a 'bug fix', test and release it. This changes the dbproj file (as there is a new file that has been added to the project). The issues arise when we merge this change back to our development branches (we have a few development branches working on different features). 
    As we have added an item to the database project, and there are quite likely new items added in the development branches, there will quite likely be a conflict on the dbproj file when doing the merge. Most of the time these can be resolved using the automerge in visual studio, although a few times this has resulted in a broken dbproj file. Using continuous integration any broken dbproj files are picked up straight away and we go and fix them. The best way we have found of doing this is by rolling back the dbproj file to the previous version and then adding the new file for the index in manually.

    • Marked as answer by Logan Therrion Tuesday, September 22, 2009 11:34 AM
    Tuesday, September 22, 2009 7:17 AM
  • Thanks, Ant.  Excellent response.  This helps considerably.


    Logan.
    Tuesday, September 22, 2009 11:34 AM