Kate Duggan

3 February 2017

Continuous Delivery – how do application and database development really compare?

Our recent State of Database DevOps survey showed that DevOps practices like continuous delivery are still far more commonplace in application development than in database development. So why is that – and why should teams care? 

Building great software is never just about the code. It’s also about managing multiple teams, timelines, and frequently changing business or customer requirements. As organizations face increasing pressure to create and release software more rapidly, DevOps has emerged as an effective way to help teams collaborate and speed up the delivery cycle.

At the heart of the DevOps approach is the concept of continuous delivery. Coupled with the cultural change that DevOps requires, continuous delivery enables teams to work together to produce software in short cycles so they no longer need to rely on ‘big bang’ releases to provide value to customers. Instead, they have reliable and repeatable processes in place to provide a steadier stream of more frequent deployments, both increasing efficiency and reducing risk in the software release process.

So what could that mean for database teams? No more repetitive and tedious development and testing processes, no more crossing fingers and hoping for the best when deploying to production, no more pain from trying to roll-back after a catastrophic failure when you have no idea what state the database was previously in. Sounds good, right?

Yet our recent State of Database DevOps report confirmed that continuous delivery practices like version control, continuous integration, and automated test and deployment are still far more commonplace for application development than they are for the database.

Only 20% of respondents practice continuous integration for the database, compared with 38% for the application, while 22% automate database deployments, again compared with a much higher figure of 38% when it comes to releasing applications. So there are still a lot of database professionals out there who aren’t yet seeing the advantages that continuous delivery can bring.

Why is that?

It’s unlikely to be a love for the tradition of laborious, time-consuming, complicated, and error-prone database change management. It’s more probably down to the fact that database professionals are concerned about the protection of their organization’s data.

This was also evident in the results of our survey. ‘Preserving and protecting business critical data’ was cited as one of the top three challenges in integrating database changes into a DevOps process.

Unlike applications, databases contain state that needs to be managed and preserved as part of rolling out new or updating existing software. Yesterday’s database can’t simply be thrown away or overwritten when changes are deployed. To do so risks the loss of business-critical data.

So processes are needed to safeguard that data as well as the behavior of applications. Otherwise, database development can fall out of step with application development, leading to a fragmented workflow and getting in the way of the combined goal of delivering great software faster.

The ideal scenario is to have application and database development teams working in parallel and coordinating changes through the same processes. This increases the likelihood of releasing more stable, consistent builds. It also helps remove unnecessary delays to software delivery.

And the benefits can be enormous. By providing a common series of development, testing, and release processes for application and database development teams, organizations see much greater collaboration on application features and their database requirements as well as opportunities to continuously learn and improve the way software is delivered. These are cornerstones of the DevOps approach, contributing to improved quality over the course of the software lifecycle and reduced risk at the point of release.

The foundations are there for many already. More than half of the respondents to our survey were already versioning their database objects alongside their application code. By putting database changes into source control, teams benefit from a single source of truth on which they can base development and deployment processes. The rest can be built from there.

To learn more about how you can extend DevOps practices to SQL Server databases, visit us online.