So what’s the real state of database DevOps?

Source – 126kr.com

DevOps survey among 1,000 software professionals. The survey included developers, database administrators, and those at management level, and over half of the companies involved employed more than 500 people. I took a quick glance at the results ina recent blog post and talked about some surprising findings:

• Within two years, 80% of companies will have adopted DevOps
• The biggest driver for including the database in DevOps is to increase the speed of delivery of database changes
• The key obstacles to implementing DevOps are a shortage of skills and a lack of alignment between development and operations teams

Those are three big headlines in themselves, but the deeper you dive into the survey which has now been published, the more fascinating it becomes, particularly for those who are wondering how on earth to bring the database into the DevOps fold. Some of the key questions – and answers – I found are as follows.

Does your team include any developers who work across both databases and applications?

Across every company surveyed, the answer was broadly the same: 75% of developers are responsible for both database and application development. So if you’re a developer and you’re not already familiar with databases, now’s the time to hone up on your SQL coding skills.

60% of developers also build database deployment scripts, and 39% are responsible for deploying database changes to production. In those companies which have already adopted DevOps, the numbers rise, with 74% of developers building scripts, and 45% also deploying them.

How frequently does your team deploy database changes?

Remember the biggest driver for including the database in DevOps being to increase the speed of delivery of database changes? Here’s why.

44% of those companies who practice database DevOps deploy database changes daily or, at the very least, more than once a week. Among those who have no plans to adopt DevOps, this falls to 28%.

Now the reason here may be that they face less pressure to shorten the release cycle, but consider the answer to the next question before you make your mind up.

What’s the greatest drawback of traditional siloed database development?

The number one answer to this question was the increased risk of failed deployments or downtime when introducing changes. The next three drawbacks were just as telling: slow development and release cycles; the inability to respond to changing business requirements; and poor communication between development and operations teams.

So in other words, companies know there are problems with traditional database development. That said, though, what’s holding them back?

What’s the biggest challenge in integrating database changes into the DevOps process?

No gold stars to hand out here. It’s the same challenge that prompted the move to DevOps in the first place: problems synchronizing application and database changes, and overcoming the different approaches teams have to development. Once you introduce DevOps practices into application development, however, the inclusion of the database in the process becomes easier because many of the issues are part of the way to being resolved.

How long will it take you to introduce a fully automated process for deploying database changes?

This question, for me, provided the most telling answer of the whole survey. Of those who haven’t yet adopted DevOps, 43% say it will take longer than two years to apply the same practices to the database. Now that, perhaps, isn’t very surprising.

What is a surprise is that 68% of those who already practice DevOps say it will take less than a year.

Given the fact that this was a broad survey covering many different industry sectors and many company sizes, there is no bias in this result. The reason appears to be that once you start doing DevOps, it becomes a lot easier to extend it across all development.