Shared dev database versioning amongst multiple branches?

[rick]

Hi,

I'm evaluating Plastic at the moment but I have a nagging concern with the branch per task approach that I hope you can help me with.

At the moment we have a fairly simple setup, one main branch and release branches for various clients who take a branch from the main one when we do releases. All work is done on this main branch and therefore it is susceptible to the issues described in your documentation. We want to move away from this to branch per task.

The problem is we (4 x devs) all point to a dev database. We only make DB structure changes every few days or so and one person does it at a time to keep our ORM mapping (Microsoft Entity Framework) tool's mapping file in line with the database schema. If we go branch-per-task and two people require DB structure changes during their tasks are we supposed to clone the database per task and then merge in the database changes from each task's DB to the main one once the task has been tested and accepted? Our SQL Server DB is 500MB in size and a bit of a pain to clone for each task.

Surely, this must be a common scenario that other people are facing too. I just wonder is there a smarter way of doing this? Maybe put the DB into source control with branching too or some other way?

Thanks in advance,

Rick

[carpediemevive]

The most common approach to this is to get each developer their own database. That way they can blow up the database whenever they want to. I don't know what database platform you are using, but if it's SQL Server you can probably get away with each developer having a copy of the structure in a local SQL Server Express setup. Obviously if it's a MySQL or PostrgeSQL they can just install it locally anyway.

Then you can make your current dev database platform a place to do your integration testing or as a staging server where you can place releases and test them in whole before shipping them.

[Soho]

Hi, as you write, it is a very common problem how to properly version control databases.

Here is what we do (it is quite trivial).

First, the code is organized such that the database interaction is sealed to one library project. All persistency related operations in business code go through interfaces, thus isolating concrete database operations to this one library. Since you are using Entity Framework, it may slightly more difficult for you to isolate the database interactions unless you use POCO or self-tracking-entities.

Isolating the database makes it a lot easier to merge only database changes between branches or using xlinks to put the database library into it's own repository.

Also isolating the database is good practice and allows you to write unit tests for all persistency related operations without using a real database at all.

Secondly, we use, as you also mention, a local SQL Server Express for each developer and our build server. All database unit tests use the local database. Since all database creating scripts are version controlled (with some .bat files for easy updates), any branch work on an isolated version of the database regardless of changes in other branches. When we switch branch to a branch with a different database, we use run the .bat file for recreating the database. Of course our build server runs this .bat file automatically at each build.

You write that your database is 500 MB. If you need to make structural changes to a 500 MB database in each branch, it sounds to me like a non-test-driven work process. We use unit test databases (with a minimum of data) for normal development.

If you really need all 500 MB data for developing, you could consider splitting the database in two, assuming that the large amount of data is stored in tables, that does not change often. That way you could have a static shared database with lots of data and a per-developer database for development.

Also to me, 500 MB is not big. If you write a script for copying that data from a non-version controlled database into the per-developer database I could imagine that this copy operation would take less than a minute.

Our production databases are typically at around 1 - 10 TB, so what we do to stress-test is to let the build-server fill in dummy data overnight or copy data from a more static database.