OpenHIE Sandbox Project

What is the OpenHIE sandbox?

The OpenHIE sandbox is a set of environments where all stages of development and testing can be seen.  Originally the sandbox was just a staging environment for internal testing and has expanded to 2 other environments as needed. Over time we would like to see our release process more automated.

Goals

• Recreate OpenHIE environment in Rwanda.
• Create a Web Demo for public use.
• Implement Continuous Integration for OpenHIE component interoperability
  • Nightly Builds
  • Automated tests
  • Statistics on code quality and coverage
  • Automated deployments

Environments

Development (Under development)

The dev environment of the sandbox is where automated builds are deployed.  The builds come from our CI server and are automatically deployed nightly.

Sandbox (staging)

The OpenHIE sandbox is the place to find all of the newest developments in the community.  This will serve as a place to experiment with new builds of software, new configurations and data. This is not stable and could change at any time. 

Demo (prod - hosted)

The OpenHIE demo site is a place to try out what the community has deemed as stable.  It is preloaded with data to demonstrate the basic features of the software recommended by each community. This will be reset each night to clear any changes made to the machines. 

Downloadable (prod - self hosted)

The downloadable release is a copy of the demo site made available for use on your local machine.  You will need virtualbox to run the images and meet the minimum hardware requirements to run all of the virtual machines at once for full functionality. With this you may make configuration changes suited to your environment and experiment with the software on your local machine. 

Lifecycle of Code?

Development Branch

1. Code is committed to a community repo.
2. Unit tests are run, if available.
3. Code is compiled / packaged and made into an artifact on CI.
4. Artifact is deployed to our dev environment.
5. Manual User Acceptance Testing occurs, testing for functionality and interoperability. Test interoperability against staging (which should mirror prod).

Release Branch

1. Code is tagged as release in code repository.
2. If it is determined that, it should not break anything deploy it to staging.
   
   1. If it will break interoperability, determine dependency and wait.
3. Run automated Integration Tests.
4. Allow users to perform User Acceptance Testing.
5. Note all versions as a Demo Release. (e.g. Demo v0.2.0 = OpenEMPI 3.0, OpenHIM 2.3, etc...) 
6. Rebuild demo and downloadable demo as new release.

Status

Sandbox/Staging

Demo

OpenHIE Demo