Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Development and deployment happens in four steps.

1. Local development

All suppliers start development of their components in their own local environment.

This could be a complete clone of the officile test environments running on the ehealth-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 ehealth-platform.

This means that the docker image is pushed to the central docker image registry used and hosted by the ehealth-platform.

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.

All applications running on an environment is specified as code in the desired state specification for the given environment.

For each application this includes:

  • 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
    • ect..

When the desired state specification is updated the applications and configuration is automatically rolled on to the environment.

4. Test and Promotion

IntTest and ExtTest

Tests should be carried out on the inttest environment.

When the application has parsed QA, it can be promoted to the next environment. This happens by a promotion of a specific desired state specification in Jenkins, by users with the right privileges.

PreProd and Prod

Going onwards to preproduction happens by making a pull-request to the "prod" branch from the "master" branch.


When the pull-request is approved all updates in the desired state specification  for preprod is rolled on the preprod environment.

Deployment to production happens by a promotion of a specific desired state specification in Jenkins, by users with the right privileges.

4.1. Hot-fixing

If serious bugs or security errors is found in production code, or containers a hotfix can be handled in the following way.









  • No labels