Update README.md

README.md

 # Deliverable: Projektkonzept
 
-## Infrastruktur
-
-Die Produktivumgebung des Webservice wird auf der Google Cloud Platform (GCP) gehostet:
-
-- **Details zur Infrastruktur**:
-
-  - **Maschinentyp**: e2-medium (2 vCPUs, 4 GB RAM)
-  - **Region**: Frankfurt
-  - **Betriebssystem**: Ubuntu 22.04
-  - **Festplatte**: 20 GB
-
-  - **Erweiterte Umgebung**:
-    - **Google Kubernetes Engine Cluster**: `devops24-autopilot-cluster`
-    - **Netzwerk**: `devops24-network`
-    - **Subnetz**: `devops24-subnetwork`
-    - **Kubernetes Deployment**: Deployment mit drei Replikaten
-    - **LoadBalancer-Service**: Zugang über IPv4 und IPv6
-    - **Ingress-Controller**: Nginx
-
 ## Technologiewahl
 
 - **Programmiersprache**: Go
@@ -35,10 +16,27 @@ Die Produktivumgebung des Webservice wird auf der Google Cloud Platform (GCP) ge
 - **Compute Engine**: Hostet VMs für Webservice und Redis-Datenbank
 - **Kubernetes Engine**: Autopilot-Cluster für Webservice und Ingress-Controller
 
-## Visuelle Hilfsmittel
+## Infrastruktur
 
-- **Architekturdiagramm**: Erstellung mit draw.io
-- TODO
+Die Produktivumgebung des Webservice wird auf der Google Cloud Platform (GCP) gehostet:
+
+- **Details zur Infrastruktur**:
+
+  - **Maschinentyp**: e2-medium (2 vCPUs, 4 GB RAM)
+  - **Region**: Frankfurt
+  - **Betriebssystem**: Ubuntu 22.04
+  - **Festplatte**: 20 GB
+
+- **Cluster Umgebung**:
+
+  - **Google Kubernetes Engine Cluster**: `devops24-autopilot-cluster`
+  - **Netzwerk**: `devops24-network`
+  - **Subnetz**: `devops24-subnetwork`
+  - **Kubernetes Deployment**: Deployment mit drei Replikaten
+  - **LoadBalancer-Service**: Zugang über IPv4 und IPv6
+  - **Ingress-Controller**: Nginx
+
+- **Datenbank**: Für die Persistenz wird Redis verwendet, welches in einer separaten Compute Engine-Instanz innerhalb der GCP-Umgebung betrieben wird.
 
 ### CI/CD Pipeline
 
@@ -46,17 +44,14 @@ Die Konfiguration für den Build des Webservices erfolgt in der GitLab CI/CD-Pip
 
 - **Test**: Durchführung von Tests mit dem Docker-Image `golang:1.21`
 - **Build**: Erstellung des Webservice-Binaries für `linux_amd64` und Speicherung der Artefakte in der Package Registry
-- **Publish**: Veröffentlichung des Docker-Containers in der Container Registry mit Versionierung auf der Basis der Pipeline-ID und des `latest` Tags
-
-## Persistenzschicht (Datenbank)
-
-Für die Persistenz wird Redis verwendet, das in einer separaten Compute Engine-Instanz innerhalb der GCP-Umgebung betrieben wird.
+- **Publish**: Veröffentlichung des Docker-Images in der Container Registry mit Versionierung auf der Basis der Pipeline-ID
 
 ## Lifecycle
 
-- **DEV**: Commits auf den `dev`-Branch lösen den Build eines Containers aus, der lokal mit Podman ausgeführt und getestet werden kann.
-- **FEATURES: Feature to Prod**: Feature-Branches werden in den Main-Branch gemerged und schließlich in die Test- und zuletzt in die Produktionsumgebung überführt.
-- **Pipeline Trigger**: Die Pipeline wird durch Merge-Requests oder Pushes auf den Branches `main`, `dev` oder `prod` aktiviert.
+![Lifecycle](Lifecycle.png)
+
+- **Pipeline Trigger**: Die Pipeline wird durch Merge-Requests oder Pushes auf den Branches `main`, `dev` oder `prod` getriggert. Nach einem erfolgreichen Durchlauf der Pipeline wird ein Container-Image als Artefakt erstellt.
+- **Artifakte**: Ein Commit auf den `dev`-Branch erzeugt ein mit `dev` getaggtes Artefakt, das für Tests in der Entwicklungsumgebung verwendet wird. Diese Tests erfolgen durch lokale Ausführung mittels Podman. Wenn alles in Ordnung ist, kann ein Commit auf den `prod`-Branch den Build eines Container-Images auslösen. Dieses wird anschließend von Kubernetes im Google Cloud Cluster anhand des `prod`-Tags erkannt und in Pods ausgeführt.
 
 ## Weitere Konfigurationen