Move variable groups to the code repository and reference it from YAML pipelines

Question

We are looking for a solution how to move the non-secret variables from the Variable groups into the code repositories. We would like to have the possibilities:

• to track the changes of all the settings in the code repository
• version value of the variable together with the source code, pipeline code version

---

Problem: We have over 100 variable groups defined which are referenced by over 100 YAML pipelines. They are injected at different pipeline/stage/job levels depends on the environment/component/stage they are operating on.

Example problems:

• some variable can change their name, some variable can be removed and in the pipeline which targets the PROD environment it is still referenced, and on the pipeline which deploys on DEV it is not there
• particular pipeline run used the version of the variables at some date in the past, it is good to know with what set of settings it had been deployed in the past

---

Possible solutions:

1. It should be possible to use the simple yaml template variables file to mimic the variable groups and just include the yaml templates with variable groups into the main yamls using this approach: Variable reuse.

# File: variable-group-component.yml
variables:
  myComponentVariable: 'SomeVal'

# File: variable-group-environment.yml
variables:
  myEnvVariable: 'DEV'

# File: azure-pipelines.yml

variables:
- template: variable-group-component.yml    # Template reference
- template: variable-group-environment.yml  # Template reference

#some stages/jobs/steps:

In theory, it should be easy to transform the variable groups to the YAML template files and reference them from YAML instead of using a reference to the variable group.

# Current reference we use
variables:
- group: "Current classical variable group"

However, even without implementing this approach, we hit the following limit in our pipelines: "No more than 100 separate YAML files may be included (directly or indirectly)"

YAML templates limits

Taking into consideration the requirement that we would like to have the variable groups logically granulated and separated and not stored in one big yml file (in order to not hit another limit with the number of variables in a job agent) we cannot go this way.

2. The second approach would be to add a simple script (PowerShell?) which will consume some key/value metadata file with variables (variableName/variableValue) records and just execute job step with a command to

##vso[task.setvariable variable=one]secondValue.

But it could be only done at the initial job level, as a first step, and it looks like the re-engineering variable groups mechanism provided natively in Azure DevOps.

We are not sure that this approach will work everywhere in the YAML pipelines when the variables are currently used. Somewhere they are passed as arguments to the tasks. Etc.

3. Move all the variables into the key vault secrets? We abandoned this option at the beginning as the key vault is a place to store sensitive data and not the settings which could be visible by anyone. Moreover storing it in secrets cause the pipeline logs to put * instead of real configuration setting and obfuscate the pipeline run log information.

---

Questions:

Q1. Do you have any other propositions/alternatives on how the variables versioning/changes tracking could be achieved in Azure DevOps YAML pipelines?

Q2. Do you see any problems in the 2. possible solution, or have better ideas?

Answer 1

You can consider this as alternative:

1. Store your non-secrets variable in json file in a repository
2. Create a pipeline to push variables to App Configuration (instead a Vault)
3. Then if you need this settings in your app make sure that you reference to app configuration from the app instead running replacement task in Azure Devops. Or if you need this settings directly by pipelines Pull them from App Configuration

Drawbacks:

• the same as one mentioned by you in Powershell case. You need to do it job level

What you get:

• track in repo
• track in App Configuration and all benefits of App Configuration