Releases to Production

Usually, Big Bite would have dictated what goes into the release, however, 2U will have final say of what is high priority to go into the release.

To assign a ticket to a release we utilise Labels in GitHub to add a version number to track the upcoming release e.g. 6.25.0

A Release Candidate should be created to track all of the tickets going out in that release:

Note: If a ticket needs to be removed from the release, the label should be removed from both the ticket & the PR and the ticket should be removed from the release candidate.

All tickets should move through the following stages:

  1. In Development > PR Created: Once an engineer has created a PR for the ticket, the ticket should be moved to the PR Created column on the project board in Github.
    • Important: All PRs should include steps to test the change/fix and a screenshot or video of the fix/change working – this will be used by the QA team to test the ticket.
  2. PR Created > PR Approved: Another engineer should then perform a PR review and either approve it or request feedback if there are any changes that need to be made.
    • If a PR requires changes, move the ticket to the PR Feedback Requested column on the project board.
    • If the PR is approved, move the ticket to the PR Approved column on the project board.
  3. PR Approved > Merged to Release Branch: Once a PR is approved, it can be merged to the Release Branch for the release version it is going out in. Once merged, the ticket should be moved to the Merged to Release Branch column on the project board in Github.
    • We encourage using release branches to make it easier to keep track of the codebase/issues/PRs etc with a source of truth for the code being released
  4. Merged to Release Branch > Merged to Staging/Internal Testing: The release branch can be merged into the Develop environment when ready to undergo QA. Tickets should then be moved to the Merged to Staging/Internal Testing column on the project board.
  5. At this stage, the QA team can go in and test on the Develop environment, however, if they prefer to test on UAT, the engineers can merge the release from Develop into UAT from here if they are happy the changes look good on Develop.