First, it's important that I did not include the words definition, artifact, or environment when I mentioned build in the title.

As shown in the illustration below, my dream is to have one build definition, one build environment, and one build artifact that is deployed to multiple release environments by shifting the configuration right. See shift LEFT and RIGHT to take yourself off the humbling 2AM calls for more details.

One BUILD to rule them all
  1. Using the build validation policy, trigger a build to validate the changes before the pull request can be completed.
  2. This helps reduce build breaks, validate tests and security scans early, raise the overall quality bar before we commit the changes, and enables reviewers to review and approve the pull request effectively.
  3. Complete the pull request. The associated merge triggers another continuous integration build, using the same, the one and only, build definition.
  4. In Visual Studio, for example, there is the option to define and build multiple environments. Some teams create artifacts for up to five environments (debug, release, system test, production ...), which takes time and generates different artifacts. Consider creating only one build artifact, using the release environment.
  5. Generate full debug files and upload them to the symbol server.
  6. Deploy the same build artifact to different environments, with different configuration.
  7. When you're on the 2AM call, you can remote debug any of the environments, linking to the symbol server and retrieving the relevant debug files.

What is the value of one build?

  • Faster than multiple builds
  • Easier to trace across different release environments
  • Easier to debug across different release environments

How do I create one build environment using Visual Studio and Azure DevOps Pipelines?

Generate full debug files for your release build environment

Generate Full debugging information

Upload the debug files to the symbol server during the build

Configure your build pipeline to target only the release environment.

  1. Add the Publish symbols task.
  2. Select version 2.*.
  3. Check Publish symbols checkbox and select the Symbol server in this organization server type.

Configure Visual Studio to debug using symbol servers and which symbol server locations to use. See Remote Debugging for more details.

  • Select Tools, Options.
  • Go to Debugging section of tools and disable Enable just my code. This instructs Visual Studio to debug external code.
  • Under Debugging, Symbols, click on the (1) new VSTS Symbol Server Location.
  • Select the VSTS account in which you set-up the symbol server. And after that close the Options screen.
You need a Basic Access Level and a Package Management license, or a Visual Studio Enterprise license to access the Azure DevOps symbol server.
Thoughts? Anyone following a similar strategy?