Merge branch 'staging' into 'main'

Main update

See merge request !62

README.md

 SS22-DevOps-Deployable
 =============================
 
-### Introduction 
+# Introduction 
 
 This repository demonstrates the automated deployment of a simple web application. It consists of two branches - **staging** and **main**.
 These branches are protected, meaning that commits targetting them will fail.
 Changes to the codebase are realized through the use of other temporary branches and Merge Requests to **staging**. Merge Requests to **main** should
 only be opened from **staging** as a source branch.
 
-As soon as a new change through a MR is commited to **staging**, a pipeline is triggered. It deploys the application to the **staging-todoapp-devops** namespace in a Kubernetes cluster, run on GKE. After that, the application is accessible on the URL:
+As soon as a new change through a MR is commited to **staging**, the [pipeline](.gitlab-ci.yml) is triggered. It deploys the application to the **staging-todoapp-devops** namespace in a Kubernetes cluster, run on GKE. After that, the application is accessible in its test/pre-production version under the domain:
 
-> https://staging.todoapp-devops.software
+> staging.todoapp-devops.software
 
-The same process happens with commits (merged from **staging**) on the **main** branch. The web application is then accessible on:
+An equivalent process follows commits (merged from **staging**) on the **main** branch. Upon a successful app build, the container image name is adjusted and a new version tag is pushed to the repository. After that, the app is deployed on GKE.
+The web application is then accessible in its production version under:
+
+> todoapp-devops.software
+
+## Manual jobs
+
+The pipeline job `switch-to-https` should be manually triggered, after the app has been deployed. Due to Google's requirements, this process can only be triggered manually after the Google-managed Load Balancer is set up correctly and is operational.
 
-> https://todoapp-devops.software