Top 4 Reasons to Combine Database Release Automation with Application Release Automation

Software is reshaping industries, from healthcare to finance to retail and beyond. The pace of change is accelerating, and companies must master their applications in order to survive in the digital era. In the software economy, speed is the new standard.

To achieve their goals of faster time-to-market, companies are adopting faster, more iterative development methodologies to be able to change and adapt more quickly. They have replaced age-old waterfall development methodologies with agile practices. From an infrastructure perspective, they have also invested in modern architectures and cloud technologies to achieve higher efficiencies. Some companies have combined these two approaches by adopting DevOps—investing in new tools and processes such as infrastructure automation and continuous integration—to clock even faster speeds.

As companies have adopted application release automation (ARA) technologies to help increase the pace of software delivery, a new constraint has emerged: data. Data has long been the neglected discipline, the weakest link in the tool chain, in fact most companies—even those are using the latest ARA and DevOps automation tools—are still managing and deploying database changes manually, anchoring development teams. Put differently, most organizations attempt to support modern, agile development environments with decades-old database management processes —the result can be likened to mounting a modern Ferrari on Model T tires. It’s a great way to get nowhere fast.

The Cost of Ignoring the Database

The costs of ignoring the database release process accrue on many fronts. Let’s examine the impact upon four key areas.

1. Cost of Adding DBAs: The math is pretty straightforward. If you’re relying on DBAs for all release-related upgrades, then you’ll need more DBAs as you increase the rate of application releases. If 10 DBAs can handle 100 changes per week, then you’ll need at least 20 DBAs to handle 200 changes per week.

But it’s not that simple.

As you hire more DBAs to keep up with the work, you’ll also have to hire more managerial people. You’ll have to devote more resources to support infrastructure. You’ll have to invest more in training. And you’ll have to account for the months/years of on-the-job experience that the 10 new DBAs will require to become as efficient as the original 10. The costs add up very quickly, particularly in comparison with the substantially lower cost of scaling through automation.

2. Mistakes and Increased Risk: No matter how large your staff of DBAs, you’re always just one human error away from a mistake—possibly of catastrophic proportions. Every database schema change review and deployment relies upon the skill, reliability, and dedication of a human. And humans have bad days. They get sick. They perform their jobs with outside troubles and stresses burdening them.

The result is the inevitability of mistakes and less-than-machine-like reliability. The carryover can be an application that significantly underperforms, or mis-performs, or crashes altogether.

The human touch also increases the risks to data integrity and security. Grants embedded in stored procedures, for example, offer a huge opportunity for human error or malicious intent to derail an application and expose its data.

3. Diminished Productivity: The DBA logjam can perpetuate a backflow of delay that echoes throughout the development process. It’s quite common for both development and QA teams to spend time idle while waiting for database changes to be reviewed and deployed. Our own customers tell us that in the past, 5% to 10% of their developers’ time was spent waiting on schema changes. (That’s past tense because we make that problem go away for our customers).

That’s obviously a terrible waste of productivity.

4. Opportunity Cost: All of the above adds up to D-E-L-A-Y-S. Slowdowns in development, slowdowns in testing, and delayed releases. And applications simply can’t do what they’re meant to do—which boils down to either making money or saving money—until they’re released into production.

Whether an application is new, or it’s an upgrade of features and functionality to an existing application, it’s costly not to have that application in production.

It’s Time to Go Faster

If you think application release cycles are shortening and starting to move at a quicker pace, you’re correct. But the pace of application release is nothing compared to what it could be when combined with database release automation.

Database deployment automation in conjunction with application release automation offers companies the ability to break the application release logjam created by today’s manual database deployment processes.  In addition, these combined solutions offer a great opportunity to improve productivity and performance, allowing development, test and DBA staff to focus on more important projects and initiatives while maintaining workloads at a sustainable level. Database deployment automation helps to eliminate otherwise unavoidable incidents of human error while increasing data security and application performance and reliability. Put simply, database deployment automation helps speed the delivery of better performing applications into production more quickly, more safely and more reliably.

The benefits of combining database deployment automation with application release automation are quite quantifiable. The typical organization can anticipate saving millions by simply teaming Datical DB with existing application release automation tools.

To learn more about the benefits of using database deployment automation and application release automation read our white paper, The Evolution of Application Release Automation.