Update variable group using Azure DevOps rest API – POSTMAN

I was struggling to update a variable group using the Azure DevOps Rest API. In this article I will document the procedure using POSTMAN.

First things first you should create a PAT in order to interact with the API. If you do not know how to create such a thing you should read my previous article about running a build through a REST api on which I documented also the creation of a PAT.

Then you will need to add the access token under authorization tab of POSTMAN using Type Basic Auth. The PAT should be added as plain text.

Then you will need to add Content-Type as application/json under Headers.

Then you will have to create your URL. This should be of the format:

https://dev.azure.com/Organization/project/_apis/distributedtask/variablegroups/groupVariableID?api-version=5.1-preview.1

Important: You should use the version=5.1-preview.1. If you use the latest version you will notice an error on the call. This is a bug that has not been fixed as I found online.

In my example I wanted to update the variable group with the ID 5 and add a variable named new-var. The body of your request should be like below. Keep in mind that we use the PUT HTTP verb to update the variable group. This means everything that is inside the variable group will be discarded. If you followed all the steps correctly you will notice the below output JSON. This should indicate success on the procedure.

Lastly you can locate your new variable inside the variable group.

Variablegroups – Update – REST API (Azure DevOps Task Agent) | Microsoft Docs

Video tutorial on YouTube:

Pass parameters from build to release pipelines on Azure devops

When you need to pass parameters between your build and release pipelines it could be a real struggle if you do not want to use variable groups. Variable groups can accomplish the requested (to pass values between build and release pipelines) but this scenario is not useful for a parametric input which is a common case when deploying a project. You can accomplish that either by using a plugin from another publisher or by following the publish artifacts procedure that I will describe.

In order to pass variables between your build and release pipelines you can create/export a file containing your variable on your build agent. This file should be exported as build artifact and then downloaded on the release pipeline.

The below build pipeline implements the functionality I described. The exported file is named projectname.txt and will be located on artifacts folder on your build agent inside folder drop. For example C:\agent\1\a\drop

trigger:
- dev

pool:
  vmImage: windows-latest

parameters:
  - name: powerenvironment
    displayName: Where to deploy?
    type: string

steps:

- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      $variable = '${{parameters.powerenvironment}}'
      $variable | Out-File $(Build.ArtifactStagingDirectory)\projectname.txt
      Get-Content $(Build.ArtifactStagingDirectory)\projectname.txt

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'
    publishLocation: 'Container'

When you run the pipeline you will be asked for a parameter. I gave this entry my name which will be passed on release.

My release pipeline will download the build artifacts and get the value of the file. The release pipeline includes two steps.

The first one downloads the folder drop from build artifacts. The projectname.txt is located there.

Then the powershell will print the contents of the projectname.txt

You can check the result and verify you get the parameter input value from the powershell script.

Bonus content:

You can also write your input parameter as a variable on the build agent and reference this value on a later step. This should be again a powershell step on your release pipeline.

$myVariable = "ProjectName";
$myValue = Get-Content $(System.ArtifactsDirectory)/drop/projectname.txt;

Write-Host "##vso[task.setvariable variable=ProjectName]($myValue)";

Lastly create a dump archive step to reference the input parameter from the build pipeline.

In order to test, use in the archive path the ProjectName variable.

Run the pipeline and verify that input parameter is correct (I used gerasimos).

Youtube video:

Deploy between different environments with variable groups – Azure DevOps

Group variables is a functionality provided by Azure pipelines that let one handle a lot of variables as one entity. It also supports key vault integration but also secrets on comparison with the standard pipeline variables which should not be used as secrets according to Microsoft, as their value can be seen.

https://docs.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=yaml

In this article I will describe how you can use variable groups for different deployments based on the environment you work. For example the company may want to differentiate the variables for a product on the test and production version. This could be injected and handled on the pipeline accordingly with group variables and parameters.

This article refers to a product which has the same variables (version, password, environment) on test and prod, but their values are different.

In order to create a variable group you should go to Pipelines -> Library -> +Variable group.

The values which I provided on prod variable group are below:

Accordingly the same values exist for test.

The pipeline will trigger when a commit is merged on the main branch.

trigger:
- main

parameters:
  - name: environment
    displayName: Where to deploy?
    type: string
    default: test
    values:
    - prod
    - test


pool:
  vmImage: ubuntu-latest

variables:
 - group: ${{parameters.environment}}

steps:

- script: |
    echo $(ENV)
    echo $(VERSION)
  displayName: Step 1 - print version and environment

- script: echo $(PASSWORD)
  displayName: Step 2 - print secret

- script: pwd ENV ${{parameters.environment}}
  displayName: Step 3 - print parameter
  
  

By running the pipeline the type of environment will be asked

Depending on the selected input, the group variables of the specific category will be printed. If I run with test as input then I will get the test version and env variable.