Configuration as Code — moving away from Library Groups in Azure DevOps
When setting up (deployment) pipelines in Azure DevOps I have seen many people using Library Groups in various ways to store specific environment variables which are different across the environments. This is also a practice I have been using in the past but it has a number of disadvantages. One of the biggest disadvantage in my opinion is the fact that the configuration information is not part of the application repository.
With Configuration As Code (CaC) getting more attention these days (on top of Infrastructure As Code (IaC)), it’s important to show you an easy solution to get this done with YAML pipelines.
Configuration as code is the formal migration of config between environments, backed by a version control system.
Let’s explore the usage of variable templates in the yaml snippet below!
In the pipeline above I have two stages (DEV/PRD) where I want to use an existing set of variables which are different for both environments. Line 22 shows the usage of a variable template which points to a dedicated DEV yml file in the same repository while the PRD stage is using the PRD yml file. Both yml files contain the same variables with other values.
That’s all. Very simple and clean to keep track of the variables in different environments. Also very easy when you need another environment. Copy and modify the values.
The variable template mechanism can also be used for injecting some common variables which are used by different pipelines. In the same yaml snippet you can see that a repository resource was added in line 6 and line 13 points to the shared configuration file (pipeline-variables.yml) in that external repository.
Adding sensitive/secret information to a configuration file in a repository is of course not a good idea. For that purpose you can still use a Library Group (Line 23). The best approach here is to use a managed identity to get secrets directly into your application from Azure Key Vault.
