OpenMRS Test environments

Continuing the discussion from qa-refapp not inline with RA 2.6:

That was a really good question, @mogoodrich. I created . I suppose @burke can update that helpdesk article (which I didn’t even realise before) and point to the wiki page, it will be much easier to update.

So asking for everyone mentioned there, @raff, @darius, @wyclif, @maurya and @dkayiwa, can you please update that page with the purpose of each environment, if there’s someone responsible for it?

  • Can I destroy dev01 and dev02 machines?
  • Can I move uat-refapp to docker, just like I did qa-refapp?
  • What needs to be done to dockerise dev00/msbuilder?
  • Is there any plans to create a docker image for the platform from the SDK (just like the one for refapp)?

We used to run automated tests on devtest01, but we now run them on a server on travis-ci. Devtest02 used to be what qa-refapp is now.

I think both machines can be destroyed.

It would be great! Can you make it so that it deploys the uat branch instead of master?

It’s running a platform. Before each RA release we need load a sql with the CIEL concept dictionary on that instance. Also we need to take backups of the db. Let me try to create a docker config, which could be used for that machine.

It’s already possible. You can run openmrs-sdk:build-distro from I have configured CI to build different versions of platform at We just need an extra publish docker image step I guess.

Well, yes, can. The problem is that today the refapp distro build is all based on master, and running another branch would have undesired effects (like the deploy of snapshot, deploy to the manual server, and so on). Instead of having a branch build, I’d rather have another build for UAT. Is there any reason why we’d have a different branch for UAT? Note that the UAT server would use the ‘uat’ docker tag, so it wouldn’t be affected by other deployments.

I see. Because it’s platform (and because it has state), I don’t want to mix with the others, then. No need to hurry with the docker image, I’m not going to be deploying it any time soon :slight_smile:

Awesome! I will play with it later. We just have uat-platform and int-platform. Does it make sense to have qa-platform and uat-plataform only? Do we want to deploy master or maybe different platform versions?

As long as there is an easy way to deploy a specific build of RA to UAT I’m cool with that.

If you want to deploy any build to UAT, it should be fine. Just create a deployment in Bamboo, and it should work :smiley:

The only two refapp environments which are not dockerised yet would be dev03 and dev04, but I don’t want to touch them right now :slight_smile:

I will create another ticket for the platform ones.

Done. I’ve not been a fan of creating more places for content anyway. The old help desk page now directs people to the wiki page.

I adapted some text from the old Test Servers page and added into a “Developer Test Environment” section.

@cintiadr – it would be nice to have a “pool” of up to 6 devtest instances that we host for developers doing sprints or spikes to demonstrate their work & get feedback. ITSM-4003 (a demo environment for the Andela sprints on Cohort Builder Enhancements is an example). Something like:

  1. Developer requests a devtest environment for a sprint or spike including their contact info, purpose, the build needed (Platform or RefApp & version), TTL in days or weeks, and their public certificate.
  2. We use the information provided to create a document for terrraform to automagically deploy their devtest environment during the specified date range. The developer is responsible for maintaining the environment during that time. Ideally, we’d give them a (semi-)automated way to refresh (re-deploy) or release (delete early) the devtest environment.

We still have a couple devtest environments lingering without a clear TTL.

@darius – can we delete devtest03?

@raff – can we delete devtest04?

Thanks :slight_smile: Based on the amount of resources we were using, I decided to start tackling the ‘long-lived’ environments first, and leave the devtest ones for later.

The easiest way (by far) for me would be using docker. Let’s assume I have one docker host for devtest machines. Someone willing to have an openmrs instance would need to follow . From there, any docker tag pushed is automatically deployed (no CI involved).

That simplifies the problem immensely to me, because there’s no users, no tomcat version, no mysql, and it’s a single machine to take care with ansible/firewall/security patches or anything. Even the time to provision a new instance is much smaller.

Would it be too much to ask for docker in this case?

That’s fine; however, it would be nice not to expect developers to publish their own docker image.

Assuming a developer has a good case for a devtest image*:

  • In most cases, they’d want a specific version of Platform or RefApp, in which case we’d use community-managed Docker image – i.e., we’d add an entry to terraform config that included owner, purpose, date range, and Docker images to use.

  • In advanced cases, they could publish a Docker image and we could point terraform to that instead.

I’m guessing it’ll take more than just a single image. More like a docker-compose containing at least application image & database image.

*I’m picturing Developer Test Environments primarily for community sprints & demos. Devs who just want a hosted instance of OpenMRS to play with or demo for personal or non-community needs (this would include most GSoC projects) can be encouraged to host themselves via DigitalOcean/AWS/etc.

Devtest03 is serving as our demo of OpenMRS Ebola. I’d like to keep this demo alive for the foreseeable future, though I’m fine moving it to a non devtest server. That hasn’t seemed like a priority so far.

(If we’re somehow resource constrained then I can talk with Jonathan and Hamish about us paying for a digitalocean server or something. But we have just submitted a paper that refers to the demo server, via short link, so we definitely want to keep it alive.)

-Darius (by phone)

Just to follow up: I created for that.

While terraform has a docker provider, I think in our case it’s just simpler to use ansible (, because one can run it locally with docker-compose :slight_smile: