Environment variables and Azure Pipelines

Some days ago talking with Sergio Navarro (if you don’t follow him you should) he raised a question about setting environment variables in an Azure Pipeline so a container can use it in the build. The answer was easy, the great news are: all variables declared in an Azure Pipeline are “executed” (I couldn’t find a better word) as environment variables in the agent, and not only that, all environment variables in an agent can be retrieved as simple variables in the pipeline.

This is easier to understand with a very simple example, I’m using a Windows agent and just plain Powershell, but this can be adapted to Linux/Mac agents using bash, just one important thing to take care: Linux/MAc environment variables are case sensitive, Windows are not case sensitive.

We have this YAML build (hmmm the coloring on the second line is not correct):

image

It is just a simple build with one Powershell task, printing out the usual PATH environment variable, using the common syntax of Pipelines variables $(variable-name) and then printing out. We also configured the variables in the properties of the Azure Pipeline with a Demo variable:

image

When we run the build, we obtain the following output:

image

Check it out:

  • The first Write-Host, has printed out the PATH environment variable without any problem, and using it as it was a simple Pipeline variable.
  • The second Write-Host has printed out the content of the demo Pipeline variable but using it as a computer environment variable on the agent.

With this simple demo I hope it gets more clear, and you are ready to use this feature in your Azure Pipelines.

Azure DevOps from Hosted XML process to inherited process

Migrating a Team Foundation Server Azure Devops Server from on-premises to cloud, it is common we have done some customizations to the process templates, which can’t be migrated directly to any of the existing templates in Azure DevOps Services.

When this happens, for every project with customizations, a new Hosted XML process is created in the Azure Devops Services destination, if navigate to: https://dev.azure.com/organization/_settings/process?_a=all you will see something like this, with the list of all the projects:

image

As you can see in the figure we have the three basic process template of the inherited process and then a line for every project with its own process which are known as Hosted XML processes. To get full advantage of the new customization UI we can migrate from the Hosted XML to the inherited process. But before proceed review first this article, as some of the process customizations that can be done in the old Hosted XML process are not preserved when migrating to inherited process: https://docs.microsoft.com/en-us/azure/devops/organizations/settings/work/upgrade-support-hosted-to-inherited?view=vsts

The migration to inherited process is done in two steps: clone the process as inherited process, move the existing process to the inherited process.

Clone process

To clone the process, click on the ellipsis icon in the selected project and click on Clone process to inherited:

image

This will show a summary of what is going to do and what will be migrated and what will be lost, on of the most important things which will be lost is any workflow restriction you set up in the old process, as the new process model allows Work Items to go from any state to any state:

image

When you click on continue, it will ask for a new name to the inherited process template and which of the main templates to be set up as parent:

image

Just click on Ok and after a while we will have the new inherited process template:

image

Migrate projects

To finish the migration process, now we have to go to each of the projects we want to apply the new inherited process, click on the name Hosted XML project you want to migrate to see its details, and go to Projects tab where you must see the project belonging to this Hosted XML process template:

image

If you click on the ellipsis on the dropdown menu you will see an option to change process (is the only option available) and if you click it a screen asking to select the destination template will be shown, in which you will be able to select the previously migrated inherited process template, just click ok and you are done.

Now you will have the process using the new inherited process template, and you can start doing customizations with the new model, using the UI directly from Azure DevOps Services rather than using the old XML customization process.

Hope this helps you.