| Excerpt |
|---|
Description of the eHealth development and deployment cycle, including description of the use of eHealth environments and flow. |
...
Telemedicine Solutions provider shall use the official eHealth docker images and helm chart for application definition and development
After local development, the Telemedicine Solutions Providers shall upload the docker images to the Docker and Helm chart repository (Harbor)
Telemedicine Solutions Providers use 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 pushes updates to Kubernetes
The Jenkins deployment pipeline is configured by the eHealth Infrastructure provider.
Kubernetes control loop watches the state of your cluster, then makes or requests changes where needed
The following figure illustrates the deployment pipeline.
...
All Telemedicine Solution Providers shall start the development of their components in their own local environment.
This could be a complete clone of the official test environments running on the eHealth platform. But this is not a strict requirement.
...
Phase #3 Deploy to test environment
To actually deploy the docker image as a container on the first test environment, the image needs to be added to the helmsman specification file for the given environment.
...
Phase #4 Test and Promotion
Notice, that every release must follow a strict release plan where eHealth environments are visited in the required order, which is deployed and tested on EXTTEST, before being promoted to PREPRODUCTION, and finally deployed to PRODUCTION.
...
If serious bugs or security errors are found in production code, or containers a hotfix can be handled in the following way.
...
Rollback
Rollback is handled somewhat semi-automatic, if the problem is visible through the pod probe services' liveness and readiness. In other rollback situations manual intervention is necessary.
...
Application Vendor performs Local Development
Application Vendor pust application and docker images to the FUT platform
The eHealth infrastructure deploys 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 successful tests, the build can then be promoted to the next eHealth environment (PREPROCUTION).
After successful tests, the build can then be promoted to the 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 Environment (INTTEST), but has a special development environment called DEVENVCGI, for their internal test. |
...