The most important feedback I get about the current state of database delivery is directly from the DBAs I meet with. Their DevOps teams are stuck in manual database delivery purgatory. Development managers just want the database delivery to work like their software delivery already does. However, databases are a different beast altogether. Unfortunately, DevOps for Database has taken a back seat to source code, as we see the tools and methodologies perfected, leaving database automation to play a game of catch up.
Another issue is that DBAs don’t trust deployment automation like code developers do. All DBAs have been burned by breakdowns or conflicts at one point or another, and most of them just feel they need to take matters into their own hands to ensure the release is done right. We recently surveyed over 200 DBAs, and the largest percentage of them noted mistrust of automation as the biggest barrier to adopting continuous delivery for their databases. In the same survey, only half of the companies doing continuous delivery of their code said they are also doing DevOps for Database. This needs to change soon or database delivery will be stuck in the past and slow down all company releases.
Databases hold the most vital company information and they need to start being treated like they matter as much, if not more, that the code being written for a company’s software. So, the question is, how do we close that gap between source code automation and database automation?
The answer is simpler than you might think. We need to bring the same processes for source code continuous delivery to DevOps for the Database. What a novel concept!
DevOps for Database requires best practices just like source code. Deployment practices need to be enforced. Version control needs to be enforced. Safe automation processes need to be created. You need to include the database in the continuous process and feedback loops. The most important thing is to make sure you have a way to control these processes, and if something needs to be handled there will be automated notifications and red flags to point out the issue.
That being said, ensuring safe continuous delivery of databases is not so simple. Databases are not a collection of files; they hold client information, transaction data, application content, etc. To make automation really work there needs to be a solid transition code created to handle database schema structure, database code, and content such as metadata.
Furthermore, there are organizational-level changes that will be required in order to ensure proper continuous database delivery. Both DBAa and C-level management will be required to adopt these development methods for databases. It can’t be and isn’t a one-person job. Both sides need to advocate for database automation.
Everyone recognizes the importance of the database to the organization. That is the reason DBAs are so afraid to automate and management is not forcing it. It should be just the opposite! Their sentiments on database control and automation need to be more positive. The question they are asking is – what could go wrong if we bring continuous delivery to our database? The question should be – what could go wrong if we don’t bring continuous delivery to our database?
Yes, database deployment automation is not a simple process, but the fact is that ensuring continuous delivery means increased productivity, faster time to market, reduced risk for new releases, and higher quality with fewer bugs. Otherwise your database will keep lagging and eventually you can find yourself in a difficult situation down the road.
About the Author
Yaniv Yehuda, CTO, DBmaestro (http://www.dbmaestro.com/)
Yaniv is the Co-Founder and CTO of DBmaestro, the leading provider of DevOps for Database solutions which enable control of database development and deployment. Yaniv is also the Co-Founder and the head of development for the Extreme group, a leading IT services solutions provider group.
