6 Reasons to Get Started with Database Release Automation
All of us working with Agile Software Development and DevOps owe a huge debt of gratitude to Toyota Motor Corporation. Agile Manufacturing’s focus on tools, processes, and training to quickly respond to customer needs was what led directly to the Agile Manifesto. The same can be said about DevOps’ development from Agile Manufacturing and the “5 Why’s”.
Problems (specifically ones dealing with software releases) do not have a single root cause and require iterations to find it. Toyota found anecdotally that 5 iterations is the number required to find the ultimate root cause.
Let’s look at Database Release Automation as an example and put together a simple strawman to illustrate. You might have found that your software releases are still not happening as quickly as you would like even after adopting DevOps and Application Release Automation (ARA).
- Why are our software releases taking 1 week after a request to reach production and our customers?
“Our software releases require a manual process. That manual process has an SLA of 72 hours.”
- Why is there a manual process for our releases?
“Our DBAs need to review the changes.”
- Why do the DBAs need to manually review changes?
“DBAs to compare the preceding environment to the target environment to locate the change, extract it, and push to the target environment.”
- Why do we require our DBAs to compare environments?”
“The Data Group, which the DBAs report into, do not trust SQL scripts and mandate they write the SQL scripts themselves.”
- Why do the DBAs not trust SQL scripts from development?
“In the past, development provided SQL scripts have violated corporate data standards. Education and enforcement is a manual process. Thus, it’s easier for DBAs to manually compare and push change than educate and enforce.”
Well, there’s your answer. Thus, the solution is not about cutting the SLA from 72 hours 12 hours as the first Why might indicate. That will simply lead to more broken SLAs as it’s already being broken today. The TRUE answer, is that a way to enforce and educate without creating an overhead burden for the Data Group and DBAs.
Database Release Automation (DRA) is exactly what’s needed here to solve this root cause. Database Release Automation is tooling that allows speed and safety for database changes. Think DevOps Database. This is not provisioning the database server; this is DDL and DML change to your database internals.
Automating database releases mirrors what we have already accomplished with application release automation, but does not have to be done after adopting ARA. In fact, many of our DRA customers at Datical have adopted DRA prior to ARA, or have stated that they regret doing ARA prior to DRA. They have identified the database change process as the biggest impediment to fast releases. (Learn more about this. Check out our market study with CIO Magazine.)
The strategy for adopting Database Release Automation (or creating the DevOps Database) is simple, yet amazingly impactful. Let’s look at the strategy first before diving into the value.
- Process standardization – Database Release Automation allows you to enforce your release process across all environments, from Dev to Test to Production and all points in-between. DRA enforces the same release mechanism and process independent of a human.
- Rules automation – DRA provides enforcement of corporate, regulatory, and technical standards. An example of a technical standard would be that indexes cannot be comprised of more than 3 columns. So, when a developer submits an index that comprises of 4 columns, that change should be automatically rejected, just like a failed used case will break the build.
- Change simulation – Knowing the impact of the change prior to being persisted to the database allows for environment transparency and allows for code reviews of proposed database changes.
- Enhanced auditing – All persisted changes for all environments, including who requested what change and where, is invaluable for many audit use cases, such as SOX compliance.
- Version Control the Database – Just like you can recreate your application from source for deployment to newly created environments, you should have the same ability with your database. Taking database dumps from another environment and restoring is not the way to do this as it provides not insight into change or allow you to recreate an environment at a specific release level.
The value of a DevOps Database is off the charts. We’ve had customers that have taken a week-long manual process down to an unattended automatic process that takes seconds with self-service. Here are 6 great reasons to get started with database release automation.
- Less time spent on database change task – This is the key value proposition of DRA. As you evaluate DRA tools, you absolutely must time the process and attempt to get to a time frame that is only comprised of automated machine time, not a human’s time.
- Less time spent on script reviews – Any DRA tool that still requires you to 3-way compare your changes is just asking for trouble. You’re trying to get your data professionals on higher value activities, not staff a help desk.
- Decrease deployment errors to production – As you have the same process for change from Dev to Production, you will have a high consistency and decrease in environment deviation leading to less errors in production. You will simply catch errors earlier where they are faster and cheaper to correct.
- Less time spend on audits – 3-way compare is for suckers. When audit time comes, you should be able to capture and email a report in less than 30 seconds. Spending time verifying change manually is unacceptable.
- Better adherence to corporate governance – Automating standards will lead to a 100% level of enforcement. Think Robocop for your database changes.
- Visibility to database change status – All DRA tools should come with a dashboard that shows who changed what, where, and when to aid in transparency and communication. No more spreadsheets!!!