Environments and holds
BranchDeploy shows what is running on each of your environments, and where each work item is deployed, without leaving Azure Boards. On Pro, you can also hold a shared environment so nobody deploys over your testing by accident.
The board and the Deployments group read your Azure Pipelines run history directly, so they also count runs queued from an AI assistant or by hand. They work on every plan, with no BranchDeploy account and no extra permissions.
The environments board
Open Boards → BranchDeploy in any project that has BranchDeploy environments set up. Each environment shows:
- Currently deployed: the newest pipeline run that finished successfully. That’s the work item and branch on the environment, who queued it, and when it finished.
- Deploying now: shown when a newer run is still in progress.
- Last run failed or Last run cancelled: shown when the newest run didn’t succeed, so the environment is still on the previous deploy.
- Held: shown when someone is holding the environment.
The board refreshes every couple of minutes while it’s open, and when you come back to the tab.
Deployments on the work item
Every work item gets a Deployments group on its form. It lists the environments this work item has recently been deployed to, and where it stands on each:
| Status | Meaning |
|---|---|
| On now | The environment’s current deploy is this work item. |
| Deploying | A run for this work item is in progress. |
| Replaced | It was deployed, but something newer has replaced it. The group says what. |
| Last deploy failed | The most recent attempt for this work item failed. |
Environments the work item hasn’t been deployed to recently are left out. If it hasn’t been deployed anywhere, the group says Not deployed to any environment yet.
The group also lists any environment someone is holding, with who, until when and why, so you know before you deploy over it.
The group is read-only. BranchDeploy never edits your work items, so the extension doesn’t ask for permission to write to them.
To move or hide the group, edit the work item type’s layout in your process settings, as you would for any other group.
Holding an environment (Pro)
When you need a shared environment to stay as it is, say for a test run or a client demo, hold it. You can do it in either of two places.
When you deploy. In the deploy confirmation, tick Hold UAT after deploying, choose how long (1 hour, 4 hours, 1 day or 3 days) and optionally add a short reason. The hold is placed once the deploy is queued, so a failed deploy never leaves one behind. If you already hold the environment, the option reads Update your hold on UAT.
From the board.
- Open Boards → BranchDeploy.
- Click Hold environment on the environment you’re using.
- Optionally add the work item you’re testing and a short note, and choose how long.
While the hold is active:
- Anyone else who deploys there sees “Heads up: Sam Lee has asked that nobody deploys over UAT until 15:00 (Client demo, #1250). You can still deploy.” in the deploy confirmation, and the button reads Deploy to UAT anyway.
- The environment shows Held on the board, and the hold is listed in the Deployments group on every work item.
- The holder sees a reminder instead, “Reminder: you’re holding UAT until 15:00 (Client demo)”, and anyone deploying the work item named in the hold sees it mentioned without a warning.
- AI assistants connected over MCP tell you about the hold before you confirm a deploy there. This needs the Extension Data (Read) scope on the PAT saved in your account.
- Only the person who placed the hold can change it. Nobody else is offered Hold UAT after deploying until it ends or is released.
A hold is a warning, not a lock. It never stops a deploy. It ends on its own when the time runs out, and anyone can release it early from the board, so a forgotten hold can’t block the team.
Holds are stored in your Azure DevOps organisation’s extension data, next to your BranchDeploy settings. They are not sent to BranchDeploy’s servers.
Before you deploy
On every plan, the deploy confirmation also says what you’re about to replace:
#1234 Round tax per line at checkout (feature/checkout-tax) is currently deployed on UAT. Deployment made by Jane Dev 2 hours ago.
It also says whether a deploy to that environment is already running. If Azure DevOps is slow to answer, the confirmation opens without these lines, so a deploy is never held up.
How BranchDeploy matches runs to environments
BranchDeploy reads the 50 most recent runs of each environment’s pipeline.
- Several environments on one pipeline: BranchDeploy tells them apart by the environment variable you set in configuration. A run without that variable, such as a CI trigger, isn’t counted for any of them, because its target can’t be known.
- One pipeline per environment: every successful run of that pipeline counts as a deploy to it.
- Work items: a run belongs to a work item when its work item ID variable names it. Runs without that variable are matched by the work item’s linked branch.
If your environments share a pipeline, set the environment variable name and value for each one, so the board can tell them apart.
Who deployed
The board shows the person Azure DevOps lists as requested for on the run. For deploys from the extension, that’s the person who clicked deploy. For deploys from an AI assistant, it’s the owner of the Azure DevOps PAT saved on your account, which is why we recommend creating that PAT from a service account. The audit log records who actually asked.
