Feedback Loops, DevOps and Database Continuous Delivery
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.
However, database source control is missing from the 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 (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 and stored procedures safely and quickly without the need for human intervention. Of course, databases are different than applications. We cannot simply blow away our databases and recreate them 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 difficult ones to automate. Renaming tables is always a good one. Always make sure that database standards are being met. 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.
Updating data and database schema with application releases is already a time-consuming task. It is no longer effective to rely on old methodologies and adding resources to a process that is already inefficient. With the rise in demand for quick application releases and updates, organizations need to focus on leveraging database DevOps and database continuous delivery.
A reliable DB change process should support lights-out automation.
You need a solution that provides more than source control for the database.
To learn more, read our white paper: Database Source Control Enables Agile Applications.