Dockerizing development and deployment of OpenMRS

,

@raff,

Could you share update on where things stand?

From our recent discussion on a Platform call, I believe the consensus was to have:

  • Last commit building to a “snapshot” tag (or “head” or whatever is the most intuitive and/or common practice as a stable tag for last commit)
  • Run smoke tests and only deploy to dev if smoke tests pass.
  • Run all tests and only tag as official version (e.g., “dev”) if they pass

This way, devs could develop against snapshot images if they wish, the dev site doesn’t crash because tests have to pass before it gets deployed, and people creating their own modules/apps can use dev images to work against newest changes without worrying about whether or not the image is going to load or run.

Our first goal is to get to the 3.0 build process not only Dockerized, but popularized enough to avoid challenges like in this thread.

What do you think about trying out Bamboo Specs for the 3.0 builds – i.e., specifying the CI build pipeline in YAML files in a GitHub repo? @mseaton has been trying this out for PIH with some success. It seems like it could not only help coordinate changes to our plans, but also serve to make the 3.0 build process easier for everyone to see.

Our second goal is to leverage the build process not only to reliably deploy OpenMRS 3.0 for our dev site and development workflows, but use it to deploy OpenMRS 3.0 with OHRI functionality.

Finally, what’s the best way to know your OpenMRS vs. OCL week? I think if we could get you regularly on the Platform (Wed, 5p UTC) call – or, if that doesn’t work for you, then the TAC (Mon, 4p UTC) call – it could help us coordinate efforts.

2 Likes