I got a question from a user of my EF Core Migrations deploy utilities last week. He was running into problems where "dotnet ef database update" was picking up the wrong version of his appsettings.json config file. At first, it looked like it was a problem with my utility's code but after some more digging, it turned out that his build server had the wrong version of the ASPNETCORE_ENVIRONMENT environment variable and it was messing with his Azure DevOps build.

Setting an environment variable value from an Azure DevOps build/release pipeline is easy to do...but surprisingly hard to figure out. It's hard to figure out because it's just too darned easy.

Basically, all variables in Azure DevOps Pipelines are environment variables.

There are 3 ways to get an environment variable value on your build server:

1. Set the value on the build machine
2. Set the value in the YAML build script
3. Set the value in Azure DevOps for the build pipeline definition

Option 1: Set the value on the build machine

The first way is easy enough if you own the machine that hosts the build and release agent. But if you're running using the Azure DevOps hosted agents, you're pretty much out of luck.

Option 2: Set the value in the YAML build script

The Azure DevOps build and release pipeline YAML has a section called 'variables' that lets you set -- uhhh -- variable values. What's not obvious is that this is setting up environment variables for your pipeline execution. Here's a sample pipeline.

trigger:
- main

pool:
  # vmImage: 'windows-latest'
  vmImage: 'ubuntu-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'
  ASPNETCORE_ENVIRONMENT: 'Production'

steps:
- task: NuGetToolInstaller@1

- script: set
  displayName: show all env vars

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

Option 3: Set a Variable in the Azure DevOps Pipeline definition

You can also define a variable as part of Azure DevOps's pipeline definition. If you go to the pipeline definition in a browser, you'll see a button labeled 'Variables'.

Click the Variables button and you'll see the Variables Editor. In the image below, you can see that I've already defined a value named ASPNETCORE_ENVIRONMENT. To add a new value, click the plus (+) button.

The name you give the variable becomes an environment variable that's available during the build pipeline script execution. If you check the 'let users override this value when running this pipeline' checkbox, when you manually execute the pipeline, you'll be given the opportunity to override the value with something for just that instance of the pipeline execution.

Using these Environment Variables

The nice thing about the build and release pipelines being based on environment variables is that you can access them from pretty much anything in your build pipeline. Want to reference it as a variable in YAML? Done. Want to reference a value in a bash script? No problem. Powershell scripts? Yup. Some custom exe call? Works there, too.

Lets say that the environment variable is ASPNETCORE_ENVIRONMENT. Here are some ways to reference it.

• From YAML: $(ASPNETCORE_ENVIRONMENT)
• From a batch script (*.bat): %ASPNETCORE_ENVIRONMENT%
• From a bash script (*.sh): $(ASPNETCORE_ENVIRONMENT)
• From a powershell script (*.ps1): ${env:ASPNETCORE_ENVIRONMENT}

Summary

So in short, it's easy to work with environment variables in your Azure DevOps Pipelines because they're everywhere.

Anyway. I hope this helps.

-Ben

-- Need help porting your builds and release pipelines to use the new YAML-based technology? Want help getting your DevOps build and release pipelines written? Getting frustrated trying to figure out how to get your database code incorporated into your Azure DevOps continuous build and continuous release (CICD) pipelines? We can help. Drop us a line at info@benday.com.