| Excerpt |
|---|
Description of the eHealth development and deployment cycle, including description of the use of eHealth environments and flow. |
...
Overview of build and deployment
Applications must be deployed using one of the predefined eHealth Helm chart and deployed in eHealth Service Mesh
Telemedicine Solutions provider must use the eHealth Infrastructure Deployment Pipeline for deploying to the eHealth environments.
- Telemedicine Solutions provider shall use officielt the official eHealth docker images and helm chart for application definition
Applications must be deployed using one of the predefined eHealth Helm chart and deployed in eHealth Service Mesh
...
- and development
- After local development, the Telemedicine Solutions Providers shall upload the docker images to Docker and Helm chart repository (Harbor)
- Telemedicine Solutions Providers uses GitLab to define the deployment file or "desired state file" based on Helmsman
- A configured Jenkins deployment pipeline monitors the Helmans file in GitLab and push updates to Kubernetes
- Kubernetes control loop watch the state of your cluster, then make or request changes where needed
The following figure illustrates the deployment pipeline.
...
Phase #1 Local development
All suppliers Telemedicine Solution Providers shall start development of their components in their own local environment.
...
Phase #2 Publish build to the eHealth-platform
When the Solution Providers supplier believes that the application / service / microservice is ready for testing it is published to the eHealth-platform.
...
- The docker image to run
- Docker repository
- Image tag
- The helm chart
- Helm chart repository
- Helm chart version
- Configuration
- Ports
- Replicas
- Memory usage
- Environment variables
- Database and queue secrets
- DNS bindings
- ectetc..
When the desired state specification is updated the applications and configuration is automatically rolled on to the environment.
Phase #4 Test and Promotion
...
Notice, every release must follow a strict release plan where eHealth environments are visited in the required order, that is deployed and tested on EXTTEST, before being promoted to PREPRODUCTION, and finally deployed to PRODUCTION.
External Test
Tests should be carried out on the inttest Test environment.
When the application has passed QA, it can be promoted to the next environment. This happens by a promotion of a specific desired state specification in Jenkins-test, by users with the right privileges.
...
In the second situation, where both liveness and readiness respond positive, the new pod will receive trafik. The one who started the deployment will look at cluster readout and decide a rollback. That person has to commit a new cluster configuration. This could be a reverse commit to the desired state file.
Note: if we are using Canary deployment, the negative impact of a software problem can be held at a minimum. That is if the negative impact can be found in prometheus.
Diagram of the flow
The flow can allows be viewed as follows.
- Application Vendor perform Local Development
- Application Vendor pust application and docker images to the FUT platform
- The eHealth infrastructure deploy to different environments, based on the Helmsman files provided by the application vendor.
- Application Vendor (or Customer) can test the Telemedicine solution on EXTTEST
- After successul tests, the build can then be promoted to next eHealth environment (PREPROCUTION).
- After successul tests, the build can then be promoted to eHealth PRODUCTION environment.
| Info |
|---|
In the figure is is shown as SRE Team (Software Reliable Engineering) must approve deployment to external test, pre-prod and production. This is not the case for external applications, furthermore, external applications do not have access to Internal Test (INTTEST), but has a special environment called DEVENVCGI, for internal test. |
