The next topic I want to address, essential for the Agile DBA, and important for other SDLC methodologies, is continuous integration and automated builds. These are two different processes that work hand in hand. As you know, an automated build system takes all of the code that has been checked into version control, compiles it, and produces a working result. In the case of a database, an automated build simply applies a series of migrations to a database, resulting in a fully functional database.
Since you now build your database through a series of migrations, you can begin your automated build at any point. You can start with nothing, building a complete database from scratch. You can also start by using an already existing database in the form of a backup that may be restored, or just a database that constantly migrates with the latest changes. The key is to be able to take a database from any point, and apply all necessary migrations, in order, to bring it up to the latest migration checked into version control.
Because this is an automated process, when you finally release to production, you should have applied you migrations many times, and be confident they work as expected.
In addition to automated builds, there is great value in Continuous Integration. For our working definition, Continuous Integration is instantiated when development code is checked into version control. The CI server notes the check in, and starts an automated build. The automated build applies migrations to a continuous integration version of your database. After applying all integrations, it then runs the automated unit tests you have written. A Pass/Fail result of the build is returned providing immediate feedback regarding the viability of the code you have checked in.
Now you have Automated Testing, Automated Migrations, Automated Build and Continuous Integration as essential safety nets. These tools allow you to sleep at night, and have effortless software releases. Using this methodology, I worked on an Agile team releasing new features to a production system every week. The release never took longer than 15 minutes, including tested after release. We never had to rollback any code. If proof is in the pudding, I’m convinced this practice is worth the effort.
Cheers,
Ben