Branch allowlist patterns for Azure DevOps deployments

Branch allowlists are a simple control: they decide which linked branches BranchDeploy is allowed to deploy before it queues Azure Pipelines. If the resolved branch does not match an allowed pattern, BranchDeploy blocks the deployment.

This is useful for QA, staging, and UAT workflows where feature branches should be deployable, but production or protected branches should not be deployed through the work item button.

How BranchDeploy matches patterns

BranchDeploy accepts glob-style patterns, one per line, in Project Settings -> BranchDeploy -> Allowed branch patterns. A pattern can match a short branch name, such as feature/*, or a full ref, such as refs/heads/main.

Good default for feature QA

feature/*
bugfix/*
task/*
chore/*

This allows normal ticket branches while keeping main, develop, and release/* out of the work item deployment path.

Good default for UAT

feature/*
bugfix/*
release/*

This allows release branches when UAT is used for release candidates, while still blocking direct deployment of main unless you explicitly allow it.

Good default for release-candidate environments

release/*
hotfix/*

This keeps the environment focused on release and hotfix validation. Feature branches can still deploy to lower environments, but not to the release-candidate target.

Patterns to avoid

Wildcard-only allowlists

* is useful while testing BranchDeploy configuration, but it removes the main value of an allowlist. Replace it with explicit branch families before giving the workflow to the wider team.

Allowing protected branches by accident

Do not include main, master, develop, or release/* unless those branches really should deploy through this environment.

Mixing naming conventions

If some teams use feature/ and others use features/, one pattern will not match both. Standardize branch names or include both patterns intentionally.

How allowlists interact with Azure Pipelines

BranchDeploy checks the branch before it queues the pipeline. Azure Pipelines can still enforce its own YAML conditions, branch filters, approvals, and environment checks after the run starts.

Use BranchDeploy allowlists to prevent obvious wrong-branch deployments at the work item level. Use Azure Pipelines controls to enforce deployment rules inside the pipeline.

Recommended rollout

1. Start with the branch families your team actually deploys, such as feature/* and bugfix/*.
2. Test with a linked work item for each branch family.
3. Try a blocked branch, such as main, and confirm BranchDeploy stops before queueing the pipeline.
4. Document the branch naming convention for developers and QA.
5. Review allowlists when adding new environments or branch naming schemes.

For the exact configuration fields, see Allowed branch patterns.