Skip to content

Release process

Simon Laing edited this page Aug 26, 2025 · 5 revisions

Each release to production should be associated with a milestone. Milestones should be marked in vX.Y.Z (semver) format. The milestone should be created and associated to pull requests and issues as they are merged into main.

The pull request from main to release should be tagged to the same milestone. When the pull request is merged the milestone should be closed. The milestone should be closed automatically as the release branch is merged.

The pull request from main to release should explain the changes and bug fixes being released. References to the tickets should be included in the description for tracking.

Releases are automated by GitHub and take approx 10 minutes to complete. The merge of the pull request will trigger the automated test run and deployment to production.

The main branch should always be mergable to release, allowing for continuous deployment and rapid fixes to any issues.

Testing process

Each change should be tested via a deployment of its feature branch before merging to main. Once everything has been tested, and unit tests updated it can be merged to main. Once merged to main the feature and other changes in main will be redeployed to the UAT environment.

The set of changes should be tested with production like data in UAT before it is allowed to be merged to release.

The UAT environment is refreshed with production data on a weekly cycle. Any data created in production will be created/updated in UAT. Any data created in UAT will be left as-is.

Release timing

Releases to production should not happen at any of the follow times:

  • Thursday PM (when in season)
  • Saturday PM (when in superleague season)
  • On the day of a AGM meeting

Hot fixes

Hot fixes can be applied to the release branch directly as required. A milestone should be created as per a normal release.

Once merged to release, the release branch should be merged back to main immediately.

Coverage expectation

Both the react and dotnet components each should not drop below 95%, meaning that the solution as a whole should never drop below 95%.

Clone this wiki locally