10 May 2019
10 May 2019

Six reasons to version control your database

For most application developers, it’s unthinkable to work without version control. The benefits of tracking and retaining an incremental history of code changes are long understood in the world of software development. No surprise then that the overwhelming majority of respondents in our 2019 State of Database DevOps survey confirmed they’re already using this practice for their application code.

But it was a different picture when we asked about database version control. Only 55% of those same people stated that they used version control for their database changes. In a way it’s understandable, as database version control was, for a long time, seen as unfeasible. But now that’s no longer the case, it’s time the database was treated in the same way as the application.

Standardizing processes across teams, projects, and across database and application code unlocks significant quality improvements and timesaving, as this blog post explains. It outlines the benefits of standardized team-based development and talks about the four steps you can take to introduce it.

It’s important because databases are increasingly in the spotlight due to the recent proliferation of data breaches, a multitude of new regulations, and the increased pace of database development. In this climate, the need for an incremental history of changes and more efficient processes is more compelling than ever, so if you’re not already versioning your database code, here are some of the reasons why you really should be, and some of the benefits you’ll discover:

1. Ease collaboration across distributed teams

Putting database code into a version control system makes it much easier to share code changes and coordinate the work of the various team members who are responsible for the database. The ability to rapidly share and manage changes makes it particularly important for teams based in different locations, and evidence shows that teams are increasingly distributed. The Stack Overflow 2019 Developer Survey, for example, found that the majority of developers work remotely more than once a month, and 12% are full time remote workers​.

With SQL Source Control, team members can choose to work on a shared database, safe in the knowledge that they won’t be over-writing each other’s work. With features like object locking, conflicts are easily avoided and developers can check code in and out with confidence.

Once the database code is in version control, the path is also paved for adopting a dedicated development environment approach. Giving each developer their own dedicated, up-to-date copy of the latest version of the database brings in the freedom to try out new things, risk-free.

2. Gain better visibility of the development pipeline

A version control system provides an overview of what development work is going on, its progress, who’s doing it, and why. It also maintains detailed change histories and can be associated with issue tracking systems. For example, SQL Source Control lets you associate database tasks with Microsoft’s Azure DevOps Server work items so that you have a complete view of your workflow.

3. Have the ability to roll back or retrieve previous versions of the database

While you should always have a reliable backup strategy in place, getting a database into version control also provides an efficient mechanism for backing up the SQL code for your database. Because the history it provides is incremental, version control lets developers explore different solutions and roll back safely in the case of errors, maintaining the referential integrity of your database while giving you a risk-free sandbox. SQL Source Control makes it easier by allowing users to simply roll back and resolve conflicts straight from the Object Explorer.

4. More readily demonstrate compliance and auditing

The change tracking provided by version control is the first step to getting your database ready for compliance, and an essential step in maintaining a robust audit trail and managing risk. Compliance auditors will require an organization to account for all changes to a database, and detail all those with access to it.

New data protection regulations are emerging all the time, and requests to demonstrate compliance or view the history of a database are increasingly frequent. With SQL Source Control, you can look through the full revision history of a database or database object and see exactly who made the changes, when they made them, and why.

5. Lay solid foundations for automating database deployments

The State of Database DevOps Survey also revealed that the task of database development has moved into the hands of the majority of application developers. This is encouraging because version controlling database code opens the door for automated deployments, which is common practice in application development.

This in turn removes the bottleneck created by not synchronizing application and database deployments. Complex processes become easier to automate and more repeatable, and deployments much more predictable because you’re working with a stable version of the database, which is being developed alongside the application. Using code checked into SQL Source Control as the basis for the automated builds and tests run by SQL Change Automation, for example, means that problems are found earlier, and higher quality code is shipped and deployed.

6. Synchronize database and application code changes

The 2019 State of Database DevOps Report found that the top two challenges in integrating database changes into a DevOps process are synchronizing application and database changes and overcoming different approaches to application and database development.

Having the database in version control alongside the application immediately addresses both concerns, because you always know the version of the database being deployed directly corresponds to the version of the application being deployed. This close integration helps to ensure better coordination between teams, increases efficiencies, and helps when troubleshooting issues. To make it easier, SQL Source Control plugs into version control systems used for storing application code changes like Git, Azure DevOps Server and Subversion.

Summary

While it’s true that database version control wasn’t always achievable, the availability of tools like SQL Source Control means it’s now easier than ever to version database code alongside application code across your organization.

Take your next step towards standardizing and automating your software delivery and become a truly high performing IT organization. If you’re among the 45% not yet version controlling your database, hopefully at least one of the six reasons above will have resonated enough for you to explore it further.

Find out more about putting database version control in place with SQL Source Control. SQL Source Control is part of the SQL Toolbelt, the industry-standard suite of tools for SQL Server development and deployment.

Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Related posts

Also in DevOps

4 steps to laying the foundations for standardized database development

In the increasingly demanding world of software delivery, IT teams are feeling the pressure to deliver value to customers – either internally to the business, or external users – quicker than ever...

Also in Blog

Database unit testing: Setting your team up for valued software delivery

There is constant pressure in software delivery to release at speed and often. To take an idea or fix and deliver it into the hands of customers in as little time as possible. However, releasing faste...

Also about database version control

SQL Source Control v7 Enhancements

With the v7 release, SQL Source Control now enforces Git hooks, and provides full support for working with Git repositories hosted on Azure DevOps. It also comes with pre- and post-deployment scripts ...