dbdeploy.net

dbdeploy.netAgile Database deployment for Java and .NET

(This post was originally hosted at http://www.dbdeploy.net)

DbDeploy is an implementation of the ActiveRecord Migrations pattern. DbDeploy.NET is the .NET port of DebDeploy. Both DbDeploys are projects initiated by ThoughtWorks. ActiveRecord comes to us via DHH.

Why would I use it?

When you’re developing software that hasn’t been released, the database is easy: you can tear it down and rebuild it at will. Once you have production data that people are using it, what do you do? How do you manage the change? The Migrations pattern allows you to make bite-sized changes to your database, and test it. It works very well with Continuous Integration.

What else is out there?

Payware:

Open source:

When should I use this pattern?

It’s ideal for greenfield agile projects where you are using Continuous Integration and want to make sure that changes to the database schema will be applied to integration tests. You can use other approaches if you have an ORM and you haven’t released to production yet.

When shouldn’t I use this pattern?

  • When you have a huge legacy database
  • When you’re trying to put data into a database and not schema changes
  • When you don’t use source control

The Migrations pattern is a really helpful way to manage database change; It’s not a silver bullet though. You need to have discipline and a good test regime. It works well with Continuous Integration.

Update: Gregg Jensen got in touch with a new URL for DbDeploy.Net

5 thoughts on “dbdeploy.net

  1. Mike Hogan says:

    This is an area I have been monitoring with interest for the past few months as I want to do a screencast on it. Its a great topic!

    I’ve been using dbdeploy on java projects for the last 3 years or so. Its not fair to say that its the same as Rails Migrations, because dbdeploy uses sql to represent changes, and Rails Migrations uses a db-agnostic api.

    Philosophically I am in favour of the db-agnostic api, so in the java space I have been looking at http://migrate4j.sourceforge.net/ and http://www.liquibase.org/ and even http://code.google.com/p/scala-migrations/ .

    The XML focus in Liquibase turns me off, but its explicit support for refactoring turns me on. Er – did I really say that…..I didn’t mean it the way it sounded.

    scala-migrations – not too sure about introducing more technology to a java project. So migrate4j hits the sweet spot more for me.

    This is all in theory by the way. As I said, I have used only dbdeploy in practice, but I am very very interested to hear about other people’s experiences using these other tools, or indeed anything else for that matter.

  2. […] Thoughtworks created an open source tool “DBDeploy” (with a corresponding .NET version, DBDeploy.NET) that they use with all of their clients and handles this elegantly. The only difference between it […]

  3. […] Thoughtworks created an open source tool “DBDeploy” (with a corresponding .NET version, DBDeploy.NET) that they use with all of their clients and handles this elegantly. The only difference between it […]

  4. […] Thoughtworks created an open source tool “DBDeploy” (with a corresponding .NET version, DBDeploy.NET) that they use with all of their clients and handles this elegantly. The only difference between it […]

  5. Dbdeploy.NET has been updated with new features and documentation at https://github.com/brunomlopes/dbdeploy.net.

Comments are closed.

%d bloggers like this: