tderoussel/ship-gate

Ship Gate

Jede Regel hier existiert, weil die offensichtliche Prüfung einmal ein falsches Positiv zurückgegeben hat. Führe das Gate vor der Behauptung aus, nicht danach.

Passe die Einzelheiten an deinen Stack an; die Form – Was würde diese Behauptung falsch machen? – ist der übertragbare Teil.

Die Behauptungsregel

Eine Behauptung über die Produktion erfordert eine Abfrage gegen die Produktion.

Ein bestandener Test ist nicht die Produktion. Ein gemergter PR ist nicht die Produktion. Ein grünes Deployment ist nicht die Produktion. Jede davon ist eine Behauptung über ein anderes System als das, über das du eine Aussage triffst.

Wenn kein Mensch das Ergebnis überprüft hat, ist es nicht „verifiziert“ – sag stattdessen, was du tatsächlich überprüft hast.

Deployment-Verifikation

• Wisse, was tatsächlich ein Deployment auslöst. Bei einem git-integrierten Host ist es der Push, nicht ein CLI-Aufruf. Ein Deployment über die CLI, wenn das Projekt per Push deployed, erzeugt einen Build, den die Benutzer nicht bekommen.
• Überprüfe das Konto, dem das Projekt gehört. Ein lokal eingeloggtes CLI kann als persönliches Konto authentifiziert sein, dem das Produktionsprojekt nicht gehört – dann gelingen alle Befehle gegen das falsche Ziel, stillschweigend.
• Verifiziere mit dem Commit-Status gegen den deployed SHA, nicht mit einem Dashboard-Blick.
• Bestätige das Deployment, das aktuelle Produktion ist, nicht nur eines, das READY ist. Mehrere können gleichzeitig bereit sein.
• Edge-/Serverless-Funktionen werden separat von der App deployed. Ein gemergter PR deployed keine Edge-Funktion; überprüfe ihre Version explizit.
• Nur-Client-Änderungen benötigen möglicherweise kein Funktionsdeployment – warte nicht auf eines, das nie kommt.
• Rufe das Live-Manifest erneut ab, bevor du eine Version bestätigst. Parallele Arbeit erhöht Versionen unter dir.

CI-Verifikation

• Prüfe auf jeden erforderlichen Kontext, nicht auf den ersten grünen.
• Prüfe niemals einen Piped-Befehl. some-check | tail meldet den Exit-Code von tail und maskiert den eigentlichen Fehler. In Shells ohne PIPESTATUS (zsh unterscheidet sich hier von bash) ist das leicht falsch zu machen – überprüfe den eigenen Status des Befehls.
• steps: 0 bedeutet, dass der Job nie gelaufen ist, nicht dass er bestanden hat. Eine Checks-API kann eine Schlussfolgerung für einen Job melden, der keine Arbeit erledigt hat.
• Ein verdächtig schneller Fehler ohne Schritte ist normalerweise ein Abrechnungs- oder Berechtigungsproblem, kein YAML-Problem.
• Das erneute Ausführen nur fehlgeschlagener Jobs spielt einen veralteten Snapshot des Branches ab. Aktualisiere zuerst den Branch, dann führe erneut aus.
• Eine Checkliste lässt Jobs aus, die nie erstellt wurden. Das Fehlen eines Fehlers ist kein Beweis für ein Bestehen.
• gh pr create erfordert ein explizites --base. Verkettete Heredocs darum können stillschweigend fehlschlagen.

Type- und Lint-Gates

• Große TypeScript-Projekte benötigen möglicherweise einen erhöhten Node-Heap; ohne ihn stirbt tsc auf eine Weise, die wie ein Codefehler aussieht.
• Wisse, welche Verzeichnisse dein Typechecker und Linter tatsächlich abdecken. Edge-Funktionsverzeichnisse sind häufig von beiden ausgeschlossen. Wenn sie mit einer anderen Laufzeitumgebung laufen, überprüfe sie mit dem eigenen Checker dieser Laufzeit – ein Test-Job ist kein Type-Gate.
• Baue in Worktrees oder sauberen Checkouts, nicht in einem Arbeitsverzeichnis mit nicht committedem Drift.

Datenbank

• Schiebe Schema niemals beiläufig oder führe Migrationen gegen die Produktion durch. Wende Schema über den überprüften Pfad an, den das Projekt gewählt hat, einmal.
• Rufe neue Stored Procedures gegen die echte Datenbank auf, bevor du ihnen glaubst. Mocks verbergen Laufzeitfehler, die nur mit echten Typen und echter Ambiguität auftreten.
• Wenn die Testsuite die Datenbank global mocked, beweist ein bestandener Unit-Test nichts über die Datenbank.
• Führe niemals Compare-and-Set auf einer Trigger-verwalteten Spalte durch – der Trigger ändert sie unter dem Schreibvorgang.
• Messe die Auswirkung einer Änderung gegen Produktionsdaten, bevor du mergeest. Ein Filter, der gegen einen lokalen Seed schmal aussieht, kann einen sehr anderen Anteil echter Zeilen treffen.

Umgebungsfallen

• Gehe niemals von der Zeitzone der Maschine aus – führe date aus. Datumsabhängige Tests schlagen am Offset fehl, und der Fehler sieht wie ein Codefehler aus.
• Eine nicht gesetzte Git-Identität kann Deployments blockieren und als unzusammenhängender Netzwerkfehler erscheinen.
• Setze Host-Umgebungsvariablen aus einer Datei, nicht durch Inline-Zuweisung; Shells und CLIs können abschließende Zeilenumbrüche einbetten, die den Wert unsichtbar beschädigen.
• Der Erfolg eines geplanten Jobs ist nicht der Erfolg des Job-Effekts: Ein Runner, der succeeded meldet, bedeutet, dass der Aufruf zurückgekehrt ist, nicht dass die Arbeit stattgefunden hat. Verifiziere den Effekt.

Ausgabe

Gib jedes Gate als BESTANDEN (Nachweis) oder NICHT GEPRÜFT (Warum) aus.

Gib niemals vor, dass ein Gate ausgeführt wurde, wenn es das nicht wurde. Wenn ein Gate fehlschlägt oder nicht geprüft ist, sage klar, dass die Änderung nicht verifiziert ist – die Behauptung zurückzuhalten ist korrekt.