Why Azure Pipelines manual runs deploy the wrong branch

A manual Azure Pipeline run can deploy the wrong branch for simple reasons: the default branch was left selected, a similar branch name was chosen from autocomplete, a PR target branch was copied instead of the source branch, or the pipeline YAML ignores the selected branch in a later step.

The fix is to make the selected source branch visible and reduce the number of places where a user has to type or copy it.

Most common causes

The default branch was selected

The Run pipeline dialog often opens with the pipeline's default branch selected. If the user does not change it, the run may deploy main or develop instead of the feature branch.

The branch name was copied manually

Long ticket branch names are easy to mistype or choose incorrectly from autocomplete. Similar names such as feature/1234-checkout and feature/1234-checkout-fix are a common source of wrong-branch runs.

The PR target branch was used

For a PR from feature/checkout-flow into main, the branch to test before merge is usually the source branch. Copying the target branch deploys the shared branch instead.

The YAML checks out a different ref

Most pipelines check out the selected source branch by default. But custom checkout logic, scripts, or deployment templates can override that behavior. If the run claims to use one branch but deploys another, inspect the checkout and deployment steps.

Branch filters or conditions skip deployment stages

The run may start on the right branch, but a deployment stage may be skipped because a YAML condition only allows main or release/*. This can make users rerun the pipeline on a different branch until something deploys.

How to diagnose it

Add an early diagnostic step to print the branch Azure Pipelines thinks it is running on:

steps:
  - script: |
      echo "Build.SourceBranch=$(Build.SourceBranch)"
      echo "Build.SourceBranchName=$(Build.SourceBranchName)"
    displayName: Print selected branch

Then check the run summary and logs:

• If Build.SourceBranch is wrong, the run was queued with the wrong source branch.
• If Build.SourceBranch is right but the deployed artifact is wrong, inspect checkout, build caching, artifact download, and deployment scripts.
• If the deployment stage skipped, inspect branch conditions and stage conditions.

Manual fix

1. Open the work item or PR that contains the change.
2. Copy the exact source branch, including the correct prefix such as feature/ or bugfix/.
3. Open the deployment pipeline.
4. Click Run pipeline.
5. Replace the default branch with the source branch you copied.
6. Confirm any variables or parameters.
7. Queue the run and verify Build.SourceBranch in the logs.

Every step above where a person types, pastes, or picks a branch name is a chance to get it wrong again. The more often your team deploys tickets to QA or UAT, the more often that happens.

BranchDeploy fix

BranchDeploy reduces wrong-branch runs by removing the manual branch-copy step. It reads the linked branch or PR source branch from the Azure Boards work item and shows it in a confirmation step before queueing the pipeline.

Each cause above maps to a specific guard:

This does not replace good pipeline design. The pipeline still needs to deploy the selected source branch, and YAML conditions still apply. But it removes the most common input error: a person choosing the wrong branch in the Run pipeline dialog. For how the linked branch is chosen, see deploy the linked branch from an Azure DevOps work item.

Prevention checklist

• Create branches from work items so the Development link is created automatically.
• Print Build.SourceBranch early in deployment pipelines.
• Use branch allowlists to block branches that should never deploy to the target environment.
• Keep pipeline branch conditions aligned with the branches your team actually deploys.
• Use BranchDeploy for QA and UAT handoffs that start from Azure Boards work items.

Frequently asked questions

Why does Run pipeline default to main?

The Run pipeline dialog starts on the pipeline's default branch for manual and scheduled builds, which is usually main. You can change it in the pipeline's YAML settings, but whatever the default is, someone still has to switch it to the branch they mean to deploy.

How do I check which branch a run actually used?

Open the run summary, which shows the source branch, or print $(Build.SourceBranch) in an early step as shown above. If that value is right but the wrong code was deployed, the problem is in checkout, artifacts, or deployment scripts rather than branch selection.

Can I stop people deploying main to a test environment?

Yes. In Azure Pipelines, use stage conditions or environment checks. In BranchDeploy, leave main out of the environment's allowed branch patterns and the deployment is blocked before a run is queued. See branch allowlist patterns.

Does BranchDeploy work if the branch is not linked to the work item?

No. It only deploys branches and PRs linked in the work item's Development section, which is what stops it guessing. See how to link a work item to a branch.

Official Azure DevOps references

• Azure Pipelines predefined variables
• Pipeline conditions