Skip to content

Latest commit

 

History

History
47 lines (32 loc) · 4.41 KB

deployment.md

File metadata and controls

47 lines (32 loc) · 4.41 KB

back

Deployment

Operation Environments

Here is an overview of the operation environments the Evento Portal will be deployed to and their corresponding Git branches:

Environment Platform Git Branch Purpose Url Status
Development Netlify main Review latest changes during development https://evtapp.netlify.app/ Netlify Status
Test Bedag (Kubernetes) test
(or hotfix-*)
Test on environment close to production before releasing https://evt-test.apps.be.ch/
Production Bedag (Kubernetes) production
(or hotfix-*)
"Live" version used by the users https://evt.apps.be.ch/

Releasing & Image Building

See Git Workflow for the general branching concept and workflow.

Development Environment

  • The latest commit from the main branch will be automatically deployed to a development environment on Netlify (on push), based on the testBuildEnv.yml GitHub Actions workflow.
  • The workflow builds a ZIP & uploads it to GitHub Pages.
  • The deployment itself is controlled by Netlify and has been configured by BKD.

Test Environment

  • To release & deploy to the test environment, BKD manually dispatches the container-build.yml workflow (see Release Instructions).
  • The workflow merges the main branch into the test branch.
  • It builds a Docker image (see Dockerfile) and pushes that image to the GitHub Docker registry (see evento-portal packages).
  • The Docker image will be tagged with the test tag and an automatically incremented version tag (e.g. 1.3.0). The Git commit will also be tagged with this version tag (e.g. v1.3.0).
  • In a GitOps manner, the Bedag cluster will then deploy the test Image to the test environment.

Production Environment

  • To release & deploy to the production environment, BKD manually dispatches the container-build.yml workflow (see Release Instructions).
  • The workflow merges the test branch into the production branch.
  • It can usually reuse the Docker image already built for this commit and will tag it with the production tag.
  • In a GitOps manner, the Bedag cluster will then deploy the production Image to the production environment.

Hotfix

A hotfix is necessary if a critical problem occurs in production that needs to be fixed at short notice, but in the meantime further changes have already been made on the main branch that should not yet be deployed.

  • To release & deploy a hotfix to the production environment, BKD manually dispatches the hotfix-container-build.yml workflow (see Release Instructions).
  • The workflow merges the hotfix branch into the production branch.
  • It builds a Docker image and will tag it with the hotfix tag and the automatically incremented version tag. Note: The version for hotfixes will be incremented on the patch level. If you create a hotfix from 1.3.0, the first hotfix build will receive the version 1.3.1.
  • Bedag has to advise the deployment for the production environment to pull the image with the hotfix tag.