Plattform, Pipeline und Deployment-Strategie als ein System

Sie haben Ihre Teams organisiert. Sie wissen, wer was baut, wer Änderungen reviewed und wer sich um Produktionsvorfälle kümmert. Aber wenn jemand fragt: „Wo läuft das eigentlich?“ oder „Wie gelangt Code von einem Pull-Request zu einem laufenden Service?“, werden die Antworten vage.

Hier scheitern die meisten Delivery-Initiativen. Teams beginnen, Tools auszuwählen, YAML-Dateien zu schreiben und zwischen Blue-Green- und Canary-Deployments zu entscheiden, ohne die Verbindungen zwischen Infrastruktur, Automatisierung und Release-Mechanismen herzustellen. Das Ergebnis ist ein fragmentiertes System, in dem die Plattform gegen die Pipeline kämpft und die Deployment-Strategie gegen beide arbeitet.

Warum Plattform-Engineering an erster Stelle kommt

Stellen Sie sich ein Team vor, das einen neuen Microservice deployen muss. Ohne eine gemeinsame Plattform provisioniert es manuell eine virtuelle Maschine, installiert Abhängigkeiten von Hand und konfiguriert das Netzwerk über ein Ticketsystem. Ein anderes Team macht dasselbe anders. Sechs Monate später verwendet eine Umgebung Ubuntu 20.04, eine andere 22.04. Ein Team speichert Logs lokal, ein anderes streamt sie an einen zentralen Dienst. Wenn ein Vorfall passiert, weiß niemand, welche Umgebung sich wie die Produktion verhält.

Plattform-Engineering löst dies, indem es eine konsistente Grundlage bereitstellt. Es beantwortet die Frage: Wie erhalten Teams Umgebungen, ohne jedes Mal alles von Grund auf neu aufbauen zu müssen? Die Plattform kann ein Kubernetes-Cluster mit standardisierten Ressourcenvorlagen sein, ein Satz von Terraform-Modulen, die jedes Team verwendet, oder eine verwaltete Service-Ebene, die Infrastrukturdetails vollständig abstrahiert.

Der Schlüssel ist Konsistenz. Wenn jedes Team auf derselben Grundlage deployed, schrumpfen die Unterschiede zwischen den Umgebungen. Die Staging-Umgebung verhält sich wie die Produktion, weil beide auf derselben Plattform laufen. Probleme, die beim Testen auftauchen, sind dieselben Probleme, die in der Produktion auftauchen – nicht neue, die durch Konfigurationsdrift verursacht werden.

Ein gemeinsames Terraform-Modul macht diese Konsistenz wiederholbar:

# modules/team-namespace/main.tf
resource "kubernetes_namespace" "team" {
  metadata {
    name = var.team_name
    labels = {
      team    = var.team_name
      env     = var.environment
      managed = "platform"
    }
  }
}

resource "kubernetes_resource_quota" "limits" {
  metadata {
    name      = "${var.team_name}-quota"
    namespace = kubernetes_namespace.team.metadata[0].name
  }
  spec {
    hard = {
      pods                = var.max_pods
      requests.cpu        = var.max_cpu
      requests.memory     = var.max_memory
      limits.cpu          = var.max_cpu
      limits.memory       = var.max_memory
      persistentvolumeclaims = var.max_pvcs
    }
  }
}

Jedes Team ruft dieses Modul mit seinen eigenen Variablen auf, aber die zugrunde liegenden Ressourcendefinitionen bleiben identisch.

Pipeline als das Rückgrat der Auslieferung

Eine CI/CD-Pipeline ist mehr als eine Abfolge automatisierter Schritte. Sie ist der Pfad, der den von Entwicklern geschriebenen Code mit der Umgebung verbindet, in der Benutzer mit der Anwendung interagieren. Jede Stufe in der Pipeline – Build, Unit-Test, Integrationstest, Security-Scan, Deploy – repräsentiert einen Schritt im Wertstrom, der Änderungen zu den Benutzern bringt.

Ohne eine Pipeline geschehen diese Schritte manuell. Jemand baut das Artefakt auf seinem Laptop. Jemand anders kopiert es auf einen Server. Eine dritte Person führt Tests von Hand durch. Jeder manuelle Schritt führt zu Verzögerungen und Risiken. Eine vergessene Abhängigkeit, eine andere Betriebssystemversion oder ein übersprungener Test können Fehler verursachen, die erst nach dem Deployment auftauchen.

Eine gut entworfene Pipeline erzwingt bei jeder Änderung dieselben Prüfungen. Jeder Pull-Request löst denselben Build-Prozess aus, führt dieselben Tests durch und durchläuft dieselben Verifikations-Gates. Teams können darauf vertrauen, dass eine grüne Pipeline bedeutet, dass die Änderung alle relevanten Prüfungen bestanden hat. Dieses Vertrauen ist es, das häufige Deployments sicher macht.

Deployment-Strategie dreht sich um Benutzer, nicht um Technologie

Wenn über Deployment-Strategien gesprochen wird, liegt der Fokus oft auf technischen Mustern: Blue-Green, Canary, Rolling Update, Feature Flags. Das sind Implementierungsdetails. Die eigentliche Frage ist: Wie liefern Sie Änderungen aus, ohne Benutzer zu stören?

Die Antwort hängt von den Eigenschaften Ihrer Anwendung ab. Ein öffentlich zugänglicher Webdienst mit Millionen von Benutzern benötigt möglicherweise ein Canary-Release, das ein Prozent des Datenverkehrs an die neue Version weiterleitet und dann den Prozentsatz schrittweise erhöht, während die Fehlerraten überwacht werden. Ein internes Tool, das von zwanzig Personen genutzt wird, kommt möglicherweise mit einem einfachen Rolling Update aus, das Instanzen nacheinander ersetzt.

Datenbank-Deployments fügen eine weitere Komplexitätsebene hinzu. Eine Schema-Migration, die eine Spalte hinzufügt, kann sicher zusammen mit dem alten Code ausgeführt werden. Eine Migration, die eine Spalte umbenennt oder ihren Typ ändert, erfordert eine sorgfältige Koordination zwischen den Anwendungsversionen. Die Deployment-Strategie muss diese Einschränkungen berücksichtigen, nicht nur den Anwendungscode.

Die Rollback-Fähigkeit ist ebenfalls Teil der Strategie. Wenn etwas schiefgeht, wie schnell können Sie zur vorherigen Version zurückkehren? Können Sie die Anwendung unabhängig von der Datenbank zurücksetzen? Unterstützt die Plattform ein sofortiges Rollback, oder müssen Sie neu bauen und neu deployen? Diese Fragen sollten vor dem ersten Produktions-Deployment beantwortet werden, nicht während eines Vorfalls.

Die drei Ebenen müssen gemeinsam entworfen werden

Plattform, Pipeline und Deployment-Strategie sind keine unabhängigen Entscheidungen. Sie bilden ein System, in dem jede Ebene die anderen einschränkt und ermöglicht.

Das folgende Diagramm zeigt, wie jede Ebene von den anderen abhängt und sie einschränkt.

Die Plattform bestimmt, was die Pipeline tun kann. Wenn die Plattform keine Blue-Green-Deployments mit Traffic-Switching unterstützt, kann die Pipeline diese Strategie nicht umsetzen. Wenn der Plattform ein Rollback-Mechanismus fehlt, kann sich die Deployment-Strategie nicht auf eine schnelle Wiederherstellung verlassen.

Die Pipeline bestimmt, wie die Deployment-Strategie ausgeführt wird. Wenn die Pipeline keine Verifikationsstufe enthält, die Integrationstests gegen die Staging-Umgebung ausführt, hat ein Canary-Release keinen aussagekräftigen Health-Check. Wenn die Pipeline die Validierung von Datenbank-Migrationen überspringt, kann die Deployment-Strategie Schemaänderungen nicht sicher handhaben.

Die Deployment-Strategie bestimmt, was die Plattform unterstützen muss. Wenn die Strategie ein sofortiges Rollback erfordert, muss die Plattform die vorherige Version am Laufen halten und den Datenverkehr sofort umschalten können. Wenn die Strategie Feature Flags verwendet, muss die Plattform Laufzeit-Konfigurationsänderungen ohne erneutes Deployment unterstützen.

Wenn diese drei Ebenen gemeinsam entworfen werden, ist das Ergebnis ein Auslieferungssystem, das als eine einzige kohärente Einheit funktioniert. Teams müssen nicht herausfinden, wie sie inkompatible Teile zum Laufen bringen. Die Plattform bietet, was die Pipeline braucht. Die Pipeline führt aus, was die Strategie erfordert. Die Strategie respektiert die Fähigkeiten der Plattform.

Praktische Checkliste für Ihr Auslieferungssystem

Bevor Sie Ihre Plattform, Pipeline und Deployment-Strategie finalisieren, gehen Sie diese Prüfpunkte durch:

• Kann jedes Team seinen Service mit derselben Pipeline-Vorlage deployen?
• Bietet die Plattform dasselbe Verhalten in Staging und Produktion?
• Können Sie ein Deployment ohne manuellen Eingriff zurücksetzen?
• Enthält die Pipeline Verifikationsschritte, die zu Ihrer Deployment-Strategie passen?
• Kann die Plattform Ihre gewählte Deployment-Strategie ohne Workarounds unterstützen?
• Ist der Datenbank-Migrationsprozess in die Pipeline integriert, nicht separat behandelt?
• Können Sie während der Geschäftszeiten deployen, ohne Angst zu haben, Benutzer zu stören?

Wenn eine Antwort „Nein“ lautet, haben Sie eine Lücke zwischen den Ebenen. Schließen Sie die Lücke, bevor Sie das System skalieren.

Das Fazit

Plattform, Pipeline und Deployment-Strategie sind keine drei separaten Entscheidungen. Sie sind ein System, das gemeinsam entworfen werden muss. Wenn sie aufeinander abgestimmt sind, können Teams häufig deployen, schnell wiederherstellen und darauf vertrauen, dass jede Änderung denselben rigorosen Pfad durchläuft. Wenn sie nicht aufeinander abgestimmt sind, wird jedes Deployment zu einem Koordinationsproblem, und jeder Vorfall offenbart eine Lücke zwischen dem, was die Plattform bietet, und dem, was die Strategie benötigt. Beginnen Sie mit der Plattform, bauen Sie die Pipeline darum herum und wählen Sie die Strategie, die beide unterstützen können.