Deriving status from source control instead of maintaining it in Bitbucket
How to turn branch, pull request and deployment events in Bitbucket into a status your board can trust, and how to tell when the derivation has quietly stopped covering most of your work.
Your board says one thing and Bitbucket says another. Someone spends part of Thursday reconciling them by hand, standup is a verbal diff between two systems, and by Monday the board has drifted again. The work is being done and recorded; it is just being recorded in the place where nobody is looking.
The fix is not more discipline about updating tickets. It is to stop treating the ticket as the source of truth about progress and start deriving progress from the thing that cannot lie about it: the repository.
Every transition you need is already being emitted
Bitbucket emits every transition you need, whether or not you are consuming them.
Branch created. Someone has started. This is the single most underused signal in most delivery setups, because it is the earliest honest one. A ticket sitting in the backlog with a branch against it has started, regardless of what the board says.
Commits pushed. Ongoing activity, and a rough liveness signal. A branch with no commits for three weeks is not in progress, it is abandoned, and the board almost never knows.
Pull request opened, approved, declined, merged. The review lifecycle. Opened means the author considers it ready for someone else. Merged means it is on the target branch, which is not the same as released.
Pipeline result, and specifically a deployment. Bitbucket Pipelines can declare that a step deploys to a named environment, which produces a deployment record rather than just a build record. That distinction matters enormously. A green build says the code compiled. A deployment says this commit reached that environment at that time. Only the second one answers the question your stakeholders are actually asking.
If your tracker is Jira, most of the plumbing is already there. Link the repository to the Jira site, and put the issue key in the branch name, the commit message and the pull request title. The development information then flows back automatically, and Jira automation can trigger on those development events rather than on someone remembering. Bitbucket also supports commit-message commands that act on the linked issue, adding a comment or moving it along. The available command set and syntax vary by product and version, so check yours rather than copying an example off the internet.
Set up that way, a large chunk of your board maintenance disappears. For a single-repo team on Jira, this is genuinely most of the problem solved, and you should stop reading and go and configure it.
Linking rate is the whole game, and nobody measures it
Linking rate is the whole game, and nobody measures it. Derivation only covers work that carries an identifier. If seventy percent of your merged pull requests reference a ticket, then your derived board is thirty percent wrong and confidently so, which is worse than being obviously incomplete. Measure this before you trust anything downstream: over the last month, what share of merged pull requests reference a ticket that exists? Most teams guess high by twenty points.
Bitbucket Cloud and Data Center do not enforce the same way. Data Center can run server-side hooks that reject a push or a pull request outright. On Cloud you generally cannot, so enforcement has to live in a pipeline step that fails the build when the branch or pull request carries no valid identifier. Both work. Confirm what your deployment actually supports before promising anyone a hard gate.
Merge is not the end and the derivation usually stops there. If your pipelines do not declare deployment environments, Bitbucket has no record of anything after the merge, and your derived status tops out at a state that sounds finished but is not.
One ticket, several repositories. A change spanning three services produces three branches and three merges. Each repository sees a complete story. Nothing sees whether the ticket is done, because “done” is the conjunction and no single repository can evaluate it.
Reverts. A revert is a normal merge. Derivation will happily leave the ticket in a shipped state while the code is no longer in the product.
Non-Jira trackers. Bitbucket’s tightest integration is with the rest of the Atlassian stack. If your work lives elsewhere, there is no first-class link, and you are consuming webhooks and calling the tracker’s API yourself.
Fix the convention before you build anything
Fix the convention before you build anything. Agree one identifier format, put it in the branch name, and generate branch names from the tracker rather than typing them. Nine tenths of linking failures are a human typing a key from memory.
Then measure. A weekly report of merged pull requests with no resolvable ticket, posted where the team can see it, moves linking rate faster than any policy. It works because it is a list of names attached to specific pull requests, not a percentage.
Then enforce, gently. A pipeline step that warns for a month and fails afterwards. Give people the escape hatch of a documented keyword for genuine no-ticket work, and count how often it gets used. That count is a finding in itself.
Then declare your deployments. If you take one structural change from this guide, make it this. Have the pipeline record a deployment to a named environment. It costs a few lines of configuration and it converts “merged” into “live”, which is the answer everybody outside engineering wanted in the first place.
Then write the consumer. A small service subscribed to repository webhooks, resolving the identifier, and calling your tracker’s API. Keep it stateless, make it idempotent, and re-fetch the pull request by ID rather than trusting the payload.
That last step is where teams underestimate the work. The webhook consumer is an afternoon. Keeping it correct across reverts, force-pushes, renamed branches, multi-repo changes and two years of drift is the actual cost, and it is the reason products like ours exist. We build GroundTruth to derive status across GitHub, GitLab and Bitbucket and write it back into the tracker, with full sync for Jira, Linear and Azure DevOps. We have a commercial interest in you not writing that service, so discount this paragraph accordingly and note that for one repository and one tracker, the native path above is the right answer.
Where this breaks down
Derived status can be confidently wrong. A hand-maintained board is visibly stale and everyone treats it with suspicion. An automated board looks authoritative. If the derivation misses a class of work, people will believe the wrong picture for longer, and the failure will be harder to spot.
Not all work has a branch. Configuration changes, data fixes, vendor escalations, incident response. Deriving from source control makes that work invisible, and the teams that do most of it are the ones already fighting to be seen.
Some teams need the manual step. The moment of moving a card is when a person asserts something is finished. Remove it and you remove a deliberate act of judgement. If your definition of done includes anything a repository cannot observe, keep a human transition at the end and derive everything before it.
The Atlassian path locks you in further. The tightest version of this uses Bitbucket with Jira. That is a real answer and also a deeper commitment to one vendor. Worth naming out loud rather than discovering at renewal.