...
| Excerpt |
|---|
Description of the eHealth development and deployment cycle, including description of the use of eHealth environments and flow. |
| Table of Contents |
|---|
Overview of build and deploymentÂ
Telemedicine Solutions provider must use the eHealth Infrastructure Deployment Pipeline for deploying to the eHealth environments.
- Telemedicine Solutions provider shall use officielt 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
- Every release must follow a strict release plan where eHealth environments are visited in the required order.
The following figure illustrates the deployment pipeline.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Development and deployment happens in four phases.
...
Phase #1 Local development
All suppliers start 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 #2 Publish build to the eHealth-platform
When the supplier believes that the application / service / microservice is ready for testing it is published to the eHealth-platform.
This means that the docker image is signed and pushed to the central docker image registry used and hosted by the eHealth-platform.
...
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.
...
When the desired state specification is updated the applications and configuration is automatically rolled on to the environment.
...
Phase #4 Test and Promotion
...
IntTest and ExtTest
Tests should be carried out on the inttest 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.
...
PreProd and Prod
Going onwards to preprod happens by making a pull-request to the "prod" branch from the "master" branch.
...
Deployment to production happens by a promotion of a specific desired state specification in Jenkins-prod, by users with the right privileges.
...
Hot-fixing
If serious bugs or security errors is 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 situation manual intervention is necessary.
...