Prüfung vor dem Release

Was vor einer Veröffentlichung läuft, welche Befunde blockieren, welche nur informieren — und was eine durchgelaufene Veröffentlichung nicht beweist.

Zwei Features können einzeln einwandfrei funktionieren und trotzdem brechen, sobald sie zusammenkommen. Das ist der typische Fehlerfall KI-generierter Software — und der Grund, warum Veröffentlichen in Airbuild kein Dateikopiervorgang ist.

Alles läuft gegen einen eingefrorenen Stand

Beim Veröffentlichen wird der Code zuerst eingefroren, und jede Prüfung läuft gegen genau diesen Stand — nicht gegen eine Arbeitskopie, die sich während der Prüfung noch ändern kann. Was geprüft wurde, ist das, was rausgeht.

Die Prüfungen

• Tests — die generierten Testsuiten: vitest für das Frontend, pytest für das Backend. Sie laufen gegen den Stand, wenn das Pre-Publish-Gate der Testing-Integration für dieses Projekt aktiviert ist. Standardmäßig ist es aus, und ohne es stoppt eine rote Suite kein Release.
• Abhängigkeiten und Secrets — Pakete mit bekannten Schwachstellen und Zugangsdaten, die nie in einem Repository liegen sollten.
• Statische Analyse und Code-Qualität — Sicherheitsmuster und Codequalität über die Quellen hinweg.
• API-Vertrag — die OpenAPI-Spezifikation wird erzeugt, ohne die Anwendung zu starten, und anschließend geprüft. Beratend: Befunde erscheinen im Problems-Panel, sie blockieren nicht.
• Endpunkte ohne Authentifizierung — jede Backend-Operation ohne Sicherheitsanforderung wird aufgelistet, abzüglich der bewusst öffentlichen wie Login, Registrierung und Health. Bestätigungspflicht: Du musst die Liste sehen und annehmen.
• Optional, je Projekt — SonarQube für tiefere Qualitätsanalyse und ein dynamischer Sicherheitsscan gegen die laufende Anwendung.

Welche Prüfungen laufen, ist eine Einstellung pro Projekt; jede wird als Integration aktiviert.

Blockierend, beratend, bestätigungspflichtig

Nicht jeder Befund stoppt ein Release, und der Unterschied ist Absicht. Befunde hoher Schwere aus der Analyse blockieren. API-Lint-Befunde informieren. Offene Endpunkte fragen.

Eine Prüfung, die nicht laufen kann, blockiert nicht. Die Gates hängen daran, was eine Prüfung meldet — nicht daran, ob sie überhaupt melden konnte. Lässt sich die OpenAPI-Spezifikation nicht erzeugen, läuft das Gate für offene Endpunkte durch, statt das Release zu verweigern; auch Aufräumschritte wie das Löschen eines SonarQube-Analyse-Projekts sind Best-Effort. Eine durchgelaufene Veröffentlichung heißt deshalb: Es wurde nichts Blockierendes gemeldet — nicht, dass jede Prüfung fertig geworden ist. Welche Werkzeuge tatsächlich liefen, steht im Nachweis weiter unten, und genau dort wird der Unterschied sichtbar.

Vor den Gates: die Live-Vorschau

Jeder Workspace hat eine Live-Vorschau der laufenden Anwendung, inklusive Backend und Datenbank. Sich durch die Abläufe zu klicken, auf die es wirklich ankommt — besonders die, die zwei Features verbinden —, ist der billigste Test überhaupt, und er passiert lange vor jedem Gate.

Der Nachweis

Jede Veröffentlichung hält einen Audit-Eintrag pro ausgeführtem Werkzeug fest. Auch Monate später ist damit beantwortbar, was geprüft wurde, mit welchem Scanner und gegen welchen Stand des Codes.