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.
