35-7 · Kapitel 35 · 6 Min. Lesezeit

Wenn jedes Team anders deployed

In vielen Engineering-Organisationen ist Deployment keine gemeinsame Fähigkeit, sondern eine Sammlung individueller Gewohnheiten. Plattform-Engineering schafft Abhilfe durch einen standardisierten, sicheren und einfachen Deployment-Pfad.

Wenn jedes Team anders deployed

In vielen Engineering-Organisationen ist Deployment keine gemeinsame Fähigkeit. Es ist eine Sammlung individueller Gewohnheiten. Team A hat ein Shell-Skript, das von jemandes Laptop aus läuft. Team B hat eine Pipeline, die vor zwei Jahren gebaut wurde, und niemand fasst sie an, weil alle Angst haben, dass sie kaputtgeht. Team C verwendet ein völlig anderes Tool, weil ein Senior Engineer damit vertraut war. Das Ergebnis ist vorhersehbar: Deployments sind inkonsistent. Ein Team kann in fünf Minuten ausliefern. Ein anderes Team braucht zwei Stunden. Ein Team hat automatisiertes Rollback. Ein anderes Team muss manuell aus dem Backup wiederherstellen.

Diese Situation hat nichts mit fehlenden Fähigkeiten zu tun. Es geht um das Fehlen eines gemeinsamen Deployment-Systems. Wenn jedes Team seinen eigenen Deployment-Pfad baut, verliert die Organisation die Fähigkeit sicherzustellen, dass jedes Deployment die gleichen Sicherheitsprüfungen durchläuft. Sicherheitsscans werden in einem Team vielleicht übersprungen. Integrationstests sind in einem anderen Team vielleicht optional. Genehmigungsprozesse variieren. Und wenn etwas schiefgeht, ist schwer zu erkennen, ob das Problem im Code, in der Konfiguration oder im Deployment-Prozess selbst liegt.

Das Problem der kognitiven Last

Jedes Mal, wenn ein Team darüber nachdenken muss, wie es deployed, verlieren sie den Fokus auf das, was wirklich zählt: ob die Funktion korrekt ist, ob die Datenbankänderung sicher ist oder ob die Infrastrukturkonfiguration angemessen ist. Deployment wird zur Ablenkung, nicht zur Routine.

Besonders schmerzhaft ist das für Teams, die sowohl Anwendungscode als auch Infrastruktur betreuen. Sie müssen sich merken, welche Umgebungsvariablen gesetzt, welche Secrets rotiert, welche Migrationsskripte ausgeführt und in welcher Reihenfolge sie ausgeführt werden müssen. Der mentale Overhead summiert sich. Und wenn etwas vergessen wird, schlägt das Deployment fehl, und das Team verbringt Zeit damit, den Prozess zu debuggen, anstatt das Produkt zu reparieren.

Das Problem ist nicht, dass Teams nachlässig sind. Das Problem ist, dass Deployment-Wissen über Einzelpersonen, Skripte und veraltete Dokumentation verstreut ist. Es gibt keine einzige Quelle der Wahrheit. Jedes Deployment fühlt sich an wie ein neues Problem, das gelöst werden muss.

Plattform-Engineering als Service, nicht als Tool

Plattform-Engineering adressiert dies, indem es einen Deployment-Pfad bereitstellt, der bereits getestet, sicher und einfach zu bedienen ist. Die Idee ist einfach: Teams sollten nicht herausfinden müssen, wie sie deployen. Sie sollten sich keine Gedanken über Umgebungseinrichtung, Version-Tracking oder Rollback-Verfahren machen müssen. Die Plattform kümmert sich um diese Belange.

Aber Plattform ist kein Tool. Es ist ein Service. Teams ist es egal, ob die Plattform auf Jenkins, GitLab CI, GitHub Actions oder etwas anderem läuft. Worauf es ihnen ankommt, ist, ob die Plattform ihnen hilft, sicher, schnell und ohne Nachdenken über Dinge zu deployen, die bereits erledigt sein sollten. Wenn die Plattform zu komplex oder zu starr ist, finden Teams ihren eigenen Weg darum herum. Und die Organisation ist wieder am Ausgangspunkt: inkonsistente Deployments.

Eine gute Plattform bietet einen goldenen Pfad. Es ist der am meisten empfohlene Weg zu deployen, und er funktioniert für die meisten Teams die meiste Zeit. Aber sie erlaubt auch Anpassungen für Teams mit spezifischen Anforderungen. Ein Team, das eine compliance-lastige Anwendung betreut, benötigt vielleicht zusätzliche Genehmigungsschritte. Ein Team, das an einem internen Tool mit geringem Risiko arbeitet, kann vielleicht schneller deployen. Die Plattform sollte diese Unterschiede berücksichtigen, ohne jedes Team zu zwingen, alles von Grund auf neu zu bauen.

Was eine Deployment-Plattform tatsächlich bietet

Eine Deployment-Plattform ist nicht nur eine Pipeline. Sie ist eine Reihe von Fähigkeiten, die Teams nutzen können, ohne Infrastruktur von Null aufzubauen. Hier ist, was eine praktische Plattform typischerweise umfasst:

Ein wiederverwendbares GitLab CI-Job-Template könnte zum Beispiel so aussehen:

.deploy-template:
  stage: deploy
  script:
    - run-security-scan
    - run-integration-tests
    - deploy-canary --percentage 10
    - wait-for-health-check
    - promote-to-production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  variables:
    DEPLOY_ENV: "production"
  artifacts:
    reports:
      security: gl-security-report.json

Teams können dieses Template in ihre eigenen Pipelines einbinden und erben so alle Sicherheitsprüfungen, ohne sie neu implementieren zu müssen.

Eine Standard-Pipeline, die bereits damit integriert ist, wie Teams Code schreiben, Konfiguration speichern und Umgebungen verwalten. Wenn ein Team Code in einen bestimmten Branch pusht, führt die Plattform automatisch Build-, Test- und Deployment-Schritte aus. Das Team muss keine Pipeline-Skripte von Grund auf neu schreiben.

Umgebungsmanagement, das sicherstellt, dass jede Umgebung konsistent ist. Staging und Produktion sollten nicht auseinanderdriften, weil jemand manuell eine Konfiguration geändert hat. Die Plattform sollte erzwingen, dass Umgebungen jedes Mal auf die gleiche Weise bereitgestellt und konfiguriert werden.

Sicherheits- und Compliance-Prüfungen, die bei jedem Deployment automatisch laufen. Dazu gehören Schwachstellenscans, Secret-Erkennung und Richtliniendurchsetzung. Teams sollten sich nicht daran erinnern müssen, diese Prüfungen durchzuführen. Die Plattform führt sie als Teil des Deployment-Prozesses aus.

Rollback-Fähigkeit, die getestet und zuverlässig ist. Wenn ein Deployment schiefgeht, sollte die Plattform eine Möglichkeit bieten, ohne manuelles Eingreifen zum letzten bekannten guten Zustand zurückzukehren. Das gilt nicht nur für Code. Es gilt auch für Datenbankmigrationen und Infrastrukturänderungen.

Observability-Integration, die Deployment-Ereignisse mit Monitoring und Alerting verbindet. Wenn ein Deployment stattfindet, sollte die Plattform Signale aussenden, die Teams helfen zu verstehen, ob das Deployment gesund ist. Das verkürzt die Zeit zwischen einem schlechten Deployment und seiner Erkennung.

Konsistenz ohne Starrheit

Die größte Angst vor Plattform-Engineering ist, dass es jedes Team in die gleiche Form zwängt. Das ist eine berechtigte Sorge, aber auch ein Missverständnis dessen, was eine gute Plattform tut.

Eine Plattform, die zu starr ist, wird von Teams abgelehnt. Sie werden sie umgehen, eigene Workarounds bauen oder sie ganz ignorieren. Eine Plattform, die zu flexibel ist, wird chaotisch, weil jedes Team sie anders nutzt und die Organisation die Konsistenz verliert, die sie erreichen wollte.

Die Balance liegt in der Bereitstellung eines goldenen Pfades, der für die meisten Fälle funktioniert, während Teams abweichen können, wenn sie einen klaren Grund haben. Die Abweichung sollte explizit sein, nicht zufällig. Wenn ein Team einen anderen Genehmigungsablauf benötigt, sollte es ihn konfigurieren können. Wenn ein Team vor dem Deployment zusätzliche Tests ausführen muss, sollte es sie hinzufügen können. Aber der Basispfad sollte der Standard sein, und er sollte die einfachste zu nutzende Option sein.

Praktische Checkliste für den Aufbau einer Deployment-Plattform

Wenn Sie den Aufbau oder die Verbesserung einer Deployment-Plattform in Betracht ziehen, hier eine kurze Checkliste zur Orientierung:

Reduziert die Plattform die Anzahl der Entscheidungen, die ein Team vor dem Deployment treffen muss?
Kann ein Team deployen, ohne Dokumentation zu lesen oder ein anderes Team um Hilfe zu bitten?
Setzt die Plattform die gleichen Sicherheits- und Compliance-Prüfungen für jedes Team durch?
Ist Rollback automatisiert und getestet, nicht nur dokumentiert?
Können Teams den Deployment-Prozess anpassen, ohne die Plattform zu beschädigen?
Sendet die Plattform Signale, die Teams helfen, Probleme nach dem Deployment zu erkennen?
Ist die Plattform einfacher zu nutzen als die Alternative, eine benutzerdefinierte Pipeline zu bauen?

Wenn die Antwort auf eine dieser Fragen nein ist, erfüllt die Plattform noch nicht ihren Zweck.

Das eigentliche Ziel

Plattform-Engineering geht nicht um Zentralisierung von Kontrolle. Es geht um die Beseitigung von Reibung. Wenn Teams deployen können, ohne über den Deployment-Prozess selbst nachdenken zu müssen, können sie sich auf das konzentrieren, was sie tatsächlich bauen. Sie können Funktionen schneller ausliefern, sich zuverlässiger von Fehlern erholen und weniger Zeit mit operativem Overhead verbringen.

Das Maß für eine gute Plattform ist nicht, wie viele Tools sie integriert oder wie viele Funktionen sie hat. Das Maß ist, ob Teams ihr genug vertrauen, um sie ohne Zögern zu nutzen. Wenn ein Team Code pushen und wissen kann, dass die Plattform den Rest erledigt, hat sich die Organisation von individuellen Deployment-Gewohnheiten zu einer gemeinsamen Deployment-Fähigkeit entwickelt. Das ist der Punkt, an dem Deployment aufhört, ein Risiko zu sein, und zur Routine wird.