5 Reasons to Create the Continuous Delivery Database
“Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.” – continousdelivery.com
Too often I hear: “We are doing Continuous Delivery.” When I ask how they provide the Continuous Delivery Database, I hear responses that are not continuous delivery at all. “We create a ticket” is the number one answer. That is NOT Continuous Delivery for the database.
A ticket to an external service team does not provide safety, speed, or sustainability. We’ve written a White Paper describing how to create the Continuous Delivery Database. Here are 5 reasons why you absolutely must do so.
- Align the speed of change for the database and the application.
You are moving at light speed with your application deployments. You are using build automation and application release automation (ARA) to deploy your apps. Sadly, when you hand off the database change to another team, you now have a two track process for releasing your entire application. This causes a cadence mismatch and results in slower releases. You will only release as fast as your database changes. That is the exact opposite of “quickly”.
- Enable Digital Transformation.
Digital Transformation is about accelerating the adoption of technology to enable agility in your company. Thus, your company will be able to quickly adapt to changing market conditions. Basically, be like Uber and not like Sears. If you are not providing continuous delivery for all components in your applications, you will not be able to digitally transform and your company will miss market opportunities that your competitors will not.
- Enable Self-Service for Development.
There is absolutely no reason for a development team to wait 7 days for a database change. In a two-week sprint cycle, that’s half a sprint. Unacceptable. Continuous Delivery for the Database allows for development to quickly release and improve the application. However, safety is an absolute must when you distribute responsibilities for changes. Thus, you will need both speed and safety to support self-service.
- Enhance Data Security.
Database release automation (DRA) assures better database code by eliminating errors that can cause application performance issues or downtime. And better database code also means better data security. Common mistakes (misplaced GRANT statements, for example) that make databases more vulnerable to breaches and data theft are eliminated.
- Your investment in DevOps and Application Release Automation will now return value.
We have heard from customers “In retrospect, I wish we had done the database first” when describing lesson learned in implementing DevOps. Though ARA is a necessary component in the DevOps toolchain, DRA is just as important. However, prioritizing the database over the application will return far more dividends than ARA. You must solve the hard problems first to make the impossible possible.
Now that you know the reasons to create a Continuous Deliver Database, read our white paper How to Create the Continuous Delivery Database white paper to begin putting it in action.