deployment-process

Deployment-Prozess

Diese Seite beschreibt den allgemeinen Deployment-Prozess für das Projektteam auf hoher Ebene.
Im Mittelpunkt steht die Trennung zwischen den Service-Repositories, dem zentralen sdk-config-Repository und Flux als GitOps-Mechanismus im Cluster.
CI/CD stellt dabei zunächst nur die Auslieferungsartefakte bereit, also Docker-Image und Helm-Chart. Das eigentliche Deployment entsteht erst danach, wenn Flux die im sdk-config-Repository definierte Zielkonfiguration auswertet und im Cluster umsetzt.

Überblick

Der allgemeine Merge-Weg ist feature -> develop -> main.
Entwickelt wird in einem Feature-Branch, anschließend wird nach develop integriert und nach Freigabe weiter nach main.
Auf beiden Ziel-Branches laufen im jeweiligen Service-Repository CI und CD an, damit das Docker-Image und das Helm-Chart als Artefakte bereitstehen.
Ob daraus direkt ein Deployment entsteht, entscheidet nicht die Pipeline selbst, sondern die von Flux beobachtete Deployment-Konfiguration.

Komponenten und Verantwortlichkeiten

• Service-Repository: enthält den Quellcode des Services, die Pipeline-Definitionen, die Docker-Image-Erzeugung und das Helm-Chart für diesen Service.
• sdk-config-Repository: enthält die Konfiguration des Helm-Releases beziehungsweise die Deployment-Konfiguration, die Flux auswertet.
• Flux: überwacht die Konfiguration im sdk-config-Repository und setzt die gewünschte Version im Cluster um.
• CI/CD im Service-Repository: baut nach einem Merge nach develop oder main die Auslieferungsartefakte und stellt sie bereit.
• Branch-Modell: beschreibt den allgemeinen Integrationsweg von feature über develop nach main; main steht dabei für den freigegebenen Stand.

Gesamtprozess

@startuml
title Allgemeiner DevOps-/GitOps-Deployment-Prozess
 
start
partition "Service-Repository" {
  :Entwicklung im Feature-Branch;
  :Merge `feature` -> `develop`;
  :CI baut das Docker-Image;
  :CD erstellt das Helm-Chart-Artefakt;
}
 
if (Zielpfad?) then (develop)
  partition "sdk-config-Repository" {
    :Merge Feature-Branch -> `develop` nach Freigabe;
    :ImageUpdateAutomation aktualisiert\nautomatisch die Dev-Konfiguration;
  }
  partition "Flux" {
    :Flux beobachtet die Dev-Konfiguration\nim `sdk-config`-Repository;
    :Flux rollt die neue Version in Dev aus;
  }
else (main)
  partition "Service-Repository" {
    :Merge `develop` -> `main` nach Freigabe;
    :CI baut das Docker-Image für den freigegebenen Stand;
    :CD erstellt das Helm-Chart-Artefakt für den freigegebenen Stand;
  }
  partition "sdk-config-Repository" {
    :Die freizugebende Image-Version wird\nbewusst manuell angepasst;
  }
  partition "Flux" {
    :Flux beobachtet die Produktionskonfiguration\nim `sdk-config`-Repository;
    :Flux setzt die freigegebene Version in Prod um;
  }
endif
 
stop
@enduml

Verhalten auf develop

Nach dem Merge nach develop starten im Service-Repository CI und CD.
Die CI erzeugt das Docker-Image mit neuem Tag, die CD stellt das passende Helm-Chart-Artefakt bereit.
Anschließend aktualisiert die Flux-ImageUpdateAutomation die Dev-Konfiguration im sdk-config-Repository automatisch.
Flux überwacht diese Konfiguration und setzt die neue Version ohne manuelle Freigabe im Dev-Cluster um.

Verhalten auf main

Nach dem Merge nach main starten im Service-Repository ebenfalls CI und CD.
Auch hier werden Docker-Image und Helm-Chart als Auslieferungsartefakte bereitgestellt.
Im Unterschied zu develop erfolgt jedoch keine automatische Produktionsaktualisierung.
Die freizugebende Image-Version wird im sdk-config-Repository bewusst manuell angepasst und freigegeben.
Erst danach übernimmt Flux die beobachtete Konfiguration und setzt die freigegebene Version im Produktions-Cluster um.

Warum die Trennung sinnvoll ist

Die Trennung sorgt dafür, dass Quellcode, Build-Artefakte und Deploy-Konfiguration nicht in einem einzigen Schritt vermischt werden.
Das Service-Repository bleibt für Entwicklung und Auslieferungsartefakte zuständig, während das sdk-config-Repository die gewünschte Zielkonfiguration für Flux hält.
Dadurch wird klar, wer was ändert, und Flux kann ausschließlich die freigegebene Git-Konfiguration in den Cluster übertragen.
Für das Team macht das Freigaben nachvollziehbar, reduziert unbeabsichtigte Produktionsänderungen und hält Dev und Prod bewusst auseinander.