I am part of a development team that uses git and Azure DevOps to manage our work.
Our work items in Azure DevOps show updates by way of added links well beyond the point we have merged the related code into our release branch. I don't know if we have a problem with our work item or transition configuration or with our development processes or, perhaps, both.
Symptoms:
- When we merge code from our working development branch to the release branch (both long-lived git branches managed with policies), we see dozens or hundreds of past work items going back for months, and long since completed, associated with the merge PR. Maybe this is related to this issue?
- On most closed work items, we see continual updates in the form of added links for different types of seemingly unrelated activity or activity on one of the long-lived branches.
The net result are zombie work items that clutter the merges between long-lived branches.
What we would like to achieve is a merge into our release branch with a PR that has only the work items related to the new code in that release. And once a piece of work is deployed, the related work items are no longer updated.
Our code process looks like this:
- Developers work in local branches and submit PRs to commit their work into our shared development branch.
- The PR is squash-committed into the shared development branch after code review and approval.
- At code freeze, we merge the shared development branch into the release branch, using the Merge (no fast-forward) strategy.
- The QA team certifies the release candidate. Bugs are fixed and merged directly into the release branch with squash commits.
- After the deployment, changes to the release branch are merged back down to shared development with the Merge (no fast-forward) strategy.
Are there any changes we can make to clean up our work item management?
Update:
We associate work items to pull requests (enforced by branch policies), never explicitly to branches. When a PR is approved, the work item is associated to both a commit and a PR:
To restate the issue, unless we manually intervene in some way, Azure Devops now creates a new commit link and PR link every time we merge code between long-lived branches.
In the example below, showing commit links (PR links also look like this), a user story was approved and committed to the development branch on July 9 and the merge to release was done later that day. Ideally, that would be the last link, but instead we see a link created for every subsequent merge between the two long-lived branches.
If you focus just on the July 16 merge from release back to development, this is why I suspect that the way diffs are determined is at fault. This work item is already in development, so the only way the two branches are different would be if you looked at the history. Which, if I understand correctly, is the way Azure Devops works, but which is also a source of pain for many organizations.
