Wenn die Pipeline entscheidet, wer ein Deployment freigibt

Stellen Sie sich vor: Ein Entwickler korrigiert einen Tippfehler in einer Dokumentationsseite. Die Änderung umfasst eine Zeile, keine Logik ist betroffen, keine Datenbank wird berührt. Trotzdem verlangt der Deployment-Prozess zwei Freigaben, 30 Minuten Wartezeit in der Staging-Umgebung und eine Unterschrift des Engineering Managers. Die Korrektur, die in fünf Minuten bei den Nutzern sein sollte, braucht am Ende einen halben Tag.

Stellen Sie sich nun das Gegenteil vor: Ein Entwickler ändert ein Datenbank-Migrationsskript, das eine Produktionstabelle sperren könnte. Dieselbe Pipeline behandelt es genauso wie den Tippfehler. Keine zusätzliche Überprüfung, keine weiteren Checks. Die Änderung geht durch, und das Team bemerkt das Problem erst, wenn Abfragen beginnen, Zeitüberschreitungen zu produzieren.

Beide Szenarien sind falsch, aber aus entgegengesetzten Gründen. Das erste bremst sichere Änderungen aus. Das zweite lässt gefährliche Änderungen durchrutschen. Das Problem ist, dass die meisten Deployment-Pipelines für jede Änderung dieselben Regeln anwenden, unabhängig davon, was sich tatsächlich geändert hat.

Warum ein Einheits-Freigabemodell nicht funktioniert

Die meisten Teams beginnen mit einem einfachen Freigabemodell: Jedes Deployment benötigt eine Überprüfung. Das funktioniert, wenn das Team klein ist und jede Änderung bedeutend ist. Aber mit wachsender Codebasis bricht das Modell zusammen. Ein CSS-Tweak und ein Refaktor des Zahlungsmoduls erfordern dieselbe Freigabe. Entwickler fangen an, das System zu umgehen, indem sie Änderungen bündeln, um die Anzahl der Deployments zu reduzieren, oder schlimmer noch, Überprüfungen ganz überspringen, weil der Prozess wie Bürokratie wirkt.

Das eigentliche Problem ist, dass Risiko nicht gleichmäßig verteilt ist. Eine Änderung an einer README-Datei birgt nahezu null operationelles Risiko. Eine Änderung an einer Datenbankmigration oder einem Authentifizierungsmodul birgt erhebliches Risiko. Beide gleich zu behandeln bedeutet, dass Sie entweder zu streng für sichere Änderungen oder zu lasch für riskante sind.

Wie eine Pipeline Risiko automatisch bewerten kann

Anstatt sich auf Menschen zu verlassen, die jede Änderung beurteilen, können Sie Ihrer Pipeline beibringen, Risiken basierend auf den geänderten Dateien zu bewerten. Dies wird als Risikobewertung bezeichnet und funktioniert durch die Definition von Regeln, die Änderungen basierend auf ihrem Umfang Punkte zuweisen.

Ein einfacher Regelsatz könnte so aussehen:

So sieht diese Logik in einer GitLab-CI-Pipeline-Konfiguration aus:

stages:
  - test
  - deploy

deploy:
  stage: deploy
  script:
    - echo "Deploying to production..."
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "db/**/*"
        - "config/**/*"
      when: manual
      allow_failure: false
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "docs/**/*"
        - "README.md"
      when: on_success
    - when: on_success
  • Änderungen an Dateien in docs/ oder README.md: 0 Punkte
  • Änderungen an Konfigurationsdateien (.env, config/): 3 Punkte
  • Änderungen an Geschäftslogik in src/: 7 Punkte
  • Änderungen an Zahlungs- oder Authentifizierungsmodulen: 20 Punkte
  • Änderungen an Datenbank-Migrationsdateien: 25 Punkte

Die Pipeline scannt den Pull Request oder Commit, prüft jede geänderte Datei gegen diese Regeln und summiert die Gesamtpunktzahl. Diese Punktzahl bestimmt dann, was als Nächstes passiert.

Risikobewertungen auf Deployment-Richtlinien abbilden

Sobald die Pipeline eine Risikobewertung hat, kann sie basierend auf dem Ergebnis unterschiedliche Richtlinien anwenden. Ein typisches Setup könnte drei Stufen haben:

Das folgende Flussdiagramm zeigt, wie die Pipeline Risikobewertungen auf Deployment-Richtlinien abbildet:

flowchart TD A[Änderung eingereicht] --> B{Geänderte Dateien scannen} B --> C[Risikobewertung zuweisen] C --> D{Punktzahl <= 5?} D -->|Ja| E[Niedriges Risiko] E --> F[Automatische Freigabe] F --> G[In Produktion deployen] D -->|Nein| H{Punktzahl 6-15?} H -->|Ja| I[Mittleres Risiko] I --> J[Eine Peer-Freigabe erforderlich] J --> G H -->|Nein| K[Hohes Risiko] K --> L[Zwei Freigaben erforderlich] L --> M[In Staging deployen] M --> N[Smoke-Tests ausführen & überwachen] N --> O{Checks bestanden?} O -->|Ja| G O -->|Nein| P[Deployment blockieren]

Niedriges Risiko (Punktzahl 0-5): Die Änderung kann ohne manuelle Freigabe direkt in die Produktion. Die Pipeline führt automatisierte Tests aus, und wenn diese bestehen, wird das Deployment fortgesetzt. Dies deckt Dokumentationskorrekturen, kleinere Konfigurationsänderungen oder Refaktorisierungen ab, die keine kritischen Pfade berühren.

Mittleres Risiko (Punktzahl 6-15): Die Änderung benötigt eine Freigabe von einem Peer oder Senior Engineer. Die Pipeline pausiert nach bestandenen Tests und wartet auf eine manuelle Freigabe, bevor sie in die Produktion fortfährt.

Hohes Risiko (Punktzahl 16+): Die Änderung benötigt zwei Freigaben und muss mindestens eine Stunde in der Staging-Umgebung verbringen, wobei Überwachungschecks bestanden werden müssen. Die Pipeline deployed zuerst in Staging, führt Smoke-Tests aus, prüft Fehlerraten und Latenz und erlaubt erst dann die endgültige Promotion in die Produktion.

Diese Schwellenwerte sind nicht festgelegt. Unterschiedliche Umgebungen können unterschiedliche Regeln haben. In einer Entwicklungsumgebung könnten Sie alles als niedriges Risiko behandeln, da es keine echten Nutzer gibt. In Staging könnten Sie die Schwellenwerte leicht anheben. In der Produktion wenden Sie die strengsten Regeln an.

Der wahre Vorteil ist Konsistenz, nicht perfekte Genauigkeit

Die Risikobewertung wird nie perfekt genau sein. Eine einzeilige Änderung in einer Hilfsfunktion könnte etwas Unerwartetes kaputt machen, wenn diese Funktion an vielen Stellen aufgerufen wird. Ein großer Refaktor, der viele Dateien berührt, könnte tatsächlich sicher sein, wenn er nur Variablen umbenennt.

Aber perfekte Genauigkeit ist nicht das Ziel. Das Ziel ist es, ad-hoc menschliches Urteilsvermögen durch einen konsistenten, transparenten Prozess zu ersetzen. Ohne Risikobewertung beginnt jedes Deployment mit einer Debatte: „Braucht das eine Freigabe? Wer soll es überprüfen? Ist das riskant genug, um Staging-Zeit zu rechtfertigen?“ Diese Debatten verschwenden Zeit und schaffen Inkonsistenz. Eine Woche wird eine kleine Änderung durchgewunken, die nächste Woche wird derselbe Änderungstyp blockiert.

Mit Risikobewertung sind die Regeln niedergeschrieben und werden automatisch angewendet. Das Team kann einmal über die Regeln diskutieren, wenn es sie einrichtet, anstatt über jedes einzelne Deployment zu diskutieren. Und weil die Regeln transparent sind, kann das Team sie im Laufe der Zeit überprüfen und anpassen, wenn es lernt, welche Arten von Änderungen tatsächlich Probleme verursachen.

Wie dies das Teamverhalten verändert

Risikobasierte Deployment-Steuerung macht mehr als nur Freigaben zu automatisieren. Sie verändert, wie Entwickler über Codestruktur denken. Wenn das Team weiß, dass jede Änderung an db/migrations/ automatisch die Hochrisiko-Richtlinie auslöst, wird es vorsichtiger mit dem, was in diesen Ordner kommt. Sie könnten Datenbankschema-Änderungen von Datenmigrationsskripten trennen, sodass ein einfaches Daten-Backfill nicht dieselbe Prüfung auslöst wie eine Schemaänderung.

Es fördert auch eine bessere Modularisierung. Wenn ein Team bemerkt, dass Änderungen an einem bestimmten Modul immer eine hohe Risikobewertung erhalten, könnte es dieses Modul umgestalten, um die wirklich sensiblen Teile von den Routine-Updates zu isolieren. Mit der Zeit wird die Codebasis bewusster um Risikogrenzen herum strukturiert.

Praktische Checkliste für die Einrichtung der Risikobewertung

Wenn Sie diesen Ansatz implementieren möchten, hier eine Start-Checkliste:

  • Identifizieren Sie, welche Ordner und Dateimuster in Ihrer Codebasis unterschiedliche Risikostufen darstellen
  • Definieren Sie ein Bewertungssystem mit klaren Punktwerten für jedes Muster
  • Legen Sie Schwellenwerte für niedriges, mittleres und hohes Risiko in jeder Umgebung fest
  • Definieren Sie die Deployment-Richtlinie für jede Risikostufe (erforderliche Freigaben, Staging-Zeit, Überwachungschecks)
  • Implementieren Sie die Risikobewertungslogik in Ihrer CI/CD-Pipeline-Konfiguration
  • Führen Sie die Bewertung bei jedem Pull Request durch und protokollieren Sie die Ergebnisse zur Transparenz
  • Überprüfen Sie die Bewertungsregeln nach einem Monat und passen Sie sie basierend auf dem Gelernten an

Die Pipeline wird zum Entscheidungsträger

Wenn Sie eine risikobasierte Deployment-Steuerung hinzufügen, hört Ihre Pipeline auf, nur ein Werkzeug zu sein, das Befehle ausführt. Sie wird zu einem Entscheidungssystem, das Änderungen bewertet, Regeln anwendet und den geeigneten Weg in die Produktion bestimmt. Die Pipeline ersetzt nicht vollständig das menschliche Urteilsvermögen, aber sie reserviert die menschliche Aufmerksamkeit für die Änderungen, die sie tatsächlich benötigen.

Es geht nicht darum, Kontrolle zu entfernen. Es geht darum, die richtige Kontrollstufe auf die richtige Änderung anzuwenden. Kleine, sichere Änderungen bewegen sich schnell. Große, riskante Änderungen erhalten die Prüfung, die sie verdienen. Und das Team hört auf, Energie mit Debatten zu verschwenden, die offensichtlich sein sollten.