Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Our Community Environments: 

Dev EnvironmentQA EnvironmentProduction Environment

Most recent committed dev work

Most Recent Release

A specific version of O3 RefApp release

Sample login for all these is admin/Admin123.

Our Release Process:

Ongoing: PR Smoke TestsStep 1: QA ReleaseStep 2: Manual ChecksStep 3: O3 RefApp Release

Automatic tests are set up in the major O3 mono-repos to give devs feedback within minutes after submitting a PR if their work will break a key feature elsewhere within that mono-repo. 

The latest builds triggered by merged PRs can be reviewed here

"QA Release": Updating the test3 environment with the latest build and selected work from dev3.

"Tags": Moment in time snapshot - what the repo looked like at a particular point in time (points to a particular commit at a particular time where we released something)

Manual last-pass through of O3 using the test3/QA Environment and checking for clinical or other concerns using the O3 Review Checklist

"RefApp Release": specifies the version of each . 

Each of these steps are explained further below. Full fancy diagram here of the O3 Release Pipeline. 

Step 1: QA Release

FIRST, obtain squad permission/buy-in to do a release (e.g. announce on #openmrs3). THEN, in 1 PR, 2 Commits are needed: (Example)

  • Step 1.1) Create Release PR:
    • TO ADD VERSIONING: Release Commit: (release) Create release commit for beta.9' This fixes the version numbers. Because we don't want the test3 version to be deployed on dev3 because that could undo more recent changes. So, in dev3, we ignore any release with the string '(release'
    • TO PROTECT DEV3: Release-Revert Commit: (release-revert) Reset to dev versions Second Commit with release revert message that unsets the fixed version numbers. 
    • Why: Ensures 'main' branch gets back to state where it is still pointing at 'next', to preserve the cutting-edge state of the dev3 environment. 
    • A GitHub Action is configured to execute comprehensive end-to-end tests on the release commit associated with the Pull Request. It is imperative to verify that all tests are successfully completed before merging the PR (learn more).
  • Step 1.2) Add Tags
    • Tag Release Commit with a tag named after the version number, as shown in the tag list screenshot here:
  • Step 1.3) QA Release then Happens Automatically
    • The Tag triggers the QA Release, AND the auto-rebuilding of Test3. In our Bamboo CI, the Deployment project called "Distribution 3.x Releases" is only triggered by tags. 
  • Step 1.4) Announce test3 release & version number to community in #openmrs.

Step 2: Manual Checks

  1. Confirm that tests are passing satisfactorily in Test3. Using the O3 QA Spreadsheet is highly recommended, in addition to checking the automated tests. Go through both the Baseline Checklist and any checks specific to that release - so that new features get some review.  
  2. Remember: Keep an eye out for manual work that could be automated - we want to maximize how we use Automation and reduce manual overhead over time. 

Step 3: RefApp Release

Go to the Deployment Project, "Deploy Reference Application 3.x"  (under the "Deploy" option in the menu)

  1. Click the cloud icon for the QA build:

  2. "Create new release" → Use the last successful build, and name the release one version number higher than the last one. When that build finishes, the new O3 RefApp release is automatically pushed to both our "production" environment in and the Docker containers are automatically updated. 
  3. Announce O3 Demo release & version number to community in #openmrs3 and on Talk. 

Note: You can see the history of releases here.