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 five whys.
Problems (specifically ones dealing with software releases) do not have a single root cause and require iterations to find it. Toyota found anecdotally that five 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 need even after adopting DevOps and application release automation (ARA).
- Why are our software releases taking one 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 to 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.
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.
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.
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 three columns. So, when a developer submits an index that comprises of four columns, that change should be automatically rejected, just like a failed used case will break the build.
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.
All persisted changes for all environments, including who requested what change and where, is invaluable for many audit use cases, such as SOX compliance.
Now that you understand the strategy, lets take a look at the 6 reasons to get started with database release automation.
1.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 six great reasons to get started with database release automation.
2.Accelerate App Release Cycles
Accelerate your application release cycles by spending less time on database change tasks. 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.
3.Focus on More Important Initiatives
Focus on more important initiatives by spending less time on database script reviews. Any DRA tool that still requires you to three-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.
4.Improve App Performance and Data Security
Improve application performance and data security by decreasing 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 fewer errors in production. You will simply catch errors earlier where they are faster and cheaper to correct.
You can also improve data security through better adherence to corporate governance. Automating standards will lead to a 100% level of enforcement — think Robocop for your database changes.
5.Spend More Time Delivering New App Innovations
Spend more time on delivering new application innovation and less time on database audits. Three-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.
6.Keep Dev and Ops in Sync by Providing Better Visibility
Keep Dev and Ops in sync by providing better 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!