Release the work
Deploy the accepted change to production through the team's approved process, observe the result, and close the ticket only when it meets the Definition of Done.
Product owns the go-live decision with the required technical and business input, as described in How We Build. This page names the ticket checkpoints, not a single deploy command or production host.
Prerequisites
- Acceptance has passed on the current published branches.
- Rollout, monitoring, and rollback match the delivery risk tier.
- Anyone who must act during rollout knows the owner and the recovery path.
Release the change
- Confirm the go-live decision and the risk-tier controls that apply.
- Merge or promote the source-code change through the repository's approved process.
- Deploy Builder and source-code artifacts in the order recorded on the pull request.
- Observe success and failure signals. Confirm that monitoring can distinguish likely causes.
- Update the Jira record with the production result, remaining limitations, and any follow-up tickets.
- Close the ticket only when the Definition of Done is met.
A contained, reversible change may ship with peer review, a defined measure, and an easy rollback. Customer-visible or difficult-to-reverse work needs staged release, stronger evidence, and an explicit rollback path.
Release checklist
- Acceptance criteria are still met by the artifact being deployed.
- The implementation has been reviewed and accepted.
- Monitoring, staged rollout, rollback, and recovery match the risk tier.
- Documentation and support guidance are current where the change needs them.
- Remaining limitations are named and accepted by the accountable owner.
- Jira status, owner, and follow-ups match the production result.
When release fails
Roll back or otherwise recover through the approved process. Assign an owner and unblock condition. Return to execution if the product must change, then repeat submit, test, and accept on new published branches. Do not leave production and Jira showing different outcomes.
Expected result
The change is in production, observed, and safe to leave in another person's hands. The ticket is complete because it meets the Definition of Done, not because implementation stopped.
Related
- How We Build — release and learn
- Ready and done — Definition of Done
- Sprint cadence and Jira — keep the record current