Wer die Factory prüft, darf das eigene Protokoll nicht umschreiben

Eine Automation in der Software Factory, die öffentlich auf software-factory.dev entsteht, macht nichts anderes, als die übrigen Automationen zu prüfen. Auf genau diesen Teil verweise ich die Leute immer wieder.

Ihr Name: Automation Auditor. Die meisten Teile einer Factory bauen, reparieren oder liefern etwas. Er dagegen reviewt das Band selbst.

Seine Lektüre am Montag

Ein einziger Cron pro Woche löst ihn aus: 0 8 * * 1. Das ist Montag um 8 Uhr, noch bevor sich die Arbeit der Woche auftürmt.

Dann sammelt er die Aktivität einer Woche ein:

• alle Pull Requests, die in den vergangenen sieben Tagen geöffnet und gemergt wurden
• die Issues, die Automationen angelegt haben
• CI-Fix-Commits, die er über eine Suche in den Commit-Messages findet
• Bugs, die von den Verifiern und vom Incident Responder kommen

Seine Noten fürs Band

Für jede Automation hat er vier einfache Fragen. Ist der Job erledigt? Ist sie mehrfach am selben Pull Request gescheitert? Hat sie sich unnötige Arbeit gemacht, zum Beispiel eine bereits reviewte Änderung noch einmal reviewt? Und gibt es Muster, bei denen Feature Builder oder Bug Fixer immer wieder danebenliegen?

Dazu kommt die Label-Hygiene. Hängt ein Issue mehr als 24 Stunden in Arbeit, markiert er es als festgefahren. Eskalationen, auf die seit über einer Woche keine Antwort kam, ebenso.

Außerdem kann er die Konventionsdateien anpassen, die die anderen Automationen lesen. Das tut er nur, wenn ein Problem klar und wiederholt auftritt.

Die Regel fürs eigene Audit

Abschauen solltet ihr euch etwas viel Kleineres: die Regel, nach der er in seine eigene Audit-Datei schreibt. Existiert für die aktuelle Woche schon ein Audit, ist Überschreiben verboten. Das neue Audit landet unter einem datierten Namen. So stehen zwei Audits derselben Woche nebeneinander, und man kann beide lesen.

Das klingt nach Verwaltung. Doch genau diese Praxis lässt den Rest funktionieren. Wer eine Factory will, die sich selbst verbessert, braucht einen Teil, der das Ganze im Blick hat. Und dieser Teil braucht ein Gedächtnis, das er nicht heimlich umschreiben kann. Überschreibt ein Audit das vorige, bleibt nur die jüngste Meinung übrig.

Die komplette Definition steht in der Konfiguration des Automation Auditor auf GitHub (öffnet in einem neuen Tab).

Wenn bei euch etwas die eigenen Automationen prüft, kann es dann die Regeln ändern, nach denen sie laufen? Und könnt ihr jedes Urteil nachlesen, das es je gefällt hat?

Weiterlesen

Die Artikel der Wissensbasis sind auf Englisch.

• Agent observability →
• Agentic Software Factory: Advanced Team Training →