Quality Gate

Ein Quality Gate ist eine Reihe von Bedingungen, die eine Änderung erfüllen muss, bevor sie in die nächste Stufe gelangt: Merge, Deployment auf Staging oder Release in Produktion. Jede Bedingung ist messbar und wird automatisch geprüft; schlägt eine fehl, stoppt die Pipeline. Das Gate ersetzt „jemand findet, dass es gut aussieht“ durch eine explizite, vereinbarte Messlatte.

Typische Bedingungen eines Gates

• Alle blockierenden Tests bestehen (Unit, API, eine Smoke-Teilmenge der End-to-End-Tests).
• Die Zeilen- oder Zweigabdeckung von neuem Code fällt nicht unter einen vereinbarten Wert.
• Keine neuen kritischen oder hohen Befunde aus statischer Analyse oder Dependency-Scans.
• Performanceschwellen werden eingehalten, zum Beispiel eine p95-Latenz unter 500 ms in einem kurzen Lasttest.
• Der Build ist reproduzierbar, und das Artefakt ist signiert oder versioniert.

Beispiel

Ein Abdeckungs-Gate in Jest. Fällt die Abdeckung unter diese Werte, beendet sich jest --coverage mit einem Exit-Code ungleich null, und der CI-Job schlägt fehl:

// jest.config.js
module.exports = {
  coverageThreshold: {
    global: {
      branches: 80,
      lines: 85,
    },
  },
};

Für sich allein lässt das nur einen Job fehlschlagen. Zum Gate wird es, wenn der Job ein Required Status Check in der Branch Protection ist, sodass der Merge-Button deaktiviert bleibt, bis er besteht. Tools wie SonarQube bündeln mehrere Bedingungen zu einem benannten Gate mit einem einzigen Bestanden/Nicht-bestanden-Ergebnis.

Warum es wichtig ist

Gates machen die Definition von „fertig“ sichtbar und konsistent. Außerdem verlagern sie Diskussionen auf den richtigen Zeitpunkt: Das Team diskutiert den Schwellenwert einmal, wenn es ihn festlegt, statt bei jedem Release.

Häufige Fehler

• Gates auf Zahlen, die man austricksen kann. Eine harte 90-%-Abdeckungsregel lädt zu Tests ein, die Code ausführen, ohne irgendetwas zu prüfen. Setzen Sie das Gate auf die Abdeckung neuen Codes und reviewen Sie die Tests selbst.
• Flaky Checks im Gate. Ein Gate, das zufällig fehlschlägt, wird umgangen. Lassen Sie nur deterministische Prüfungen blockieren; führen Sie den Rest nicht blockierend mit Alerts aus.
• Zu viele Gates, zu spät. Zehn Bedingungen, die erst vor dem Release geprüft werden, erzeugen einen Berg von Fehlern, für deren Behebung niemand Zeit hat. Setzen Sie günstige Prüfungen früh an, bei jedem Pull Request.
• Stille Overrides. Wenn ein Gate übersprungen werden kann, protokollieren Sie, wer es übersprungen hat und warum.