How to link work items for a yaml pipeline build when using release branches?

Question

In Azure DevOps, when using release (flow) branches along with YAML Build(+Release) pipelines. I'd like to be able to quickly identify a list of all the work items that are new/changed since the previous release.

The Automatically link work items to builds or releases feature seems to work well with Pull Requests (PR's) into the main branch. But if the releases are done by creating branches (e.g. releases\v1.0) from latest main branch commit, this "automatic linking" doesn't appear to be an option, as you have to explicitly select a branch (the only wildcard in the list is * - can't seem to enter/select releases\*.

I think my ideal would be if there's a way that, when creating a release branch (e.g. releases\v1.2) & subsequent yaml build pipeline is triggered, it's "Related Work Items" are limited to just the ones related to commits since the last release (e.g. since releases\v1.1).

Previously, we were doing PR's from main into a single release branch - which isn't really ideal as, for one, it creates a new merge commit (plus it feels like a hack)

Thanks in advance.

Answer 1

I've just had the same issue. I've managed to overcome it with a crude PowerShell script and Git command git log origin/<mainline_branch>.. to compare the release branch with what's on the main branch.

I then use regex to find work item numbers in format #1234

Then calling DevOps API I tag the work item (you'll need to generate a PAT).

The result is each matching work item is tagged with the name of the release branch.

Caveat - we use branch naming strategy: "releases/123" and branch from development to create release branches. Once a release hits production we merge release into mainline similar to: https://medium.com/@kushshiv/git-branching-strategy-4f01f48a8e2c

You'll need to amend the script if you use another branch format or branching strategy.

- task: PowerShell@2
inputs:
  targetType: 'inline'
  script: |
    $releaseBranch = "$(Build.SourceBranch)"
    $parts = $releaseBranch.Split("/")
    $releaseBranch = $parts[-2..-1] -join '/'
    
    Write-Output "git checkout $releaseBranch"
    git checkout $releaseBranch

    $workItems = New-Object System.Collections.Generic.List[System.Object]        
    
    Write-Output "git log origin/<mainline_branch>.."
    $output = git log origin/<mainline_branch>..
    Write-Output $output

    $output | 
        select-string -pattern '#(\d+)\b' -AllMatches | 
        ForEach-Object {$_.Matches} | 
        ForEach-Object {$workItems.Add($_.Value.substring(1))}
        
        $token = "PAT_TOKEN"
        $token = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($token)"))
        
        ForEach ($workItem in $workItems | Sort-Object | Get-Unique) {
            Write-Output "Updating work item $workItem  with tag $releaseBranch"
            
            $url3 = "https://dev.azure.com/<organisation>/<project>/_apis/wit/workitems/{0}?api-version=5.0" -f $workItem
                
              $body = "[
              {
                `"op`": `"add`",
                `"path`": `"/fields/System.Tags`",
                `"value`": `"$releaseBranch`"
              }
            ]"
    
            $response3 = Invoke-RestMethod -Uri $url3 -Headers @{Authorization = "Basic $token"} -Method Patch -Body $body -ContentType application/json-patch+json
            
            Write-Output "Finished updating work item $workItem  with tag $releaseBranch"
        }

Answer 2

I think my ideal would be if there's a way that, when creating a release branch (e.g. releases\v1.2) & subsequent yaml build pipeline is triggered, it's "Related Work Items" are limited to just the ones related to commits since the last release (e.g. since releases\v1.1).

If you create releases/v1.2 bases on releases/v1.1, and specify releases/v1.1 in the settings. sample like below:

Run pipeline based on releases/v1.2 for the first run, It will include the work items from releases/v1.1.

But if the releases/v1.2 is created from main branch, even you specify releases/v1.1 in the setting, the work items will not be included.

Please check the doc for the automatically linking work items to builds behavior.