6 Reasons to Get Started with Database Release Automation
Problems, specifically ones dealing with software releases, rarely have a single root cause. You might have to use multiple iterations of the software to find them. And, once fixed, you may find that your software releases are still not happening as quickly as you would like (even after adopting DevOps and Application Release Automation).
Database Release Automation (DRA) can help fix these problems. Database Release Automation is tooling that enables speed and safety for database changes. Think DevOps for the Database. This is not provisioning the database server; this is DDL and DML change to your database internals.
Releases via database automation mirror 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. (Check out our market study with CIO Magazine.)
The value of applying DevOps to the database is off the charts. We’ve had customers take a week-long manual process down to an automatic process that takes seconds with self-service.
Here are 6 great reasons to get started with database release automation:
- Spend 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.
- Spend less time 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 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.
- Spend less time 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 leads to 100% 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!)
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 look 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 for 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. It provides no insight into changes and it doesn’t allow you to recreate an environment at a specific release level.
Learn more about database release automation. Read our white paper, How to Get Started with Database Release Automation in 4 Easy Steps.