We (Redgate) released SQL Change Automation a few weeks back. This is the first stage to implementing a combined toolset that works with both state/comparison development and migrations based development. The change updated both our migrations toolset (previously ReadyRoll) and our build/release cmdlets (DLM Automation) to SQL Change Automation (SCA).

I have pipelines that are setup with Redgate DLM Automation tasks. This post shows how I updated the first of these to SCA.

Finding the Build

Here’s my current VSTS build pipeline for a project. Note that these are DLM Automation 2 tasks. There is a single task that you configure with the Operation (on the right) to build, test, or sync a database.

Note that there is a version drop down at the top of the right side. Here I need to drop this down to find the SCA task, which is version 3.

Once I select this, you’ll see that my task changes to SCA, both on the left and right.

I can change both tasks to v3 and I’m set. This is really the change that we’ve done, and we’ve combined operations. If you drop this down you will see there are SCA (migrations) projects here along with SQL Source Control state projects.

This means that if I convert from a SQL Source Control/state project, my pipeline stays intact. I’ll just change the operation from a build with SQL Source Control to one with SCA.

This mostly works, but there are some path differences for release, so I’ll talk about those in another post.

This is a simple change, but it’s important for future strategy. You can watch a bit of our strategy in this SQL in the City video on the database deployment pipeline. If you want to give this a try, download SQL Source Control and/or SQL Change Automation and start a test project.