# AnyWay backend deployment

The backend is a containerized fastapi application built in [https://git.kluster.moll.re/anydev/anyway](https://git.kluster.moll.re/anydev/anyway). The container is deployed along some helper services on our own kubernetes cluster.


## Overview
The deployment comes in two flavors - `staging` and `production`. The setup is straightforward and mostly identical between the two environments: most configuration lies in the `base/` folder and only the environment-specific adjustments are in the `overlays/` folders.

The deployment is in principle fully functional as-is, but the main benefits - automatic deployment, provisioning and updates - are only available when levering argoCD. In the recommended setup, the manifests are never applied manually, but are instead referenced in the [app of apps](https://git.kluster.moll.re/anydev/anydev-app-of-apps). This handles both the deployment of a stable `production` version and the automatic deployment of `staging` versions for each pull request.


## Cluster requirements

For the deployment of the **backend** application, the following prerequisites need to be met on the kubernetes cluster:
- ingress controller (assumed to be `traefik` in the manifests but easily adaptable)
- a storage class (assumed to be `nfs-client` in the manifests but easily adaptable)
- argoCD (for automatic deployment)
- (upcoming) sealed secrets controller (for managing secrets)


## Deployments
The deployment is done to two environments:


### Production
Only tagged builds from the `main` branch are deployed to the production environment. This is the live environment that is used by the users. The main branch is protected and can only be merged to through pull requests. This is handled as a simple argoCD application that points to the `overlays/production` folder which references the latest `semver` tagged version of the backend.


### Staging
All builds from forks and pull requests are deployed to a seperate namespace. The crucial part is that this is handled as an argoCD `applicationSet` that automatically creates a new application for each pull request, adding a further modification to the `overlays/staging` patches. This way, each pull request gets its own isolated deployment that can be tested and validated before merging to main. The staging deployments are automatically removed when the pull request is closed.