Azure DevOps Classic Releases

How to use CAT in Azure DevOps Classic Releases.

If you use classic releases in Azure DevOps instead of pipelines defined in YAML, the integration of CAT is a bit different than described in our documentation.

This tutorial describes how you can hide sensitive information, such as connection strings or their parts, while still keep and use the same code base locally and in pipelines without any changes.

Prepare CAT Project File #

First, create a simple CAT project file:

Notice two things:

• the project contains junit output - it is needed for Azure DevOps, wit that it can display nice charts and overview with failed tests.

• Connection string is not in expected format.

The goal is to NOT have the connection string in the project file, while being able using it without any changes.

On your machine: Create an environment variable with the same name you used in the project file - AERO_DWH_CONNECTION_STRING if you follow the tutorial exactly. (Creating an environment variable is very simple task, use your search enginge if you don’t know how to do that.) Do NOT put the percent signs in the name when you create the environment variable - it is just a clue for CAT that this is an environment variable. The value of the created variable should be the entire connection string (as you’d use it in the project file).

When you install PowerShell / cmdline / VSCode or whatever you use, it should then know about the environment variable and you should be able to use CAT, as if the connection string was hardcoded. If CAT still complains about incorrect connection string, restart your machine first.

Create the Release Pipeline #

Define variables in your classic release pipeline. Often you’ll have more environments, so you will have more variables. Put the entire connection string into the variables and set them as secret:

In the tasks of your pipeline, don’t forget to map the secret variables to environment variables:

And that’s it. You can now use the same code locally during the development and in the Azure DevOps pipelines. No need to preprocess anything. Just commit and push your changes, Azure DevOps will be able to use it without any tweaks.