Between deciding that a release is ready and deploying it, teams often pull a work-item list from a tracker, compare it with the tag, write release notes, complete a change request, and have someone review the diff. Generating notes directly from the tag is reliable, but it does not verify a list that was maintained separately.
Common mismatches include a hotfix cherry-picked onto a release branch without being added to the tracker, a pull request merged just before the tag after the notes were written, a completed ticket whose change was later reverted, or a release spanning multiple repositories while the notes cover only one.
If your release starts from a ticket list rather than generated notes, how do you detect items that do not match Git? Which parts remain human review, and which parts have you automated?
1 Answer
Make the ticket identifier mandatory in every pull request title and enforce it with a required CI check. At release time, extract the identifiers from the commits between the previous and current tag, then compare that set with the tracker’s release list in both directions. Items in Git but absent from the tracker reveal unclaimed hotfixes; items in the tracker but absent from Git reveal work that was pulled or never merged. Run this check in CI and publish the mismatches so a person only investigates exceptions.
Reverts need special handling. If a revert appears in the same range, remove the reverted ticket from the shipped set. For releases spanning multiple repositories, run the extraction for each repository and union the identifiers before comparing them with the tracker.
For a commit that references a ticket missing from the release field, I’d report it explicitly as “shipped but unclaimed” rather than ignore it. That makes the ownership problem visible and lets the release coordinator decide whether the tracker needs updating or the change needs investigation.