How to deploy a pull request source branch with Azure Pipelines

When an Azure Repos pull request is linked to a work item, the branch you usually want to deploy for QA is the PR source branch. That is the feature branch being merged, not the target branch such as main or develop.

This distinction matters because selecting the target branch deploys code after merge, while selecting the source branch deploys the changes that are currently under review.

Source branch vs target branch

Manual method

1. Open the pull request in Azure Repos.
2. Copy the source branch name from the PR header.
3. Open the deployment pipeline in Azure Pipelines.
4. Click Run pipeline.
5. Select the source branch, not the target branch.
6. Enter any required variables, such as environment or work item ID.
7. Queue the run.

This works, but it depends on the person deploying the PR choosing the correct side of the pull request.

CLI method

You can ask Azure Repos for the PR source ref and then run the pipeline on that branch.

az repos pr show \
  --org https://dev.azure.com/YOUR_ORG \
  --project "YOUR_PROJECT" \
  --id 123 \
  --query sourceRefName \
  --output tsv

If the command returns refs/heads/feature/checkout-flow, queue the pipeline on the branch name:

az pipelines run \
  --org https://dev.azure.com/YOUR_ORG \
  --project "YOUR_PROJECT" \
  --id 42 \
  --branch feature/checkout-flow

Use the same organisation, project, and repository context for both commands so you do not mix a PR from one project with a pipeline from another.

BranchDeploy method

BranchDeploy reads the Development links on the Azure Boards work item. If the work item has a linked pull request, BranchDeploy resolves the PR source branch and uses that as the pipeline run source.

The confirmation step shows the resolved branch before the pipeline is queued. That gives QA a clear check: the deployment is for the feature branch under review, not the PR target branch.

Watch out for PR validation refs

Azure Pipelines PR validation runs can use PR-specific refs, such as merge refs created for validation. Those are useful for build validation, but they are not the same as manually deploying the feature branch to UAT.

For a deployment run, prefer the source branch ref, such as refs/heads/feature/checkout-flow. If your YAML conditions restrict deployment stages, make sure they allow the source branch pattern you expect:

condition: startsWith(variables['Build.SourceBranch'], 'refs/heads/feature/')

When the source branch has been deleted

If the PR is completed and the source branch has been deleted, there may be no feature branch left to deploy. In that case, either deploy the target branch after merge or create a new branch from the commit you need to test.

For BranchDeploy, a deleted source branch can make an old PR link less useful. Keep work items linked to the current branch or active PR while they are in QA.

Recommended workflow

1. Create the branch from the work item, or link the PR back to the work item.
2. Use BranchDeploy from the work item when QA needs to deploy the change.
3. Confirm that the branch shown in the dialog is the PR source branch.
4. Use branch allowlists such as feature/* or bugfix/* to block accidental target-branch deployments to non-production environments.

Official Azure DevOps references

• Azure Repos pull requests
• Get Pull Request REST API