The purpose of this document is to clearly illustrate the steps required to do a code release for Magento 2 or Craft. Code from these repos can be release released separately or together.
Release Branching strategy and workflow is an ongoing area of improvement. As of 01/25/2023 we have modified our strategy a bit and outlined it here: https://miro.com/app/board/uXjVPuFwtc0=/?share_link_id=649991993824
Foundations of a successful release:
...
End of Sprint Responsibilities (end of Tuesday or first thing Wednesday):
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 owner.
Staging Verification (Wednesday-Monday)
The staging PRs are reviewed and approved by at least 2 developers. The release owner then merges the PR.
All code should be tested thoroughly by the QA team to ensure all new functionality works as expected and all existing functionality has remained unchanged.
Run automated test suites available.
Functional testing will be done against every ticket.
Regression tests will be run on all affected sites to verify continued functionality of core features.
Any issues found during staging verification will be communicated to the PM and developer who did the work.
They will decide if the work should be fixed as a “Release Candidate”** or filed as a bug to be fixed in the current sprint or later.
The release owner should determine if we need any assistance from systems management during the production deployment and, if so, make sure they are invited to the release call.
Day of release (Tuesday after sprint start):
Pull requests from Staging to Production are created, reviewed, and approved by at least 2 developers. They are then merged by the release owner.
Production branches should be tagged with CHM ticket number.
Release owner should communicate to the #sprint-releases channel that the release is beginning.
During the release call, deployments will begin to the production environments slated for release.
QA in charge of release will run and communicate results of automated tests.
QA team will functionally test any indicated high risk tickets.
Once automated and functional tests have passed (or any that have failed have been discussed and a plan for a fix has been created), the release can be marked as a success.
Release owner communicates this to the #sprint-releases channel and marks the CHM ticket as complete
PM will communicate as needed to necessary stakeholders
**A Release Candidate is a bug that needs to be fixed in time to go out with the next release. Process as follows:
A bug ticket is created outlining the issue.
A branch is cut from the release branch, named with the following format:
rc/[ticket number]Fix is made, PR is created and approved.
Fix is merged into the release branch.
QA tests fix on staging.
When fix is confirmed, the release branch is merged back down into
integration