EP-BUILD-CONTRACT

Build Contract#

Vorbedingungen#

Ein Build darf nur starten, wenn:

der zu bauende Scope eindeutig ist,
Quell- und Abhängigkeitsstände bestimmt sind,
erforderliche Verträge und Manifeste lesbar sind,
die Konfiguration keine verbotenen hart codierten Umgebungswerte benötigt,
die vorgelagerten Validierungen erfolgreich sind.

Verbindliche Eigenschaften#

Deterministisch: Reihenfolge und Auswahl der Eingaben sind nachvollziehbar.
Isoliert: Veränderliche Runtime-Zustände werden nicht als Quelle verwendet.
Abbruchorientiert: Strukturelle Fehler stoppen vor teuren Folgeschritten.
Nachweisbar: Status und verwendete Eingaben werden dokumentiert.
Wiederholbar: Ein fehlgeschlagener Lauf kann nach Behebung ohne manuelle Bereinigung erneut gestartet werden.
Nicht promotend: Der Build selbst verändert weder Baseline noch Production.

Fehlervertrag#

Fehler werden mit Stufe, betroffenem und Ursache ausgegeben. Ein fehlgeschlagener Build erzeugt keinen als erfolgreich markierten Kandidaten. Teilresultate dürfen zu Diagnosezwecken erhalten bleiben, müssen jedoch eindeutig als nicht freigegeben gekennzeichnet sein.

Verantwortungsgrenzen#

Die Engineering Platform definiert diesen Vertrag. Gemeinsame Build-Werkzeuge werden nicht hier dupliziert. Workspace- und Building-Block-spezifische Builddefinitionen spezialisieren den Vertrag, ohne ihn abzuschwächen.

Nachbedingungen#

Nach Erfolg existieren ein eindeutig identifizierbares Build-Ergebnis und dessen Evidenz. Erst nach zusätzlichen Pipeline-Gates kann daraus ein Kandidat für Packaging oder werden.

Nachweis und Realisierungskette#

Der Vertrag wird durch ausgeführt. Erfolgreiche Läufe materialisieren ein Build-Manifest und versiegelte in Runtime. Die muss Repositoryrevisionen, ausgeführte Schritte, Ergebnisarten und SHA-256-Werte enthalten.