How to deploy an Azure Pipeline from an Azure Boards work item

Azure Boards tracks work items. Azure Repos tracks branches. Azure Pipelines runs deployments. The problem is the handoff between them. When a developer finishes work on a feature branch, someone still has to find that branch, open the right pipeline, select the correct parameters, and queue a run — all outside the work item where the work was planned.

This guide explains how Azure DevOps connects work items to pipeline runs, how the manual handoff works, and how to reduce friction with BranchDeploy.

What Azure Boards already knows

Azure Boards work items can display Development links — direct connections to Azure Repos branches and pull requests. When a developer creates a branch from a work item, or links an existing branch through the Development section of the work item, that link appears on the work item details page.

This means the work item already knows which branch contains the work you want to test or deploy. The challenge is getting that information into an Azure Pipeline run without manual copy-paste.

Azure Boards does not natively offer a "deploy" button that uses the linked branch. That gap is what BranchDeploy fills.

The manual method: how most teams do it today

Without a dedicated extension, deploying the branch linked to a work item requires these steps:

1. Open the work item in Azure Boards.
2. Find the Development section and note the linked branch or PR name.
3. Copy the branch name to your clipboard.
4. Open Azure Pipelines in a new browser tab or window.
5. Navigate to the correct pipeline for your target environment.
6. Click Run pipeline and select the branch you copied.
7. Add environment and work item parameters if your pipeline expects them.
8. Queue the run and copy the run URL back to the work item or Slack thread.

This is eight steps, two browser tabs, and manual clipboard use for every single deployment. When a QA team is testing multiple tickets, or when a developer needs to push a branch to staging several times in a day, this sequence adds up quickly.

Problems with the manual method

Beyond the time cost, the manual approach introduces specific failure points that matter for teams trying to maintain reliable QA and staging environments.

Wrong branch selected. When branch names are typed or pasted manually, it is common to select a previous branch by accident, especially when autocomplete shows multiple similar names. The pipeline runs, but the wrong code is deployed.

Wrong pipeline. Teams with multiple pipelines (staging, UAT, preview) can queue a run against the wrong environment. There is no confirmation step that shows the environment and work item together before the run starts.

Permission gaps. QA engineers or delivery managers who need to trigger a deployment may not know which pipeline to open, or may not have the Azure Pipelines UI bookmarked. Relying on developers to queue runs on behalf of other roles creates a bottleneck.

Missing audit trail. There is no automatic record of which pipeline run corresponds to which work item deployment, which matters when you need to trace a regression back to a specific deploy event.

The BranchDeploy method

BranchDeploy is an Azure DevOps Marketplace extension that adds a deploy action to the Azure Boards work item toolbar. It resolves the linked branch automatically and queues your configured Azure Pipeline from inside the work item.

The workflow becomes:

1. Open the work item in Azure Boards.
2. Click the BranchDeploy action in the work item toolbar.
3. BranchDeploy detects the linked Azure Repos branch or PR and resolves the source branch.
4. A confirmation step shows the branch, environment, and work item details.
5. Click Deploy.
6. The configured Azure Pipeline is queued. The run ID and a direct link appear immediately.

No clipboard. No tab switching. No branch-name guesswork.

Requirements for BranchDeploy

To use BranchDeploy, you need:

• An Azure DevOps organisation on dev.azure.com (not Azure DevOps Server).
• Azure Boards enabled with work items that link to Azure Repos branches or pull requests.
• An Azure Pipeline you want to queue for deployments.
• Permission to queue the pipeline as your Azure DevOps user.
• A project admin to configure BranchDeploy in Project Settings.

How BranchDeploy resolves the linked branch

Azure Boards work items track Development links — a separate section from comments, related work, and attachments. BranchDeploy reads these Development links when you click the deploy action.

If the work item has a linked Azure Repos branch, BranchDeploy uses that branch directly. If the work item has a linked pull request, BranchDeploy reads the PR source branch — the branch being merged, not the target branch.

On the free tier, if there is a single clear linked branch or PR, BranchDeploy uses it and shows it in the confirmation step. If there are multiple candidates, BranchDeploy Pro shows a branch picker so the user can select the correct branch before deploying.

What happens at the confirmation step

Before queuing the pipeline, BranchDeploy shows a confirmation dialog with:

• The resolved branch name.
• The repository the branch belongs to.
• The target environment (configured in Project Settings).
• The work item title and ID.

The user reviews these details and clicks Deploy to confirm. There is no way to skip the confirmation. This prevents accidents and gives every person who deploys a chance to verify the context before a pipeline run is queued.

When this workflow is useful

The work item deploy workflow is most valuable when:

• QA engineers need to deploy specific branches to a UAT environment without relying on developers.
• Delivery managers need visibility into which branches are being deployed and from which tickets.
• Developers want to push a feature branch to staging without leaving the context of the work item they are working on.
• Teams want to reduce the number of tools open during a deployment and keep deployment decisions traceable to specific tickets.

Security and permissions

BranchDeploy queues your existing Azure Pipeline as the current Azure DevOps user and respects existing Azure DevOps permissions. If a user cannot queue the pipeline manually, BranchDeploy cannot queue it for them. No credentials are stored by the free extension workflow, and no BranchDeploy account is required.

Branch allowlists can be configured in Project Settings to restrict which branches are permitted to deploy to a given environment. BranchDeploy will block a deployment before queuing the pipeline if the resolved branch does not match the allowlist.

For details, see the BranchDeploy security and permissions page.

How to set it up

1. Install BranchDeploy from the Visual Studio Marketplace.
2. Open your Azure DevOps project.
3. Go to Project Settings → BranchDeploy.
4. Enter your pipeline ID, environment name, and optional branch allowlist patterns.
5. Save settings.
6. Open a linked work item and click the BranchDeploy action.

For the full setup walkthrough, see the BranchDeploy setup documentation.