DevOps has moved into the mainstream and practices such as continuous delivery now are being widely adopted. But what about the database? Applications often have a back-end database that needs to be developed and maintained at the same time.

At first glance, there doesn’t seem to be an issue. The recent “State of Database DevOps Survey” from Redgate showed that 75 percent of companies have developers in their team who work across both applications and databases.

Investigate a little deeper, however, and the cracks start to appear. The survey also showed that while version control is used by 81 percent of those in application development, it falls to 58 percent for the database. The same is true for continuous integration and automated deployments—39 percent and 33 percent for the application, 20 percent and 21 percent for the database.

What’s going on? If developers are increasingly responsible for the database as well the application, why can’t the principles of DevOps be applied across both areas? That way, rather than the database being the problem at the end of the pipeline that can (and many times does) cause releases to fail, it becomes part of the pipeline.

Especially when you consider that the biggest downside of traditional siloed database development is the downtime often experienced when introducing changes. That’s not to mention slowing down releases and preventing companies responding rapidly to changing business requirements.

A typical DevOps workflow looks something like this:

Code is version-controlled so different developers can work on multiple branches at the same time. When it’s checked into the version control system (VCS), often at the end of each day, it triggers a continuous integration process that builds and validates the changes. Once the changes are complete, a release management tool then pushes them through the testing, QA and staging environments and there’s a final review before the changes are deployed to production.

Not every company does all of this, but many do different parts of it and plan to extend DevOps practices into other areas. They might start with version control, for example, get the team accustomed to checking in changes, and then move on to continuous integration.

It works too. The “2016 State of DevOps Report” from Puppet found that organizations practicing DevOps deploy 200 times more frequently, recover from failures 24 times faster, and have a 3 times lower change failure rate. DevOps has moved from a developer-led approach to one that businesses are actively encouraging.

Thing is, database development can be part of the same picture as application development. Let’s take another look at that DevOps workflow:

The same workflow, but this time with database development included. Note that there are no extra boxes or arrows, there are no asterisks with caveats, and the only difference is that database development has been added to application development and a DBA has stepped in to the frame.

But how can database development be added to the DevOps mix when it requires new tools, separate processes, a different mindset? The answer is to think about integration not separation, and extending the current infrastructure not replacing it.

Application development teams, for example, will use a VCS like Team Foundation Server (TFS) or Git, a continuous integration system like TeamCity or Jenkins, and maybe a deployment automation tool like Octopus Deploy. They’ll also have a favored IDE for application development, probably Visual Studio, and if they do database development, they may well work in SQL Server Management Studio as well.

Ask them to add to their workload with unfamiliar tools and development environments, or enforced policies and processes, and the shine of DevOps starts to lose its luster. What was freeing them to perform better is now tying them down to an unwelcome way of working.

Ask them, on the other hand, to use the same tools and processes but extend their capability to database development and it’s a different story. If they already version application code using TFS, for example, there are database version control tools out there that plug into it so that database development becomes an additional part of the process, not an extra process.

The same is true for continuous integration, release management and deployment. At every step of the DevOps workflow, database development can join application development so that it’s a natural partner rather than an unwelcome guest.

But just how realistic is this approach? When development teams are already facing the challenge of introducing DevOps, is it a pipe dream to think the database will even be considered as part of the picture?

According to Microsoft, no. When Visual Studio 2017 was launched in March, the Enterprise edition included Redgate Data Tools in the installer to make it easier for users to implement DevOps practices when building, deploying and maintaining their SQL Server databases.

As Shawn Nandi, senior director for Cloud App Development and Data product marketing at Microsoft said at the time: “We think this is an important step forward to help companies extend DevOps practices to all parts of their applications.”

So if you’re considering adopting DevOps, remember the database can be part of it, too.

About the Author/Matt Hilbert

Matt Hilbert is a technology writer at Redgate Software with 20 years’ experience working for lots of the world’s biggest tech companies – and many of the smallest. He has a particular fascination for emerging technologies and is on a continuing mission to decompile, untangle, and explain techspeak to a wider audience, and excite people about the endless possibilities technology offers.