Database Source Control vs. Database Release Automation

Source control is your single source of the truth. Using a continuous build server with source code control is the first step in Agile Development, Continuous Integration, and Continuous Delivery. When a build happens, source code is transformed from human-readable text to machine instructions that can be deployed. The source is tagged so that the code is forever tied to a specific application release. You can recreate it at any future time.

Database source control is missing from our database change process today. Sure, maybe we are checking in our DB change scripts. Maybe we use Toad Team Coding to check-in and check-out DB objects for us during development. Once that build is performed, you have an atomic application binary ready for automated deployment and a bunch of SQL scripts. But that will still not speed your deployment process. You are still tied to a manual database deployment process.

The big challenge is that you cannot determine if a change has been persisted to a database without a manual review. If you need manual DBA intervention for every change to a database, you will fail.

The best way to guarantee safety is by using the same source control repository for both application code and DB code changes. This creates database source control: a single source of the truth for what database changes are part of a release. This helps teams know what application version goes with what database schema version. But this can be a lofty goal for many organizations.

Database Release Automation

Database Release Automation (DRA) solves this problem. Just like Application Release Automation orchestrates and automates previously manual tasks, database automation enables full stack automation by changing our database schemas safely and quickly without the need for human intervention. Of course, databases are different than application or web servers. We cannot simply blow away our database server and recreate it with a new version of the schema. We would lose our data. Databases have state and evolve over time.

Balancing safety and speed is key; you must have both with Database Release Automation. As part of every Database Release Automation tool evaluation, you should have use cases that test if you can perform a completely automated database deployment. Review your past year’s schema changes and choose the really gnarly, nasty ones to automate. Renaming tables is always a good one. Also, attempt to enforce naming conventions and the like with changes. Look for ones that you know should fail and make sure your DRA tool will catch them.

If your current DB change process cannot support lights-out automation, you need a solution with something more than just source control for the database.

To learn more read our white paper, Database Source Control Enables Agile Applications.

Seeing is believing.