Continuous Database Integration – video

At the continuous integration workshop Headspring Systems held in Austin this week one of the topics that we covered was Database Integration. We are still in the process of publishing the videos of the entire workshop but I thought I would publish this snippet (30 minutes) that talks about how We Do Database MigrationsJeffrey Palermo and I did this workshop and had a great time doing it. This demonstrates how to use the Tarantino toolset.

I hope  this is useful and would love to hear some feedback about what you like or hate about this approach.


About Eric Hexter

I am the CTO for QuarterSpot. I (co)Founded MvcContrib, Should, Solution Factory, and Pstrami open source projects. I have co-authored MVC 2 in Action, MVC3 in Action, and MVC 4 in Action. I co-founded online events like mvcConf, aspConf, and Community for MVC. I am also a Microsoft MVP in ASP.Net.
This entry was posted in .Net, agile, continous improvement, continous integration, Tarantino, Tools. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jason West

    Would be interesting to see how you do merges at varying levels of divergence and when there are merge conflicts.

  • @jason we normally do not have file merge conflicts as the file names are unique. If two different feature branches are each adding files to their branch then the first branch to merge back into the trunk gets to commit and the last branch to merge must renumber their files if they fail.

    Right now the tarantino tool will allow duplicate file number prefixes but I would like to add a check in the tarantino tool that would fail if there were two duplicate file prefixes. This would force the developer who has not committed to update their files if there was a conflict.

  • @erichexter what we do for this is immediately gets the latest on that folder and checks-in an empty file.

    So when I do a migration, I must download the others first, so the numbering stays right. it then checks in an empty file, so that others get the same benefit.

    Migrations run without hiccup.. .and when I’m done with my change, I check it in and other migrations notice that they haven’t run it and they include it in the update.

    In some cases it requires a:

    migration run 12 (a few versions back)
    migration run (to get back to current)

    but that hardly happens.

  • If I understand correctly what makes Tarantino unique comparing to other SQL-based tools is that it has no concept of “version”. Instead it runs all not-yet-applied scripts in alphabetical order. This is very powerful as it not only allows any file naming convention but also supports bunch of branching / merging scenarios.

  • @zvolkov, It does have a small concept of a version. When it tracks the scripts that are applied to the database it logs the time but it also logs the batch of scripts that were applied as a batch. This number is essentially the total number of migration scripts that have been run against the system. So in the case of this video the version of this database was 11. This does not directly correlate back to the version of the application which the changes correspond to. We really heavly rely on the fact that the scripts in source control are the correct scripts to run with the code in source control. So yes this does make branching very easy since there are very few constraints around keeping scripts tied to say an assembly version number.

  • JECt19 I want to say – thank you for this!