An Azure DevOps extension for QA deployments

QA testers in Azure DevOps teams spend a surprising amount of time not testing: messaging a developer to deploy a branch, waiting for the run, then finding out the wrong branch went out. The ticket they are about to test already says which branch holds the change. They just cannot use it.

BranchDeploy is an Azure DevOps Marketplace extension that adds a deploy button to Azure Boards work items, so a tester can deploy the ticket's branch to the QA environment themselves, from the ticket.

A tester's day, before and after

Why testers can trust the branch

• It comes from the ticket. BranchDeploy reads the branch or pull request linked in the work item's Development section. Nobody types it.
• PRs resolve to the right side. A linked pull request deploys its source branch, the change under review, never the target branch.
• Ambiguity is shown, not guessed. If several branches or PRs are linked, a picker lists them with their repository.
• Missing links stop the deploy. If no branch or PR is linked, BranchDeploy says so instead of falling back to a default branch.
• Unsafe branches are blocked. Allowed patterns such as feature/* and bugfix/* keep main and release branches off the QA environment.

What developers and admins get

• Developers stop being interrupted to queue QA deployments. Linking the branch to the ticket, which most teams already do, is all they need to do.
• DevOps admins keep control: BranchDeploy queues the existing QA pipeline as the signed-in user, so pipeline permissions, approvals, and checks all still apply. The free extension stores no credentials.
• Leads get the work item ID passed into the pipeline run and, with Pro, an audit log of who deployed which ticket and branch.

Setting it up for a QA environment

1. Install BranchDeploy from the Visual Studio Marketplace.
2. In Project Settings → BranchDeploy, enter the QA pipeline ID, name the environment QA, and allow feature/* and bugfix/*.
3. Grant the QA group Queue builds on the QA pipeline.
4. Ask developers to create branches from tickets, or link their PRs, so every ticket in Ready for QA has a link.
5. Have a tester deploy one ticket end to end.

Detailed steps are in the setup documentation. If a ticket says no linked branch was found, use the no linked branch checklist.

When one QA environment is not enough

A single QA environment holds one branch at a time, so two testers can overwrite each other's deploys. Common fixes are a short queue on the board's In QA column, or more QA environments. BranchDeploy Pro supports unlimited environments, each with its own pipeline and branch rules, so testers pick QA1 or QA2 in the deploy dialog.

Frequently asked questions

Can testers deploy without knowing Git or Azure Pipelines?

Yes. They work entirely from the Azure Boards ticket. They need permission to queue the QA pipeline, but they do not need to find it or choose a branch.

What if the developer pushes more commits after QA deploys?

Deploy again from the ticket. BranchDeploy queues the linked branch as it is at that moment, so the new run picks up the latest commits.

Can testers deploy to staging or production too?

Only if you configure those environments and the tester can queue those pipelines. Most teams give QA a QA or UAT environment only, and use branch rules to keep it that way.

Is BranchDeploy free for a QA team?

The free plan covers one project with one environment, which is enough for a single QA target. See pricing for Pro.