5

WARNING: LONG QUESTION.

[QUESTION]

If the strategy is to have a branch per database, as described in the problem below, where scripts are version controlled.

How do you manage the data migration issues when trying to consolidate to fewer branches?
Is it just a cost you incur as part of data migration?

Essentially transform scripts will have to be created at the time of migration.

Is there a better way?
Can we have both issues resolved at the same time?
What is the best practice?

[BACKGROUND]

At my work place we have a product which has 3 branches. Mainline having the "LATEST AND GREATEST" changes which is not necessary ready for release.

  • Version B (names have been changed to protect the guilty)
  • Version A (names have been changed to protect the guilty)
  • Mainline

Because of these branches there is effectively 3 versions of the database. Code version control is fairly easy however database version control seems difficult.

Having read Do you use source control for your database items? it seems the best way is to export all the create scripts for each object/table. NOTE: How you manage it, in one big script or multiple scripts or a hybrid, is your preference according to the article.

I agree with this and have inquired as to why it's not done.

Currently the DBAs refuse to branch the scripts into branches. Aside from laziness as an excuse the reason is to save time with data migration. Effectively the database changes are forcibly maintained across all versions.

All the scripts are version controlled and maintain only in mainline. Version A and Version B have their own special file that states which change scripts to run on their respective branch. The problem arises when there is a change script, for instance applied to Version A but Version B only requires part of the changes. It is up to the developer to inform the DBAs to update the file which indicates which patches to apply for each branch. For change scripts which does too much manual intervention is needed to manually apply part of the change script.

To update a database on Version A all patches are extracted with Version A's which patch to apply file.

[SCENARIO]

  • The 3 versions above exist.
  • Database changes occur to Version A.
  • Branch consolidation where the code is merged from Version B to A so that Version B can be removed.
  • The same needs to happen with the database.

Hope this makes sense.

Community
  • 1
  • 1
Gavin Chin
  • 558
  • 1
  • 6
  • 16
  • Can you please clarify whether any of your database scripts are CURRENTLY version-controlled? Or are you planning on using source control in the future to maintain multiple branches of your database? Also, is your question about how to merge the databases frequently or only once to get rid of the branches altogether? – Thomas Jung Jun 16 '09 at 03:51
  • I've clarified what the issue is above. Seems like the version control strategy in place is only because branching is to be avoided, due to reasons I cannot comprehend. I thought my understanding of the problem was because there was some big cost with data migration. But as John Saunders states below it is usually taken into consideration when the change scripts are created in the first place. Thanks for all the help guys. Seems like normal version control strategies would work after all. – Gavin Chin Jun 16 '09 at 05:13

1 Answers1

3

Take a look at Chapter 8 in Eric Sink's Source Control HOW TO. It's a great resource for understanding the ins and outs of source control.

nikmd23
  • 9,095
  • 4
  • 42
  • 57
  • nikmd23, Thanks for the link. Source Control merging is indeed as you've referenced. However how if multiple database changes have occurred and any script changes are merged across the branches correctly. Is it just a cost the person assigned to consolidate the changes, say months later, occurs in the time they have to invest in writing transform scripts etc. The issue isn't the database script control the issue is the data migration costs. Is there away around it? For example maintaining a script for every change for data migration? Have I missed something? – Gavin Chin Jun 16 '09 at 02:58
  • 1
    Every schema change must take data migration into consideration. Sometimes, the schema changes will not require any change in the data. Sometimes, they will require changes in the data. In that case, it's up to these change scripts to also change the data, however that may be necessary. – John Saunders Jun 16 '09 at 03:54