RoundhousEModes

RoundhousE Modes

RoundhousE has three modes which can be combined to create interesting work flows. Here are the modes:

• Normal: Runs all necessary scripts. It will even create the database if necessary.
• DropCreate: Drops the existing database and then executes Normal mode.
• RestoreRun: Restores a backup (the baseline) into the existing database and then executes in Normal mode.

Where are these "Modes"?

These are actually workflows. In a Normal mode/workflow, you just execute RH without restore configured. In RestoreRun mode, you execute RH with restore options configured. The one that seems to trip up most new people is understanding DropCreate mode, but it's simply a run that has /drop specified followed by a normal run.

We have never deployed to production

If you are developing an application that has not yet made it into production, you will want to run in DropCreate mode. This will drop and re-create your database each time you run RH. Be sure to include scripts that insert any reference data your application requires. This mode ensures your deployments are tested in the same manner they will be executed the day you push the application to production.

Our application is now used in production

Once your application has been deployed to production, you will want to take advantage of the RoundhousE's two other modes: Normal and RestoreRun.

Development, QA and Staging Deployments

You will want to fully exercise your database deployment process through development, QA and staging. By the time you've made it through the deployment pipeline, you want to be confident that your scripts will work correctly against the database version already in production. The best way to do accomplish this is running RoundhousE in RestoreRun mode:

1. Take a backup of your production database[1] and put it on a network share. This will be the baseline for development, QA and Staging deployments.
2. When deploying releases to each of these environments, execute RoundhousE using RestoreRun mode and point it at the baseline created in step 1. In this mode, RoundehousE will restore the target database from the production database backup and then apply new migration scripts.

Production Deployments

Deployments to production should be done using Normal mode. RoundhousE will simply run the necessary scripts to bring the production database up to date. After the new version has gone live, take a new backup from production and use this as your new baseline for deploying throughout the deployment pipeline.

[1] Using a true production backup may be hard for large databases or databases with sensitive data. You are simply trying to gain confidence that the scripts you are going to run on production will work as expected, so if you can't use a replica of your production database, perhaps try with a copy of a staging area that is somewhat representative of the data you typically find in production. You can usually get a scrubbed (sensitive data removed/changed) and/or pared down version of that production database (schema + some required tables filled in).

Use Case For Preferring RestoreRun

You can never get past changes directly to a production database. It's going to happen. Your DBAs may have something urgent that needs to be done directly to a database server. You need a way to feed it back through your environments.

Since direct changes to a prod database are a matter of fact, it just needs a little more thought on how to work with this fact. I think every organization deals with this fact, and I was in an organization where we found this to be true. But we thought through the issue and realized one very important thing - we had production database backups.

We had production database backups, scrubbed database backups if there was sensitive data, and if the database backup was very large, we would also have a scrubbed backup that introduced only schema and some database tables and possibly some pared down data.

Because we were using RoundhousE and RestoreRun mode, our developers would always start from the latest backup, so it would restore the backup locally and apply only the latest changes. That way even those changes added that were urgent and only applied to production, we would have on the next refresh of the database locally, plus any changes we had that had not yet hit production.