| Excerpt |
|---|
Description of the eHealth development and deployment cycle, including description of the use of eHealth environments and flow. |
| Table of Contents |
|---|
Development and deployment happens in four stepsphases.
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 ehealtheHealth-platform. But this is not a strict requirement.
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 ehealtheHealth-platform.
This means that the docker image is signed and pushed to the central docker image registry used and hosted by the ehealtheHealth-platform.
3. Deploy to test environment
...
When the desired state specification is updated the applications and configuration is automatically rolled on to the environment.
4. Test and Promotion
4.1 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.
4.2 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.
4.
...
3. Hot-fixing
If serious bugs or security errors is found in production code, or containers a hotfix can be handled in the following way.
4.
...
4. 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.
...
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
