如何在发布后更新work item的State？DevOps流水线内置实现方案问询

Absolutely! You don’t need third-party extensions to pull this off—Azure DevOps has all the built-in tools you need to update work item states automatically after a specific release finishes. Here’s a step-by-step breakdown to set this up:

1. Use a PowerShell Task with Azure DevOps REST API #

The core idea is to leverage a PowerShell task in your release pipeline to call Azure DevOps’ native REST APIs. This lets you:

• Fetch all work items linked to the current release
• Update each work item’s state to your desired value

Step 1: Add the PowerShell Task to Your Release Pipeline #

Navigate to your release pipeline, go to the environment you want to trigger the work item update (e.g., QA), and add a PowerShell task (choose "Inline" script for simplicity).

Step 2: Paste the Inline Script #

Here’s a ready-to-use script that fetches linked work items and updates their state. Adjust the $newState value to match your work item’s state field (e.g., "Ready for Production", "Done"):

# Get system variables for the current release
$releaseId = $(Release.ReleaseId)
$orgUrl = "$(System.TeamFoundationCollectionUri)"
$projectName = "$(System.TeamProject)"
$accessToken = "$(System.AccessToken)"

# Set up authentication headers
$headers = @{
    "Authorization" = "Bearer $accessToken"
    "Content-Type" = "application/json-patch+json"
}

# Fetch all work items linked to this release
$workItemsEndpoint = "$orgUrl$projectName/_apis/release/releases/$releaseId/workitems?api-version=7.1-preview.2"
$workItems = Invoke-RestMethod -Uri $workItemsEndpoint -Headers $headers -Method Get
$workItemIds = $workItems.value | Select-Object -ExpandProperty id

# Define the target state for your work items
$newState = "Done" # Update this to your desired state

# Loop through each work item and update its state
foreach ($id in $workItemIds) {
    $updateEndpoint = "$orgUrl$projectName/_apis/wit/workitems/$id?api-version=7.1-preview.3"
    
    # Build the JSON patch body to update the state field
    $updateBody = @(
        @{
            op = "replace"
            path = "/fields/System.State"
            value = $newState
        }
    ) | ConvertTo-Json

    try {
        Invoke-RestMethod -Uri $updateEndpoint -Headers $headers -Method Patch -Body $updateBody
        Write-Host "✅ Successfully updated work item #$id to state: '$newState'"
    } catch {
        Write-Warning "❌ Failed to update work item #$id : $_"
    }
}

2. Configure Permissions #

Make sure the pipeline has permission to edit work items:

• Go to your project’s Settings > Permissions
• Find the Release Service ({Your Organization Name}) identity
• Grant it the Edit work items in this node permission (set to "Allow")

3. Control When the Task Runs #

You can restrict this task to only run for specific scenarios (e.g., only when the QA release succeeds):

• In the PowerShell task’s Control Options, set "Run this task" to Custom condition
• Use an expression like this to target successful releases in the QA environment:

  and(succeeded(), eq(variables['Release.EnvironmentName'], 'QA'))
  

Why This Works #

This approach uses 100% built-in Azure DevOps components:

• The $(System.AccessToken) variable is a native system token that authenticates the pipeline against the API
• REST APIs are baked into Azure DevOps, so you don’t rely on external tools
• You get full control over which environments trigger the update and what state work items are set to

内容的提问来源于stack exchange，提问作者Greg