6 Reasons to Get Started with Database Release Automation

Problems, specifically ones dealing with software releases, rarely have a single root cause. To fix these problems, you might have to use multiple iterations of the software to find them. And, when fixed, you might have also found that your software releases are still not happening as quickly as you would like even after adopting DevOps and Application Release Automation (ARA).

Database Release Automation (DRA) can help fix these problems. 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.

Releases via database automation 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 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Better adherence to corporate governance – Automating standards will lead to a 100% level of enforcement. Think Robocop for your database changes.
  6. 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.

What is the Strategy for Database Release Automation?

The strategy for adopting Database Release Automation (or creating the DevOps Database) is simple, yet amazingly impactful. Here’s what you should be looking for.

  • 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.

To learn more about database release automation, read our white paper, How to Get Started with Database Release Automation in 4 Easy Steps.

Seeing is believing.