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:
Are our assumptions of use of environments above correct and align with OCL’s use of them?
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.
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.
