Product articles SQL Change Automation SQL Change Automation
Sometimes the tool just fits –…

30 June 2015
30 June 2015

Sometimes the tool just fits – using SQL Change Automation and Octopus Deploy for Data Change Control

From a business risk perspective, data change can be just as significant as code or schema change. Sometimes even more so; an incorrect static (or reference, or master) data change can drive your software’s behaviour more dangerously askew than pretty much any bug can.

Imagine treating a retail customer for an investment fund as a corporate by mistake, or vice versa (a potential regulatory breach). Or booking the repatriation trades in the wrong currency (and not finding out until they settle, and hit the wrong cash balance). And what are your web customers going to do when the ‘choose credit card type’ drop-down is empty?

There are of course whole businesses and a whole software category dedicated to master data management (MDM). If you’re a customer of a big MDM vendor and have data governance and data change control locked down and causing no concerns – good for you. But many firms find that they have to build their own workflows.

If you’re using the Redgate stack for database version control and database automation, and also use Octopus Deploy for release management, you might just find that you have a perfectly serviceable option at your fingertips, using software you already own.

Whether you’re using the SQL Change Automation extension, in Visual Studio, or the SQL Source Control extension in SQL Server Management Studio, you have the option to register any given table as a static data table, bringing it under the same control as your schema and database code. This example uses SQL Source Control:

SoC register static data
When you commit change and build your database as part of your continuous integration (CI) process, the deployable package includes the committed state of your static data.

SoC commit static data

With SQL Change Automation product, when this package is prepared for deployment against any given target, you are given a clear GitHub-style diff report for review before any change is applied.

This review file (changes.html) is associated with this deployment against this target, and no other. If the target database is changed (schema, code or static data) before the change is applied, the deployment is invalidated and will not be applied, regardless of approval. (For more information on drift protection across your environments, have a look at the article,  Dealing with production database drift).

What’s more, if you’re using Octopus Deploy with SQL Change Automation, just adding a review step to the deployment process creates a durable association between the change being approved, the approver’s comments, and the deployment itself.

Data change approval step

So don’t just keep these tools within the dev team; invite Operations, Risk, Compliance, Legal – anyone who has to approve change – to the party.

Combine it with schema documentation and you have a clear picture for the business approver to understand, and a clear and durable audit trail to keep you looking good.

Tools in this post

SQL Source Control

Connect your databases to your source control system.

Find out more

SQL Change Automation

Continuous integration and automated deployments for your SQL Server database.

Find out more

Share this post.

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

You may also like