I just thought it could be a good thing to have a dedicated version control branch for all database schema changes and I wanted to know if anyone else is doing the same and what have the results been.
Say that you are working with:
- Schema model/documentation (some file where you model the database visually to generate the schema source, say MySQL Workbench, with a .mwb file, which is binary)
- Schema source (a .sql file)
- Schema-based code generation
The normal way we were working was with feature branches, so we would do changes to the model files (the database specific ones), and then have to regenerate points 2 and 3, dealing with the possible conflicts (or even code rewriting).
Now say that your workflow goes the same way as the previous item numbering. With a model branch you wouldn’t have to reconcile the schema model with binaries in other feature branches, or have to regenerate schema source and regenerate code (which might have human code on top of it).
It makes so much sense to me it feels weird not having seen this earlier as a common practice.
Edit: I’m counting on branch merges to be the assertions for the model matching the code. I use a DVCS, so I don’t fear long-lived branches or scary-looking merges. I’m also doing feature branching.
4
I would advise against it. Database schemata change together with other related code or resources. To be able to track changes properly, you need to make cohesive changes link to each other, and a shared commit is the best way to go about it.
Consider your suggestion of keeping the schema under a separate branch. First off, you keep branches so you can push changes independently of other unrelated changes. What happens if you push schema commits without the corresponding code?
- You create commit history that appears “out of the blue”. It’s hard to follow where it came from or why, after a while.
- If you only commit schema, remember that others can do it as well. That means that others can pull and then rewrite/change your schema changes and still pass all of their tests (because they’re not testing your code). Then, when you want to commit your code you get conflicts, which may have otherwise been avoided.
There may be other drawbacks, or even benefits. But these 2 right here are enough of a reason for me not to take this approach.
Hope that helps.
4
I’d recommend to put all kinds of sourcecode together that builds up a running system (inlcuding database-queries and -schemas)
Why? Because, then you always have a relation between your code and the rest of the things that build your system (configuration, SQL, Readmes, Tests, …). If you make a change, you get certainly reminded to change those other artifacts, too.
If you have different branches, or even different repositories, it is much harder to remember which revision of branch A belongs to what revision of branch B, though leading to mistakes.
We used to work with release-branches, once. For that purpose, all developer agreed to a common procedure:
- fix a bug in the release-branch
- create a patch/diff
- apply the diff to the main branch
This is not very nice, because you duplicate changes that could have been merged. But it is an easy approach, every developer can handle, and SVN/CVS-merge sometimes is a pain in the a.
3
It’s bad idea in terms of “development philosophy” and usability
- you have broken rule “branch per task/feature” – model branch have not related task (or more than one task in timespan)
- This branch will be “forever-live” branch
- additional permanent merges with features-branches and broken builds if merge missed after schema-changes
2