Releasing Databases in VSTS with Redgate SQL CI and Octopus Deploy

You can still do Database Lifecycle Management (DLM) workflows in the hosted version of Team foundation Server (TFS) in Visual Studio Team Services (VSTS) . If you are doing your database development in SSMS, you can use a mix of tools to set up the functionality in VSTS. Jason Crease demonstrates how to build and deploy a simple database into the test environment using SQL CI, SQL Source Control, Octopus Deploy, tSQLt, SQL Cop and SQL Release, all with the minimum of hassle and effort.

Microsoft’s Visual Studio Team Services provides a convenient hosted version of TFS. With the recent addition of the Visual Studio Marketplace, it’s now really easy to create build-definitions to do your ALM and DLM (application and database lifecycle-management) workflows. In this article I’ll present a quick example of a DLM workflow.

You code SQL in SSMS, commit it using Redgate SQL Source Control to VSTS, build it using SQL CI in VSTS, and deploy with SQL Release in Octopus Deploy. Using the new extensions for SQL CI and Octopus Deploy, it’s straight-forward to setup advanced functionality in VSTS.

Database Continuous Integration in VSTS

My project, WidgetShop, has a SQL Server database. I’ve developed this database in SSMS, and used Redgate SQL Source Control to source-control the schema.


My source-control system is VSTS. In VSTS code explorer, I can see my database schema:


Next in the chain I have a VSTS build-definition. This uses a few different tasks: Redgate SQL CI extension tasks, the Publish Test Results task, the Copy and Publish Build Artifacts task, and the Octopus Deploy Create Octopus Release task.

This system builds and tests the database. It then sends the package to Octopus Deploy – a popular deployment management system. I’ve set it up to deploy the package just to the testing environment – more on this later.


The Redgate SQL CI Extension

The Redgate SQL CI Extension is available from the Visual Studio Marketplace. Using this extension, you can add tasks to a VSTS build definition that will build a NuGet database package from a schema, run tSQLt tests, sync the schema to a target database, and publish the package to a NuGet feed.

I also publish the tSQLt test results using the Publish Test Results task. This produces a nice interactive way to explore your test results from within VSTS.


The Octopus Deploy extension

In the Visual Studio Marketplace, there is an Octopus Deploy extension. This extensions adds a task to your build-definition task-list. This task lets you trigger an Octopus Deploy release from a VSTS build. It has several nice configuration options too, e.g. including all the relevant TFS Work Items in the release’s release-notes. See the Marketplace page for more information.

I’ve added this task to the end of my build definition. If the database builds and passes my tSQLt tests, a release will be created in Octopus Deploy. You can optionally deploy the release to an environment. Here, I’m deploying it directly to my Testing environment from the build.


Doing a Build

I have a trigger on my build definition to cause a build on every check-in. So committing a schema change using SQL Source Control will cause a build.


VSTS Build agents can either be hosted (i.e. managed automatically by Microsoft on Azure) or on-site (run by you in your local environment). Hosted build-agents may be convenient, but they make it hard to deploy to on-site resources. You’d have to open your Octopus Deploy server (and often SQL Server) to the internet, which is difficult and insecure. That’s why I’m using an on-site build agent.

My build does these things:

  • Using the Redgate SQL CI extension, build the scripts folder to a NuGet package.
  • Publish this package as a build artifact. I often find build artifacts useful, but this step is not strictly necessary.
  • Using the Redgate SQL CI extension, run the tSQLt tests.
  • Publish the test results to VSTS. This creates the nice test visualisations and results in VSTS.
  • Publish the NuGet package to my on-site NuGet feed. 2364-publishPackage-daa16b1e-db27-4f3d-8
  • Sync the package to a database. I use this to update a CI database to the latest source-code. This gives my team a database which represents the latest source-controlled schema.
  • Release to my Octopus Deploy server.

I can watch the progress of the build from VSTS.


Deploying to Octopus Deploy

The final step deploys a build to Octopus Deploy. When I go to Octopus, I can see this release – which is numbered as 0.0.9. It’s only deployed as far as testing. If I want this build to go to Preproduction and Production, I should click ‘Deploy’ to advance through the Octopus environments.


Within Octopus Deploy, I’ve set up a deployment process that uses Redgate SQL Release to deploy to multiple environments. For a tutorial on how to set this up, see here.