Preparing for MVP release of OCL for OpenMRS client


The OCL for OpenMRS Squad is working toward an MVP release of their OCL client. Having lost @karuhanga’s ability to actively contribute to the project, we’re trying to build the knowledge & capability to manage the CI/release process within the team.

Our assumption of environments:

  • QA code updated when commits made to master, data reset manually (if at all)
  • Staging gets manually promoted code & content in preparation for release to production
  • Production gets manually promoted code
  • Demo get manually promoted code (e.g., latest stable release) & data and accounts automatically reset daily

The questions we have:

  1. Are our assumptions of use of environments above correct and align with OCL’s use of them?

  2. Which environments get CIEL updates? Could we commit to updating all (QA, Staging, Prod, & Demo) within 24-48 hours of a new CIEL release?

@dkayiwa has graciously offered to help @kirity get up to speed on OCL’s CI environments and will likely be pinging you with more questions. :slight_smile:

/cc @dkayiwa @grace @paynejd


Looking over the CI configuration, at least code-wise it looks like most OCL projects are configured as expected to build & deploy automatically to QA after each commit with a deployment plan for manual promotion to staging, production, and demo environments.

The OCL Client (OCL for OpenMRS) plan, however, seems to be configured to automatically deploy to the demo environment for some reason. I’m guessing that this was done because demo had content that wasn’t available on QA at the time? In any case, it seems we should make sure code changes are being properly deployed to QA and that QA has the needed content for testing, then turn off the automatic deployment of code to the demo environment.

I still need to figure out how data (content & accounts) in QA and demo OCL environments are initialized/populated. I’m assuming there’s a dataset somewhere defining the default state for demo that is reset daily and would expect QA content to be manually managed. Still learning.


A little more investigation. It looks like demo data may be coming from what’s here.

1 Like

Based on settings in the oclapi-qa definition, it looks like QA is configured to import the demo data as well.

A few points:

  1. QA’s data is reset every commit.
  2. QA uses demo data from as you noticed
  3. DEMO environment uses a demo file mentioned in
  4. CIEL updates go to production and staging
  5. CIEL updates may go to demo occasionally, but it’s more time consuming (requires recreating demo data file)
1 Like