Deployment Pipeline

All client-side and server-side applications – including CDS Hooks services, FHIR resource servers and similar – MUST be built and delivered according to the HSP Marketplace specification such that they may be configured at runtime into the HL7 DaVinci Sandbox Architecture. The Service Packaging Requirements essentially boil down to using 12factor principles and eliminating local storage of any/all persistent data.

The HL7 DaVinci development team delivers automatically built images via the HSPC Docker Hub organization into public repositories corresponding to public GitHub repositories. Every project is built automatically by Docker Hub according to project-specific settings for branching strategy, testing etc. Upon successful builds, Docker Hub uses automated web hooks to notify HSPC's production container management of the new build becoming available, in turn triggering automated update of HSPCs cloud environment.

Continuous Deployment Stages

  1. Developer tests code and local images on local machine(s) according to DaVinci policies and procedures.
  2. Developer checks in and pushes code to corresponding branch of a DaVinci GitHub repository. (e.g. `git push`)
  3. Developer merges commits into the deployment branch, if necessary. (Most projects are just committing directly to master.)
  4. GitHub automatically notifies HSPC Docker Hub to trigger automated build process.
  5. Upon successful build and regression testing result, Docker Hub notifies HSPC container management to pull updated image and roll out to a swarm.

Technical Notes

No Sticky Sessions

Applications MUST NOT use sticky sessions, nor any form of 2nd-level caching requiring similar container affinity. HSPC's reverse proxy environment routes pseudo-randomly and has no mechanism for supporting these types of applications.

Data Persistence

All containers are assumed to be ephemeral unless you tell us otherwise. If you have persistence requirements – usually external database access or disk access – let us know so we can find a workable solution.

Swarm Updates

Auto-rollout of updates begins with container management instructing the sandbox server to download the appropriate image. Once downloaded, existing containers are killed at a 15s delay while updated containers are starting up. As services are configured in a swarm, and there may be more than one container running at any given time. During the short (usually <1m) rollout periods, both old and new instances will be responding to requests if the cardinality is greater than 1. 


Per the HSP Marketplace specification, all certificate management and SSL crypto is handled outside the image/container. HSPC's internal reverse proxy handles all cryptography and certificate management. Individual services are forwarded appropriate HTTP headers by the reverse proxy such that the base URL of the request in easily detectable by the application. Other than that, applications do not need to worry about SSL/TLS.