FAQ

Have a question we don’t cover here? Then get in touch

You keep mentioning Continuous Integration. What is it?

Continuous Integration is the process by which a developer’s code is automatically tested and integrated with all other code when it is checked in. Tools such as CruiseControl can manage this. For more on the topic see Martin Fowler’s piece on the topic.

How does dbdeploy work with Continuous Integration

dbdeploy is called from within an ant build script. Ensure that your continuous integration build includes the usage of dbdeploy, this will mean that your next production upgrade will be tested as part of each build.

What about branching?

The more you think about what could go wrong on a branch the worse it gets. Common best practice is to keep branches short-lived and dedicated to a specific purpose, when following this we’ve found that in practice very few issues crop up. When issues do crop up it’s unfortunate but they need to be dealt with manually.

What about rollback?

A rollback or back-out procedure is often a requirement when making modifications to production databases. The mechanics of this procedure will vary according to the technology available, volumes of data, length of maintenance window (if any) and in-house preferences. Should there be a requirement for a rollback script then dbdeploy can help, you can test the dbdeploy undo script as part of your automated build.

Does dbdeploy actually execute delta scripts?

No. Our experience tells us that production DBAs usually prefer to inspect a script rather than trust a tool to make modifications to their (understandably) precious databases! So the rationale is that if dbdeploy is going to generate a script that will eventually be run in production then this is the approach that should be taken in all pre-production environments also. You must have a separate task in your process to actually execute the script generated by dbdeploy.