top of page
Writer's picturemicah jardine

$(Release.EnvironmentName)


Azure DevOps has a wide range of pre-defined variables available for use in Azure Pipelines (see link). By far my favorite is the $(Release.EnvironmentName) variable. This variable is set as the Name of Environment in your releases.


This is easiest illustrated by an example, the highlighted values below will become the $(Release.EnvironmentName).





So what? Well, actually we can use this variable to simplify our release process. I use variable groups (see links) and one of the variables I declare is Environment = $(Release.EnvironmentName). Now I can use $(environment) in my release steps.


One place I use this is when I use an 'Azure Resource Group Deployment' task when deploying infrastructure.


Firstly I use it to append the resource group name with the Environment, this allows me to group my environments easily into there own resource groups.



Secondly, I use it on my Parameter files. My parameter files are specified like so.


  • Resource1.dev.json

  • Resource1.acc.json

  • Resource1.prd.json


When Azure DevOps evaluates the template file location with $(environment) substituted in the path, the variable is used, and the correct parameter file for the environment is selected, allowing specifying appropriate files across environments without the need to update the parameter file location.


Another place I use this is also with infrastructure deployments, however, this time I use Tokenisation (see links) to replace #{environment}# parameter in my parameter files with the $(environment) value.


Now you have of course noted that I do not need to assign Environment = $(release.EnvironmentName), instead just use $(release.EnvironmentName) directly, however, I find variables easier to work with if they have a clearly defined context.


Finally, by using as many variables as possible your pipelines, you can more quickly clone and entire Environment. I will post on this at some point in the future, however one major benefit is that, if your pipeline is well constructed and you add new task(s) to Development, you can just delete ACC and PRD and clone from Dev, saving you the effort of adding additional steps to multiple environments, and introducing errors.


Micah Jardine.


Links

4,727 views0 comments

Recent Posts

See All

Simple RBAC Model for Azure & DevOps

Azure RBAC models in Enterprises do not need not be complex. Microsoft recommends having fewer subscriptions and creating granular permissio

©2020 by Micah Jardine - Azure Cloud Blog. Proudly created with Wix.com

bottom of page