(How) are variable groups versioned in Azure DevOps?

Viewed 932

I have been trying to find some information on how variable groups are versioned in Azure DevOps (or if they even are versioned at all).

My "problem" is that what if we have the following scenario:

We have a release pipeline that has a linked variable group with a set of variables that the release is dependent upon.

During our first run of the release pipeline (release 1) we deploy our applications and we use the variable groups variables to configure the application.

After our first release, everything works fine, a few weeks pass and we decide to make a few changes to our variable groups. for instance, we might change the name of a variable, or change the value. Now we are ready for our next release (release 2).

We run our release, but only to find out that something is broken, the application does not work anymore.. so we quickly want to roll back to a previous stage (to release 1), so we simply just "re-release/re-run" the release we did for release 1... however.. since we have changed our variable groups variables, would this cause us to do a release with the newly updated variables, or does Azure DevOps somehow store/"snapshot" the stage of the variable groups from the first time the release ran?

2 Answers

The variables groups not versions (yet...) in Azure DevOps. so, if you update a variables group you can know what was before.

But, as a workaround, you can create a Gir repository that saves the data and update him with an automatic pipeline:

trigger: none

schedules:

- cron: "*/15 14-21 * * Mon-Fri"
  displayName: Every 15 min M-F 9am-4:45pm (UTC-05:00)
  branches:
    include:
    - master
  always: true

- cron: "0 22 * * Mon-Fri"
  displayName: M-F 5pm (UTC-05:00)
  branches:
    include:
    - master
  always: true

pool:
  vmImage: 'ubuntu-latest'

steps:

- checkout: self
  persistCredentials: true
  clean: true

# Updating the python version available on the linux agent
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
    architecture: 'x64'

# Updating pip to latest
- script: python -m pip install --upgrade pip
  displayName: 'Upgrade pip'

# Updating to latest Azure CLI version.
- script: pip install --pre azure-cli --extra-index-url https://azurecliprod.blob.core.windows.net/edge
  displayName: 'Upgrade Azure CLI'

- script: az --version
  displayName: 'Show Azure CLI version'

- script: az extension add -n azure-devops
  displayName: 'Install Azure DevOps Extension'

- script: echo ${AZURE_DEVOPS_CLI_PAT} | az devops login
  env:
    AZURE_DEVOPS_CLI_PAT: $(System.AccessToken)
  displayName: 'Login Azure DevOps Extension'

- script: az devops configure --defaults organization=$(System.TeamFoundationCollectionUri) project="$(System.TeamProject)"
  displayName: 'Set default Azure DevOps organization and project'

- pwsh: |
    # Checkout the source branch
    git checkout $(Build.SourceBranchName)

    # Get all variable groups
    $groups = ConvertFrom-Json "$(az pipelines variable-group list)"
    $groups | foreach {
      $groupName = $_.name

      # Prepend VariableGroups folder name
      $filePath = Join-Path "VariableGroups" "$groupName.json"

      # Save the variable group to a file
      ConvertTo-Json $_ | New-Item $filePath -Force

      # Use the last modified user's name and email
      git config user.email $_.modifiedBy.uniqueName
      git config user.name $_.modifiedBy.displayName

      # Stage the file
      git add $filePath

      # Commit
      git commit -m "Variable group $groupName updates"
    }

    # Push all changes
    git push origin
  displayName: 'Save variable groups'

A detailed explanation you fine here.

Azure DevOps does not version variable groups in the sence that if you change a variable that would create a new revision of the group itself. However, to answer my own question.. it does persist the variables values and name between builds and releases. So for instance if a variable is changed between release 1 and release 2 and we re-run the deployment of release 1, the variables would be exactly the same as for the first time you ran release 1.. no matter which changes has been made to a variable groupe or any other release/stage/build variables for that matter.

Related