As the OpenMRS 3.0 Framework is beginning to get piloted and we expect adoption only to grow, we need to migrate from an ad hoc deployment at openmrs-spa.org to a more automated CI-based process that can be hosted within the OpenMRS infrastructure (e.g., something like qa3.openmrs.org, staging3.openmrs.org, demo3.openmrs.org).
Adapting the proposed RefApp 3.x folder layout to define everything needed to deploy an instance of the current version of OpenMRS 3 (running at openmrs-spa.org) would be a great start and would have some immediate benefits:
- Provide the recipe for automated CI builds so we can have qa, staging, and demo environments for OpenMRS 3.0 work
- Harden our convention for defining deployments (both for OpenMRS 2.x & 3.x)
- Make it easier for people to try out OpenMRS 3.0 for themselves (either through a hosted environment or by deploying locally)
Some of the pieces I think we need are:
- Pulling settings (host location, port, etc.) into environment variables
- A repo for OpenMRS 3.0 Framework with GitHub action(s) to build docker containers and deploy them to OpenMRS on Docker Hub
- ansible-docker-compose file(s) that define the hosted environments for our infrastructure
- CI plans to deploy those environments
I assume micro frontends (with its myriad of esm modules) would be similar to the RefApp (with its myriad of OpenMRS modules) – i.e., changes to individual esm repos wouldn’t trigger a new deployment to qa; rather, a commit to the OpenMRS 3.x repository (like a change to its import map configuration) would trigger a new build & deployment. Then CI could be used to manually promote any one of those builds to staging/demo sites.
I know there are more pieces, but I wanted to get the conversation started here. Thoughts about other steps/pieces we’ll need?