...
There are three “owners” involved in each release:
A developer acting as a release owner who is responsible for
Cutting release branches on associated repositoriesAll PR creations and code deployments to staging and production
Creation and ownership of the release’s CHM ticket
Coordinating with QA around Staging Verification and readiness for Prod
Communicating in #sprint-releases when a release begins and is marked as complete
A Product Manager who is responsible for
Communications around the release to internal and external stake holders
Selection of tickets to be released
Scheduling release calls
Determining Release Candidates as needed
A QA Engineer who is responsible for
Ensuring each ticket is functionally tested as part of Staging Verification
Communicating any concerns related to releasing to production uncovered in testing
Selecting high-risk tickets to be functionally tested in production
Running and communicating results of automated tests
All code merged into integration should be tested and PM reviewed prior to creating the release branchesPRs to Staging. If not, it will need to be reverted. Consider this before merging in any approved PRs near the end of the sprint.
...
A code freeze will be enacted on the staging environments, aside from any hotfixes/release candidates required for release.
The assigned PM will finalize ticket selection for the upcoming release.
The release owner cuts a release branch for each repo in the release.
The release branch name should follow the following format: release/MM-DD-YY-[repo]
i.e.
release/02-22-22-craft
PRs to staging targeting the from the release branches are created by the release ownercreates PRs from individual feature branches to Staging.
Staging Verification (Wednesday-Monday)
...