# Deployment process

This document shall provide the definition of the deployment process.

## Prerequisites:
### Customer repositories
The FHIR Team creates repositories that customers have access to. It shall always contain a working exemplary `docker-compose` configuration.
On every change, a new release of this shall be created.

The Customer is subscribed on releases on their github repository.

### Documentation
When creating the release, the documentation is updated to reflect all new changes.
It contains an exemplary configuration and an explanation for the configuration options.

## General workflow
### Step `Meeting`
The FHIR Team comes together and goes through its repositories.

If a repository has changes to be released, the Person having last merged into develop is designated the `repo-person`.

The `repo-person` is responsible for releasing the new version of that component.
Once all repositories are covered, the Team designates one `dc-person` per customer.
The `dc-person` is responsible for getting the docker stack to work.

### Step `Release`
The designated `repo-person` updates the documentation in the `Readme.md` to reflect additions, changes, fixes and new features.
The documentation must contain a working exemplary configuration and a short description of the configuration sections.

Once the documentation is merged, `repo-person` creates a release. If the release process is automated, `repo-person` makes sure
that everything went right. (e.g. tag is not created on a commit with `[skip ci]`, the image is on dockerhub, etc.)

Once the release is ready, `repo-person` notifies the `dc-person`.

### Step `docker preparation`
The `dc-person` updates the version numbers and necessary configurations.
Then `dc-person` runs the stack locally and tests each route with one file. (We hopefully tested the components beforehand, so this is just to make sure, everything works together as expected).

If unexpected errors occur: go to Step `Errorhandling`.

Otherwise proceed with Step `Portainer deployment`.

### Step `Portainer deployment`
The `dc-person` adapts the previously tested docker configuration to work with portainer and updates the `{customer-team-fhir-stack}`.
Then each route has to be tested with one file.

### Step `Delivery`
The `dc-person` creates a new branch in the customer repository. Once all necessary changes are in it, `dc-person` merges it back to `develop`
and from there to `main`.
Then `dc-person` creates a new release from `main`.
The customer will be notified through the github bot.

### Step `Errorhandling`
In case of errors while testing the routes, the `dc-person` contacts the `repo-person` for the repository causing the error.
If the error can be fixed before the work-day of `dc-person`ends, `repo-person` fixes the error and goes back to Step `Release`.

If the error can't be located or it can't be fixed in the same day, the FHIR team gets together again to make a decision:
- Release the component with its error?
- Release everything but the component?
- Do not release at all?

If the decision is to release the component with its error, `dc-person` proceeds with Step `Portainer deployment`.

If the decision is to release everything but the component, `dc-person` rolls back changes in the docker configuration.

If the decision is to not release at all the Team needs to come together and evaluate what went wrong and how to avoid that.
The customer should be notified about not releasing.

## What to change:
- Run stack -> run stack locally
- feature wise process
- story is finished -> create stack with the feature in it