Skip to content

Release process

Jump to bottom
roxy-dao edited this page May 14, 2024 · 22 revisions

Open mSupply Release Process

This is the process followed when creating a release. It's written out here as a knowledge sharing process really, those of you who do the releases will know most of this, though perhaps a checklist or reference is helpful.

Checklist

Here's an outline of the steps to take when making a release. Think of this as your cheatsheet - for more information see the sections below

RC

  • Git fetch
  • Pull release branch & main
  • (maybe) Bump the version in the root package.json
  • Push the changes
  • Add tag git tag vX.Y.Z
  • Push tag git push origin vX.Y.Z
  • Create android build
  • Draft a new pre-release on GitHub
  • Edit details
  • Upload assets

Release

  • Merge feature branch to main
  • Merge main to develop
  • Delete the release branch

Branches overview

This is the branching strategy that we're using (ref)

image

Branch Protected? Base Branch Description
main YES N/A What is live in production (stable).
A pull request is required to merge code into main.
develop YES main The latest state of development (unstable).
feature NO develop Cutting-edge features (unstable). These branches are used for any maintenance features / active development.
release-vX.Y.Z NO develop A temporary release branch that follows the semver versioning. This is what is sent to UAT.
A pull request is required to merge code into any release-vX.Y.Z branch.
hotfix-* NO main These are bug fixes against production.
This is used because develop might have moved on from the last published state.
Remember to merge this back into develop and any release branches.

Create and deploy a release

When it comes to release time, the process is as follows:

image

  1. Merge main into develop to ensure the new release will contain the latest production code. This reduces the chance of a merge conflict during the release.

    $ git checkout develop
$ git merge main

  2. Create a new release-vX.Y.Z release branch off of develop.

    $ git checkout -b release-vX.Y.Z
$ git push --set-upstream release-vX.Y.Z

  3. Create a new milestone vX.Y.Z-RCx (Replace with next RC version for history) and move all the uncompleted issues for version into this milestone so testers know which bugs have been fixed with what version in their tester board. From here, any bug fixes as a result of QA will go into the release branch

  4. When the code is ready to release, navigate to the project on Github and open a pull request with the following branch settings:

    • Base: main
    • Compare: release-vX.Y.Z Update with details of the release

  5. If the version hasn't been bumped in the root package.json then do this now

  6. At some point in the checklist you will merge the release branch into main. You can do this by using the "Merge pull request" button on the release PR.

  7. Add a tag, this will start a build process on Jenkins

    git tag vX.Y.Z
git push origin tag vX.Y.Z

    note that for the Jenkins build, the tag must start with v

  8. Create the android build

    cd ./client
yarn android:build:release

  9. Now you are ready to create the actual release. Navigate to the project page on Github and draft a new release (or pre-release for RC versions)

    • Click on the Draft a new release button: image

    • Click on Choose a tag image

    • Select vX.Y.Z from the list

    • This should set the 'previous tag' to 'auto'. Enter the tag as the heading of the release: image

    • Edit the description. This is the format used:

    ### What's in this release
[a brief description of the highlights]

#### Features
- [bullet point for each feature, with a one-liner about them]

#### Bugs fixed
- #[issue number] [hand crafted description]

**Full Changelog**: https://github.com/openmsupply/open-msupply/compare/v1.1.14...v1.1.15

    You will find it helpful to click the Generate release notes button. This will give you a list of all PRs merged in this release. From there you can rewrite descriptions and gather up a list of changes.

    • Upload the assets
      • Android apk which you've just built
      • All the assets from the jenkins build. Note that dropbox is much faster to download from!
    • Set as latest release
    • Click Publish release

Testing Cycle

  1. Move all completed issues that are in milestone vX.Y.Z-RCx into the version milestone.

  2. Update docs for current version by filtering out docs: external in the Done PR list, and re-label the PRs with docs: done.

  3. Do daily triage for critical bugs that may stop the user from using some functionality and add them to the RCx milestone.

  4. Evenly assign bug issues to each team.

Testing Process

Note: Testers should always be using the latest RC build for their tests. This means that they should swap to the new RC version if it is available for the rest of their testing.

  1. Write up/update test suites as required
  2. Test new features first
  3. Go through the rest of the other test suites
  4. Once the test suites have been completed, individual bug issues can be tested. QA team gets this from their tester board, so please correctly label every issue with the correct milestone.

Release

  1. Merge the release-vX.Y.Z into develop.

    $ git checkout develop
$ git merge release-vX.Y.Z
$ git push

  2. Close the release PR.

  3. Delete the release branch on Github.

Clone this wiki locally