2 min read

As part of our process we create PBIs (work items) describing what needs to be done, and then during commit, our commit messages describe what we actually changed. During a release we need to keep track of this information and inform stakeholders as to what changed. This used to be fairly time-consuming step in which we had to gather information from the PBIs and commit messages and write up what we’re releasing. We managed to automate it to the point where all the information is linked cleanly into one page per release, with each work item linked directly, which allows someone to quickly get additional context.


Install the Generate Release Notes Build Task from the Azure DevOps Marketplace



In the release, add an Agent phase (if you don’t already have one)

Add the Generate Release Notes Task and a PowerShell Task


Customize the release notes properties and template as needed

Since the Wiki already links work items by IDs, I found it useful to only include the IDs in the template.

**Build Number**  : $($build.buildnumber)    
**Build started** : $("{0:dd/MM/yy HH:mm:ss}" -f [datetime]$build.startTime)     
**Source Branch** : $($build.sourceBranch)  

###Associated work items  
* #$($widetail.id)

###Associated change sets/commits  
* **ID $($csdetail.changesetid)$($csdetail.commitid)** 


Now that the release notes have been written to a file, you can do whatever else you want with it, such as post-processing, emailing somewhere, etc. Next we’ll post it to our Wiki using PowerShell

$content = [IO.File]::ReadAllText("$(System.DefaultWorkingDirectory)\releasenotes.md")
$data = @{content=$content;} | ConvertTo-Json;
$params = @{uri = '$(WikiPath)';
  Method = 'PUT';
  Headers = @{Authorization = "Bearer $(System.AccessToken)" };
  ContentType = "application/json";
  Body = $data;
Invoke-WebRequest @params

Next, we need to add the Variable we referenced:

Was this post helpful?