Release Process

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 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:

• There are three “owners” involved in each release:

  • A developer acting as a release owner who is responsible for

    • Cutting release branches on associated repositories

    • All 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 PRs to Staging. If not, it will need to be reverted. Consider this before merging in any approved PRs near the end of the sprint.

End of Sprint Responsibilities (end of Tuesday or first thing Wednesday):

1. A code freeze will be enacted on the staging environments, aside from any hotfixes/release candidates required for release.

2. The assigned PM will finalize ticket selection for the upcoming release.

3. The release owner creates PRs from individual feature branches to Staging.

Staging Verification (Wednesday-Monday)

1. The staging PRs are reviewed and approved by at least 2 developers. The release owner then merges the PR.

2. 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.

   1. Run automated test suites available.

   2. Functional testing will be done against every ticket.

   3. Regression tests will be run on all affected sites to verify continued functionality of core features.

3. Any issues found during staging verification will be communicated to the PM and developer who did the work.

   1. 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.

4. 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):

1. Pull requests from Staging to Production are created, reviewed, and approved by at least 2 developers. They are then merged by the release owner.

2. Production branches should be tagged with CHM ticket number.

3. Release owner should communicate to the #sprint-releases channel that the release is beginning.

4. During the release call, deployments will begin to the production environments slated for release.

5. QA in charge of release will run and communicate results of automated tests.

6. QA team will functionally test any indicated high risk tickets.

7. 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.

   1. Release owner communicates this to the #sprint-releases channel and marks the CHM ticket as complete

   2. 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:

1. A bug ticket is created outlining the issue.

2. A branch is cut from the release branch, named with the following format: rc/[ticket number]

3. Fix is made, PR is created and approved.

4. Fix is merged into the release branch.

5. QA tests fix on staging.

6. When fix is confirmed, the release branch is merged back down into integration