# CI/CD Strategie: Gitea Actions & ArgoCD

Diese Strategie trennt den **Build-Prozess** (CI) strikt vom **Deployment-Prozess** (CD).

## Der Workflow

1.  **Code Change (CI):**
    *   Du pushst Code in ein App-Repo (z.B. `stabify/whoami`).
    *   **Gitea Actions** springt an.
    *   Der Code wird getestet und ein Docker Image gebaut.
    *   Das Image wird in die Container Registry gepusht (z.B. `harbor.stabify.de/library/whoami:v1.0.1`).

2.  **Config Change (GitOps):**
    *   Um das neue Image zu deployen, änderst du den Tag im **GitOps Repo** (`stabify/gitops`).
    *   Datei: `apps/whoami/overlays/production/kustomization.yaml` -> `newTag: v1.0.1`.
    *   Du commitest und pushst diese Änderung.

3.  **Deployment (CD):**
    *   **ArgoCD** (läuft im Cluster) bemerkt den neuen Commit im GitOps Repo.
    *   ArgoCD vergleicht IST-Zustand (Cluster) mit SOLL-Zustand (Git).
    *   ArgoCD führt das Update durch (Rolling Update).

---

## Repository Struktur (Simuliert in diesem Ordner)

### 1. `repo-app-source`
Hier liegt der Quellcode deiner Anwendung.
*   Enthält den Source Code (Go, Node, Python...).
*   Enthält das `Dockerfile`.
*   Enthält die `.gitea/workflows/ci.yaml` Pipeline Definition.

### 2. `repo-gitops`
Hier liegt der Zustand deines Clusters.
*   **`bootstrap/`**: Der Einstiegspunkt für ArgoCD ("App of Apps").
*   **`cluster/production/`**: Definiert, WELCHE Apps auf dem Produktions-Cluster laufen sollen.
*   **`apps/`**: Enthält die eigentlichen K8s Manifeste (Deployments, Services, Ingress).
    *   Wir nutzen **Kustomize** (Base/Overlay Struktur).
    *   **Base**: Allgemeine Definition der App.
    *   **Overlay**: Umgebungsspezifische Anpassungen (z.B. Hostnames, Replicas, Image Tags für Prod).

## Vorteile dieser Struktur
*   **Sicherheit:** CI Server braucht keinen Cluster-Zugriff.
*   **Übersicht:** Das GitOps Repo ist die "Single Source of Truth".
*   **Wiederherstellbarkeit:** Cluster kaputt? Einfach ArgoCD installieren, auf das Repo zeigen, warten -> Fertig.