Repo-Struktur

Zielgruppe: Anwender und Betreuer · Stand: 06.11.2026

Jeder DienstNomad-Job und jeder Infrastruktur-Stack bekommt ein eigenes Repository in der Gruppe seiner Abteilung. Nichts lebt nur lokal oder als UntermappeUnterordner in einem fremden Repo.

Regeln

• Ein Repo je Dienst bzw. Nomad-Job, z. B. container-platform-core-services/nomad-jobs/traefik-ingresspilot-graylog. Ein Job ist oft ein ganzer Stack aus mehreren Diensten: Er enthält dann mehrere Groups und darin mehrere Tasks. Zusammengehörige Dienste stehen deshalb als Groups und Tasks in einem Job, nicht in getrennten Repos. Diese Regel ist Good Practice und wird nicht technisch erzwungen. Wie ein Dienst auf Jobs und Repos aufgeteilt wird, entscheidet der jeweilige Software-Betreuer.
• Ein Repo je Infrastruktur-Stack (Terraform, Umgebung eines Standorts), z. B. cloud-core-infrastructure/bremen1/consul-servers.
• Lab-Repos tragen lab im Namen (z. B. bremen1/lab-edge-routers), deployen nur pre-development und promoten nicht.
• Wiederverwendbares gehört in Module (terraform-modules/…) bzw. Rollen (ansible/roles/…), nicht in Stacks.
• Default-Branch ist pre-development (Rollen: latest).

Konfiguration, die nur auf einem Rechner oder Server liegt, geht verloren. Auch Testkonfigurationen gehören in ein Repo.

Weiterführend

• Abteilungen, GitLab-Gruppen und Teams
• Rollen und Module versionieren