Between declaring a release ready and deploying it, teams often pull a list from a tracker, compare it with the release tag, generate notes, complete a change request, and have someone review the diff. The problem is that generating notes from the tag only proves what is in Git; it does not verify a list maintained separately in a tracker.
Common mismatches include hotfixes cherry-picked onto a release branch without a corresponding ticket update, pull requests merged after the notes were written, completed tickets whose changes were later reverted, and releases spanning multiple repositories while the notes cover only one.
If your release process starts with a ticket list rather than generated Git notes, how do you detect items that do not match the tag? Which parts do you automate, and where is human review still necessary?
3 Answers
Reverts need special handling. A squash-merged revert often preserves the original ticket key with a “Revert” prefix, so the reconciliation step should remove the reverted change from the shipped set when the revert is inside the release range. Also keep a documented fast-track process for emergencies: record who approved, what changed, when it shipped, and how the tracker and release notes were updated. Automation should verify that process, not replace the final human review.
Make the ticket key mandatory in every pull request title and enforce that with a required CI check. At release time, extract the keys from the commits between the previous and current tags, then compare that set with the tracker’s release list in both directions. A key in Git but not the tracker indicates an unclaimed change, such as a hotfix; a key in the tracker but not Git indicates work that was removed or never merged. Run this check in CI when the tag is created and publish the mismatches for review. For multiple repositories, collect the keys from each repository and compare their union with the release list.
That handles most cases well. I’d explicitly label a ticket referenced by Git but absent from the release field as “shipped but unclaimed,” rather than silently ignoring it. That makes the discrepancy visible and gives someone a chance to correct the tracker.
The cleanest process is to make Git the source of truth: use one issue per work item, one branch and pull request per issue, require the issue reference, squash merge into the main branch, and create tags only from that branch. Never cherry-pick into the release path. Then the commit range between two tags can generate the release notes directly. If every change maps cleanly to an issue, there is little value in adding another reconciliation tool.
That works when the team can make Git authoritative. The harder case is when the tracker is intentionally the release source of truth, or when operational exceptions allow a hotfix or a pulled ticket. In that setup, comparing the two systems is still useful even with a disciplined branching model.
Exactly. The automated result should become part of the release artifact: not just a claim that the list was reviewed, but the actual verification result and any exceptions that were resolved.