Azure Boards Development links explained
Development links are the structured links Azure Boards uses to connect a work item to code activity in Azure Repos. They are what let a work item show related branches, commits, and pull requests instead of relying on comments or pasted URLs.
For deployment workflows, Development links are important because they answer a practical question: which branch or PR represents the work in this ticket?
What appears in the Development section
The Development section of an Azure Boards work item can show code artifacts such as:
- Branches created from or linked to the work item.
- Pull requests linked to the work item.
- Commits that reference the work item.
- Builds or other development activity connected through Azure DevOps.
BranchDeploy uses branch and pull request links from this section. Commit links are useful for traceability, but a commit alone does not tell BranchDeploy which branch should be deployed.
How Development links are created
Create a branch from the work item
This is the cleanest path. Open the work item, use the Development section to create a branch, and Azure DevOps links the new branch to the ticket automatically.
Link a pull request to the work item
When opening a PR, add the work item in the PR's work item area, or link the PR from the work item. Once linked, the PR appears in the work item's Development section.
Use the AB# commit syntax
Azure DevOps can link commits to work items when the commit message includes the work item ID with the AB# prefix.
git commit -m "Fix checkout validation AB#1234"This is useful, but for BranchDeploy you should still make sure the work item has a branch or PR link, not only commit links.
Development links vs related work links
A Related Work link connects one work item to another work item. A Development link connects a work item to code. They serve different purposes.
| Link type | Connects to | Used by BranchDeploy? |
|---|---|---|
| Development branch link | Azure Repos branch | Yes. |
| Development PR link | Azure Repos pull request | Yes, resolves the PR source branch. |
| Development commit link | Git commit | No, not enough to choose a deploy branch. |
| Related Work | Another Azure Boards work item | No. |
| Plain URL in a comment | Text or hyperlink | No. |
Why Development links matter for deployments
When a tester asks to deploy ticket 1234, the deployment source should be explicit. A Development link lets the work item point to the exact branch or PR that contains the change. BranchDeploy can then resolve that linked source and queue Azure Pipelines without a person copying branch names between tools.
This keeps the handoff short and auditable:
- The ticket shows the work being tested.
- The linked branch or PR shows the code under test.
- The pipeline run shows the deployment result.
Examples: what each Development section deploys
The same ticket can look very different depending on how the team linked its code. These examples use work item #1482 Add customer invoice export.
| Development section shows | What BranchDeploy deploys |
|---|---|
Branch feature/1482-invoice-export | That branch, shown in the confirmation step. |
PR #311 from feature/1482-invoice-export into main | The PR source branch, feature/1482-invoice-export. Never main. |
Branch feature/1482-invoice-export and PR #311 from that branch | The PR source branch. A single linked PR takes priority over branch links. |
Branches feature/1482-invoice-export and feature/1482-invoice-export-v2 | A picker listing both, so the user chooses before anything runs. |
Three commits referencing AB#1482, no branch or PR | Nothing. BranchDeploy reports that no linked branch was found. |
| A branch name pasted into a comment | Nothing. Comments are not Development links. |
The pattern is simple: the clearer the Development section, the less anyone has to decide at deploy time. For the full deploy flow, see deploy an Azure Repos branch from an Azure Boards work item.
Good team conventions
- Create branches from work items when possible.
- Keep the active PR linked to the work item.
- Use
AB#references in commits for extra traceability. - Remove stale branch or PR links if they confuse deployment choices.
- Do not rely on branch names pasted into comments as deployment instructions.
Troubleshooting
The work item shows commits but no branch
Add or create a branch link. BranchDeploy needs a branch or PR source, not just commit history.
The linked PR is completed
Completed PRs can still be useful for traceability, but the source branch may have been deleted. If the branch no longer exists, deploy the target branch through your normal release flow or link a new deployment branch.
There are too many linked branches
BranchDeploy can show a picker when there are multiple candidates. For less ambiguity, remove stale branches and abandoned PRs from the Development section.
