Skip to content

9. Release Close-out
What Merging the shipped release back into permanent branches, deleting it, and locking the JIRA Release.
Owner Engineering (merges and notifies), Project Manager (closes the JIRA Release).
Triggers Immediately after a successful production deployment.

Summary

After a release ships, it is closed out cleanly so the codebase and tracker stay consistent. The release branch is merged into both master and develop (and any other active release branches), then deleted. The JIRA Release is closed the same day, which locks it: no new stories, tasks, or bugs can be added. Other developers are notified to pull the latest tag into their own release branches so everyone builds on the shipped code. Skipping close-out is how version drift and merge conflicts accumulate.

Full detail

Merge back

When the release (or hotfix) is fully tested, approved, and tagged:

  1. Merge into master: release/<version> into master, so production-ready code is on the production branch.
  2. Merge into develop: release/<version> into develop, so future development already contains these changes.
  3. Merge into any other active release branches if applicable, or at minimum inform the owners of those branches so they incorporate the changes.

Delete the release branch

Once merged into master and develop, delete the release branch. Its permanent record lives in the tag, not the branch. Leaving stale release branches around invites accidental commits and confusion about which line is current.

Close the JIRA Release the same day

The JIRA Release MUST be closed on the same day the build is released to users. Closing it:

  • Marks it as released and locked.
  • Prevents any further modification.
  • Forbids adding new stories, tasks, or bugs to that release.

Any new work after closure requires a new JIRA Release with a new version number, matching a new release branch and app version. Reusing a closed version's number is forbidden, because it creates two branches with the same version but different code.

Notify the team

Inform other developers to pull the latest tag into their own respective release branches (if any are active). This keeps everyone building on top of what actually shipped and prevents the next release from silently missing these changes.

flowchart TD
    A[Production deploy successful] --> B[Merge release into master]
    B --> C[Merge release into develop]
    C --> D{Other active release branches?}
    D -->|yes| E[Merge into them or inform owners]
    D -->|no| F[Delete release branch]
    E --> F
    F --> G[Close JIRA Release same day - locked]
    G --> H[Notify devs: pull latest tag into your release branches]

Example

v1.4.0 is live. The lead merges release/v1.4.0 into master and develop, confirms no other release branch is active, and deletes release/v1.4.0. The PM closes JIRA Release v1.4.0 that afternoon, locking it. A message goes to the team: pull tag v1.4.0. A week later a new request arrives; rather than reopening v1.4.0, a new JIRA Release v1.5.0 and branch release/v1.5.0 are created for it.