Die Gabelwartung automatisieren, eine Aufgabe, die niemand haben möchte

Die meisten Unternehmen, die umfangreiche Software betreiben, verfügen über mindestens einen Fork, den sie am liebsten nicht hätten. Eine Bibliothek, die für eine Anforderung im Upstream gepatcht wurde, würde nicht funktionieren. Eine vom Anbieter bereitgestellte Abhängigkeit mit lokalen Änderungen. Etwas wurde vor drei Jahren aus einem Grund gespalten, den niemand der Anwesenden vollständig erklären kann.

Die Arbeit, sie auf dem neuesten Stand zu halten, ist die Definition einer Aufgabe, die wichtig und niemals dringend ist, was bedeutet, dass sie in Schuldgefühlen geschieht.

Warum diese Aufgabe passt

Die meisten vorgeschlagenen Agentenaufgaben bestehen einen von drei Tests nicht. Dieser überholt sie alle.

Es ist gut spezifiziert. Nehmen Sie die Upstream-Änderungen, wenden Sie sie auf einen Baum mit bekannten lokalen Modifikationen an, lösen Sie die mechanischen Konflikte und führen Sie die Tests durch.

Es hat einen natürlichen Überprüfungspunkt. Die Ausgabe ist eine Pull-Anfrage, und die Überprüfung einer solchen ist bereits etwas, was Ingenieure tun.

Es ist begrenzt. Es gibt einen definierten Satz von Upstream-Commits und einen definierten Baum, sodass der Agent nicht unbegrenzt wandern kann.

Vergleichen Sie das mit „Kundenanfragen bearbeiten“, was bei allen dreien fehlschlägt, und der Unterschied in den Ergebnissen ist nicht rätselhaft.

Was der Agent tun sollte und was nicht

Es sollte die mechanischen Änderungen anwenden, Konflikte lösen, wenn sich die Lösung aus der Struktur der Änderung ergibt, die Testsuite ausführen und eine Beschreibung darüber schreiben, was es getan hat und welche Konflikte es wie gelöst hat.

Es sollte nicht entscheiden, dass ein fehlgeschlagener Test akzeptabel ist, eine lokale Änderung aufgrund eines Konflikts stillschweigend verwerfen oder seinen Anwendungsbereich erweitern, um den Refaktor einzuschließen, den es unterwegs bemerkt hat.

Letzteres ist wichtiger als es klingt. Ein Agent, der Dinge verbessert, die er nicht verbessern sollte, erzeugt Pull-Requests, die schwieriger zu überprüfen sind als die Arbeit, die er ersetzt hat.

Wo die eigentliche Schwierigkeit liegt

Nicht beim Anbringen von Patches. Im Wissen, welche lokalen Veränderungen tragend sind.

Eine Abzweigung häuft Änderungen an, von denen einige absichtlich sind und andere Unfälle sind, die niemand entfernt hat. Ein Agent kann den Unterschied nicht allein am Code erkennen, und eine Konfliktlösung, bei der eine absichtliche Änderung stillschweigend verworfen wird, ist der Fehler, der die meisten Kosten verursacht.

Bei der Schadensbegrenzung handelt es sich um eine Dokumentation der Absicht: eine Aufzeichnung darüber, warum jede lokale Änderung vorhanden ist und zusammen mit der Verzweigung aufbewahrt wird. Organisationen, die dies tun, erzielen wesentlich bessere Ergebnisse, und die Übung, es zu schreiben, ist in der Regel allein schon wertvoll.

Ich bewerte es

Die nützlichen Kriterien sind spezifisch. Hat die Testsuite bestanden? Wurden alle lokalen Änderungen beibehalten oder explizit mit einem Grund als verworfen gekennzeichnet? War der Umfang auf die Upstream-Änderungen beschränkt? Stimmt die Beschreibung mit dem Unterschied überein?

Diese sind alle automatisch überprüfbar, was es Evaluatoren ermöglicht, jeden Lauf zu bewerten, anstatt dass eine Person jeden Lauf mit der gleichen Sorgfalt überprüft.

Das ehrliche Ergebnis

Die Arbeit fällt dadurch nicht weg. Es wandelt es von einem Tag mechanischer Anstrengung in eine Stunde Wiederholung um und macht die Trittfrequenz regelmäßig statt gelegentlich, wo der größte Vorteil liegt. Kleine, häufige Zusammenführungen sind wesentlich einfacher als der jährliche Aufholprozess.

Als nächstes

Auf den Software Factory-Seiten erfahren Sie, wie aus Backlog-Arbeit überprüfungsbereite Pull-Requests werden. Auf den Seiten zum Agent Orchestration System werden Bewertung, Richtlinien und Kostenzuordnung behandelt.