In case you can’t or don’t want to use the Microsoft hosted agents (why?), setting up your own build servers is not too hard. Of course, I hope you don’t have to deal with a proxy server. In the unlikely scenario that you have a proxy server, I honestly hope you don’t have one with a self-signed certificate. Now, if you have to deal with all of this, I feel you. I put some notes together on how to get this setup done and have builds and releases running on your own agents flawlessly.

Setting up DevOps agent behind a proxy

Microsoft has documentation on how to setup an agent behind a proxy. This works well so I will not repeat what they say. Basically, you will config the agent using below command:

./config.cmd --proxyurl http://proxy.mycompany.com:8888 --proxyusername "myuser" --proxypassword "mypass"

This works well because the agent creates proxy configuration variables that the tasks can use. Most Microsoft maintained tasks (e.g. Nuget, npm, VS build/test, etc) will automatically use these variables.

Fixing the self-signed certificate error

Self Signed Certificate In Chain

The next issue you might find is that your proxy uses self-signed certificates (why? just somebody tell me why!). If this happens, you will get the self signed certificate in certificate chain error. This happens because your proxy is doing a man in the middle attach on you. Without going into the reasons this would be ok, your proxy is replacing the original cert served to you with a cert of its own. To get rid of this error, you should trust your proxy’s cert to let it do its thing.

First, export the cert root CA into a .cer or .pem file. Ensure you select Base 64 instead of DER encoding (I was lazy and reused an old gif from Install Root CA cert in Android emulator):

Export Certificate

Save the cert file to your build server and set a variable NODE_EXTRA_CA_CERTS to point to it.

setx NODE_EXTRA_CA_CERTS "c:\AzureDevOpsAgent\ProxyCACert.cer"

If you need to install several CA certificates, you can concatenate the content of the files together and change the file extension to .pem and changing your NODE_EXTRA_CA_CERTS export. Example of the .pem file:

base 64 encoded cert

base 64 encoded cert

base 64 encoded cert

Setting this environment variable fixed issues with nuget, npm, and git. There might be other task types that are not covered, but the basics should be.

Cheers, Lucas


If you are neck-deep into DevOps using Azure DevOps, chances are that you have your code on a git repository, have PBIs or Stories, are using Pull requests, Builds, and releases. If you are doing all of this good stuff, great! Carry on and I will show you how to get that shiny cherry on top of your cake. If you are not, you can probably benefit from this post too, but you will have to figure out how to do the same using the tools you love.

What I want to do is to automatically generate a markdown file with all work items associated with this release. I also want to accumulate work between environments so work items will only show once on a particular environment.


First, ensure you have a solid branching strategy. I’m quite fond of git flow myself, but anything that uses a PR will work fine.

I really recommend you use PR policies to ensure that everyone is doing the same. This is what I recommend for most projects:

  • Require a minimum number of reviewers:


  • Check for linked work items. This is key to ensure that release notes are generated


  • Check for comment resolution


  • Merge Type
    • I like squash because it allows the dev to push as many changes as they want but master/develop branch only get a single clean commit


  • Build



Make sure that your build has the Automatically link new work in this build flag turned on.


The release notes are generated at the release (duh!) and they will be different from each environment used. You will need an extension to generate the release notes. I use this one by Richad Fennel. Below are the configurations that work well for me:


The template is markdown with some special notation for variables. Review the extension documentation for more information. In my template, I put the work item name and a link back to the azure devops work item. Uncheck the Generate for only this Release flag to ensure that work items associated with builds without releases or not approved releases are accumulated. Here is a copiable version of the template.

The final piece of the puzzle involves publishing your release notes. I recommend having an API endpoint in your app where you can post the release notes. Again, I use powershell to do that:


And here is the powershell code above:


Finally, you can render the uploaded markdown into a html page. Here is what your release notes could look like (style was shamelessly stolen from Visual Studio Code release notes):



That was a lot of little things to consider. However, once you have everything setup, you will never have to write release notes again.

Cheers, Lucas