I have a question about best practice and Azure Pipeline. I have a web site (ASP.NET API old version) I need to publish on 2 environments

  1. staging
  2. production

I think this schema is classic. At the beginning I decided to create one build in release mode and deploy it on staging first then manually on production after validation. I created this

enter image description here

Then I realized I cannot manage the web.config. This system deploy 2 time the same build with same web.config on my 2 environments. I cannot tell him to use one or another web.config.

So I decided to create 2 builds and manage 2 pipelines separately and trigger the second after validation of the first one. Yes but no. I don't like the idea to build twice the same code and there is problem. what if my first pipeline is ok and then my second is in error because I always request last change on my branch and I can always have a new change during the deployment process. So no way I must do one build with a 2 phase deployment.

Now, juts tell me. Am I right?

PS: someone that has more rights than me should create the tag azure-pipeline

2 Answers 2


This can be achieved using variable groups, config file transforms, and pipeline tasks. You can create a single build artifact and substitute settings for each environment when the application is deployed.

Variable Groups

Create two variable groups, one for Staging and one for Production, with appropriate values for your variables. You only need to include variables which are different between the stages.

Staging variable group

ApiUrl = staging.xyz.com

Production variable group

ApiUrl = production.xyz.com

Config Transform

Create a config file (XDT) transform in your source code that will replace element values with variable tokens.

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <add key="ApiUrl" value="#{ApiUrl}#" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>


Release pipeline

In your release pipeline, add the XDT Transform task to apply your transform to your config file and the Replace Tokens task to substitute appropriate variables in place of the tokens.

The token format is up to you, so long as your XDT file and transform task are configured the same.

Be sure link the variable groups to the appropriate stages in your release pipeline.


In a cloud native design, application configuration is no longer performed at build time. Instead, it is provided by the destination environment or retrieved by your application at runtime. One such service is Azure App Configuration.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.