Steve Jones

16 October 2015

DLM S2 – Automated Version Control

 In my last post, I looked at the first stage of our maturity model, the Manual level. In this post we move to the S2 level, which is characterized by the use of a formal Version Control System (VCS) and process.

S2 – Automated Version Control

Many software development organizations have implemented a VCS for their software development languages. The tight integration of the version control systems with many IDEs makes this easy for developers working on front-end and middle-tier application code.

However, this use of a VCS often doesn’t extend to the database. We find many clients using a development database as a code repository, without any tracking or backup of the database code.

The benefits of version control, or source control, are widely recognized. Backups of the code, versioning for tracking the state of projects as they may relate to others, branching and merging to provide isolation from conflicting requirements, and more. Professional developers understand that a VCS is necessary, yet many of them fail to extend that view to their database code.

There are many reasons this may be true, but a VCS for the database provides a basis for building a database whose code is consistent at a point in time. That consistency is important for ensuring a known set of code can be tested and deployed to other environments without issues. In many ways, an automated source control process for your database code is the foundation on which a Continuous Delivery, or mature software pipeline, is built.

Our characterization of an S2 Automated Version Control level requires the integration of your database development tools (usually SSMS for SQL Server developers, SSDT or other editors for front end developers working with a database) with a VCS. The integration must ensure the format of all database code is consistently stored in a way all developers understand. In addition, there must be a way to ensure changes made to a development database are not lost and are captured in your VCS.

There are relatively few ways to accomplish this, but all of these techniques require tools to support a VCS in some way. Whether you build your own software to manage this, or purchase a third party tool, we highly recommend you implement some link between your database code and a VCS.

This link should ensure all changes made to a database are noted and alerts raised if changes are not stored in the VCS project for that database.

Once this is complete, you can start to progress towards a more mature, better engineered database development process.

After reaching this second stage and bringing a foundation of management to your database code, the next stage is the S3 stage at which a Continuous Integration (CI) cycle is introduced and code is rigorously and repeatedly tested.

You can read more about that, and the other stages in Redgate’s Database Lifecycle Management maturity model, by dipping into my other posts:

An Overview of Database Lifecycle Management

Stage 1 – The Manual Stage

Stage 2 – Automated Version Control

Stage 3 – Continuous Integration

Stage 4 – Release Management