Bevor der Feature Builder baut, sucht er nach offenen Bugs

Noch bevor der Feature Builder die erste Zeile eines neuen Features schreibt, schaut er nach, ob das Fundament Risse hat.

Um diesen Pre-Flight-Check geht es mir hier. Die Automation läuft in der Factory, die öffentlich auf software-factory.dev (öffnet in einem neuen Tab) entsteht. Sie baut das nächste Feature aus dem Backlog komplett, von vorn bis hinten. Vorher muss sie sich das aber erst verdienen.

Wann sie aufwacht

Die Cron-Zeile 0 */2 * * * weckt sie alle zwei Stunden. Zusätzlich reagiert sie auf das Ereignis „Pull Request gemergt“: Ein frischer Merge kann also direkt den nächsten Build auslösen. Manuell starten lässt sie sich auch.

Der Pre-Flight-Check

Ist sie wach, greift sie nicht gleich ins Backlog. Zuerst zählt sie die offenen Pull Requests. Sind es drei oder mehr, bricht sie ab.

Danach folgt der Check, auf den es ankommt. Sie sucht nach offenen Bugs der Priorität 1, um die sich noch keiner kümmert. Gemeint sind Bugs, die weder in Arbeit noch im Review noch bei einem Menschen liegen. Gibt es so einen Bug, bricht sie ab. Für Bugs der Priorität 2 läuft dieselbe Prüfung.

Solange also ein wichtiger Bug ohne Bearbeiter herumliegt, ruht jede neue Feature-Arbeit. Der Builder lässt der Bug-Fixer-Automation den Vortritt. Hat jemand den Bug übernommen, geht es mit den Features weiter. Der Check soll nur verhindern, dass ein ernster Bug ohne Owner bleibt. Ist ein Fix schon in Arbeit oder im Review, hält er die Linie nicht auf. Bugs der Priorität 3 blockieren gar nicht, so läuft die Linie bei Kleinigkeiten weiter. Wenn aber etwas ernsthaft kaputt ist, geht das vor.

Bauen, sobald beide Checks bestanden sind

Sind beide Checks grün, holt sie sich das Feature mit der höchsten Priorität aus dem Backlog, dessen Abhängigkeiten alle geschlossen sind. Dann arbeitet sie es Schritt für Schritt ab: Migration, Typen, Datenzugriff, UI, Component Stories, Seitenintegration, Tests, Pull Request.

Tests kommen in denselben Pull Request

Das zweite Detail, das ihr übernehmen solltet, wendet denselben Gedanken auf Tests an. Für jede interaktive UI sind End-to-End-Tests Pflicht. Sie kommen in denselben Pull Request und werden nie auf später verschoben. Berührt eine Änderung eine bestehende Interaktion, muss der Builder alle betroffenen Tests aufspüren und im selben Pull Request anpassen. Hinterlässt eine Änderung andere Tests kaputt, wird sie abgelehnt.

Die Reihenfolge beim Bauen ist ein Sicherheitsmechanismus

Beide Regeln gehen auf dasselbe Prinzip zurück. In welcher Reihenfolge gebaut wird, ist eine Sicherheitsfrage, keine Komfortfrage. Wer neue Features baut, während Bugs offen sind, nimmt Schulden auf, um mehr Durchsatz zu bekommen. Der Pre-Flight-Check kostet jetzt ein bisschen Tempo. Dafür bekommt ihr ein Fundament, auf dem ihr weiterbauen könnt.

Wer die Automation selbst lesen will: feature-builder.yaml im Repository der Factory (öffnet in einem neuen Tab).

Was prüft eure Build-Pipeline, bevor sie mit neuer Arbeit beginnt? Und zählt „ein ernster Bug ohne Owner“ zu den Gründen, aus denen sie anhält?

Weiterlesen

Die Artikel der Wissensbasis sind auf Englisch.

• The software-factory pattern →
• Agentic Software Factory: Advanced Team Training →