Welcome back to another episode of Azure Pipelines How To, the series. Today, we’ll learn how to fetch variables from Variable Groups in Azure DevOps. Fasten your seatbelts and let’s get started 💺.

What are Variable Groups

Variable Groups are no black magic. It’s just a storage space for all your values (both public and secret) that you might want to use in your pipeline. They can be shared among different pipelines. Secrets are being protected by customisable guards, like approvals, checks, and pipeline permissions. Meanwhile, the non-secret ones are not guarded by any of the mentioned. That’s all theory you need, so let’s move to implementation. Of course, if you want to read more, you can. do that in MSDN.

Creating new group

In the same way, we started with Secure files, first navigate to Pipelines > Library, then variable groups (if not preselected for whatever reason). Next, click ” + Variable group ” (pic 1.). This will redirect you to the group creation page (pic 2.)

Second, add name for your group, description, and variables. To make the variable “secret”, click a little locker icon at the end of the Value input. Once you save a change, Pipeline permissions and Approvals and checks buttons should be enabled. Let’s look into them.

Pipeline permissions

Again, it’s done precisely the same way as for Secure files. To make a Variable Group available for a pipeline, select all pipelines that should be using variables in this group. In my case, it’s just one – WebFlix. It might be a simple step, but don’t forget about it, it’s easy to forget and there is nothing worse than getting an error when you are 110% sure everything should FINALLY work as expected.

Approvals and checks

The next step will be deciding on checks and approvals. Take your time and decide on what you need. In my example, I’ll add only Approvals (see pic 5). You can read about all possibilities, as always, on MSDN.

How will that work? Next time, I’d like to run a pipeline a job/stage that calls for those variables will be stopped while waiting for approval for a defined amount of time.

Managing Variable Groups with Azure CLI

If you don`t want to get stuck in “ClickOps” you can always use Azure CLI. Here are several commands, that can come in handy. First – create group. It comes with two required parameters – group id and name.

az pipelines variable-group variable create --group-id --name

But Gosia we weren’t able to add groupId in ADO, what now? Worry not, I wondered about the same thing, so went on and checked some places for you. Turns out it just assigns it a numeric value starting from 1. https://dev.azure.com/.../.../_library?...&variableGroupId=1&...That can come in when someone created a group manually, and you want to modify it via CLI.

After creating a group we can go on and modify it. We can f.ex.

Delete group:

az pipelines variable-group variable delete --group-id --name

List all variables in a group

az pipelines variable-group variable list --group-id

Update variable’s value

az pipelines variable-group variable update --group-id --name

If you want to read more about oprional parameters, check this MSDN page.

Reading variables

Now, let’s move to the code.

First of all we have to let your pipeline know where to read those values from, so at the very top of your code, just add:

variables:
  - group: devopsifyme-webflix-e2e-dev
  - name: someOtherVariable
    value: 'test test test'

This way we’ll let the specific pipeline know which group of variables it can use. Also, ensure that groups go before single variables defined directly in the pipeline. The next step is reading, and it’s really simple. I wanted to pass it as a param to a template, but you can echo it, do whatever you wish!

parameters:
          userSecret: $(E2E_CLIENT_SECRET)

Can we add some dynamic here?

In a way, you can. Dependently on what you want to achieve, but let’s cover some examples.

1. You want to have several groups for a different environment.
This is doable. Just include the name of the environment in the group’s name (like I did in an example above). You can do something like this:

parameters:
- name: env
  type: string
  values:
    - prod
    - test
    - dev
  default: dev

variables:
- group: devopsifyme-webflix-e2e-${{ parameters.env }}

With that the selected group’s name will change dependently on which environment you want to run your code.

2. You want to have a different group based on a branch from which you are running your pipeline.
You can add some conditions based on which we’ll connect to a specific group

 variables:
  - ${{ if eq(variables['build.SourceBranchName'], 'main') }}:
    - group: devopsifyme-webflix-e2e-prod
  - ${{ if eq(variables['build.SourceBranchName'], 'develop') }}:
    - group: devopsifyme-webflix-e2e-test
  - ${{ if and(ne(variables['build.SourceBranchName'], 'develop'), ne(variables['build.SourceBranchName'], 'main')) }}:
    - group: devopsifyme-webflix-e2e-dev

Variable Groups vs. Secure Files

Writing this section I’ll try to be as unbiased as possible, I promise.

It seems natural to ask what is better, Variable Groups or Secure Files? They both come with pros and cons. Let’s go through them together, starting with Variable Groups.

VG Pros:
Easy to edit – unlike in the files, you can change the value of a variable whenever. No changes on the group level are required.
Connection to Key Vault – this goes without a say. If you are already using a KeyVault you don’t have to store the same value in 2 places (and later remember to edit it in both of the places).
Description field – if you are sharing space between different teams and projects you don’t necessarily have to give your group a super fancy name (although I highly reccommend the name to be as descriptive as possible). You can always add a description with more details for other users.

VG Cons:
Lots of manual work to create those – if you have a lot of variables for different environments, you’ll have to initiate them manually one by one. Plus, on top of that, some of those you might need locally as well.

SF Pros:
Less manual work if a large number of values – You define them once, have the same file locally for development if needed) and you are good to go.

SF Cons:
Changes are painful – there is no way to “update” a file. You must delete it and re-upload it. Thus need to store them locally as well.
Description field is not supported – name is all you’ve got!

If you want to find out by yourself which one you like more, check out our pervious post about Secure Files!