GitHub: der Code erscheint am Vorgang

Eine Story ist „In Bearbeitung“, aber ist der Code dazu schon geschrieben? Liegt ein Pull Request zur Prüfung bereit, oder ist er längst zusammengeführt? Bisher musste man dafür in GitHub suchen oder jemanden fragen. Seit dieser Version zeigt GODAV Pro die Antwort direkt am Vorgang, im neuen Reiter Entwicklung.

Die Verknüpfung selbst ist einfach: Wer den Vorgangsschlüssel in einen Branchnamen, eine Commitnachricht oder einen Pull Request schreibt, hat verknüpft. Hier geht es um die Entscheidungen dahinter.

Solange GitHub den Schlüssel noch nirgends nennt, sagt der Reiter, wie man das ändert.

Eine Verbindung, kein Import

Mein erster Gedanke war, GitHub als zweiten Import neben Targetprocess zu bauen. Die Integrationen waren ja gerade fertig. Das hätte aber nicht gepasst: Ein Import ist ein Lauf, er startet, wird fertig und lässt sich wiederholen. GitHub ist eine stehende Verbindung, die ständig nachliefert. Deshalb hat GitHub eine eigene Kategorie bekommen, und die heißt bewusst Entwicklung und nicht „GitHub“. Käme irgendwann Azure DevOps dazu, gehörte es in dieselbe Gruppe. Aus demselben Grund zeigen die neuen Symbole für Pull Request, Branch und Commit kein Anbieterlogo, sondern die Formen, die jede Versionsverwaltung benutzt.

Ebenso bewusst habe ich GitHub-Issues nicht gespiegelt. Zwei Systeme, die denselben Datensatz pflegen dürfen, streiten sich auf Dauer darum, wer recht hat. In GODAV sind Requests und Vorgänge die Stelle, an der Arbeit erfasst wird, und GitHub ist die Stelle, an der der Code entsteht.

Abruf als Grundlage, Webhook als Beschleunigung

Ein Administrator richtet die Verbindung mit einem persönlichen Zugangstoken oder einer GitHub App ein. Das Token ist in Minuten eingerichtet, gehört aber einem Menschen. Die App gehört der Organisation und überlebt es, wenn derjenige, der sie eingerichtet hat, das Haus verlässt. Deshalb stehen beide Wege zur Wahl.

Jedes Repository gehört genau einem Projekt, und nur dessen Schlüssel werden erkannt.

Die Daten kommen auf zwei Wegen. Die Grundlage ist ein Abruf im Takt, standardmäßig alle fünf Minuten. Er funktioniert überall, auch dort, wo GitHub den Server gar nicht erreichen kann, etwa bei einer Installation im eigenen Haus. Zusätzlich lässt sich ein Webhook einrichten, dann kommen Änderungen binnen Sekunden an. Ohne gültige Signatur nimmt der Server dort nichts an. Ich hätte auch nur auf den Webhook setzen können, das wäre schneller gewesen. Aber eine Funktion, die in der Hälfte der Installationen nicht funktioniert, weil ein Firewall-Eintrag fehlt, ist keine gute Grundlage.

Commits holt GODAV nur vom Standardbranch. Ein Commit auf einem Feature-Branch kommt ohnehin über den Pull Request an, der ihn enthält. Würde ich jeden Branch einzeln abfragen, stünde derselbe Commit nach dem Zusammenführen zweimal am Vorgang. Außerdem gibt es je Repository einen Stichtag: Was davor geschah, wird nicht angesehen, und die Vorgabe ist der Tag, an dem das Repository zugeordnet wurde. Wer mehr sehen will, setzt ihn zurück.

Von Hand, aber nicht gegen den Abruf

Hat jemand den Schlüssel vergessen, verknüpft er einen Pull Request von Hand. GODAV holt Titel und Zustand dann bei GitHub, statt der Eingabe zu glauben. Entfernen lassen sich aber nur Verknüpfungen, die von Hand gesetzt wurden. Eine automatisch erkannte käme beim nächsten Abruf einfach wieder, und ein Papierkorb, dessen Wirkung fünf Minuten hält, ist schlimmer als gar keiner.

Ein Branch aus dem Vorgang

Mit Branch anlegen entsteht ein Branch direkt aus dem Vorgang heraus, abgezweigt vom Standardbranch. Den Namen gibt ein Muster je Repository vor, zum Beispiel Schlüssel und Titel. Der Schlüssel ist darin Pflicht. Ohne ihn würde der Abruf den neuen Branch nicht erkennen, und man sähe am Vorgang nicht, was man gerade selbst angelegt hat.

Branchmuster und Statusautomatik stehen je Repository; ab Werk sind alle drei Regeln aus.

Im selben Dialog stehen die drei Regeln, mit denen ein Branch oder Pull Request den Status eines Vorgangs vorwärts bewegen kann. Eine Feinheit dabei: Eine Regel greift nur, wenn sich in GitHub tatsächlich etwas geändert hat, nicht bei jedem Abruf. Sonst würde ein seit Tagen offener Pull Request eine Story, die jemand bewusst zurückgestellt hat, alle fünf Minuten wieder nach vorn schieben. Die Statuswechsel laufen im Namen dessen, der die Regel gespeichert hat, mit genau dessen Rechten, und stehen ganz normal im Änderungsprotokoll.

Außerdem

• Auf dem Board zeigt ein kleines Symbol, ob zu einer Karte ein Pull Request offen (blau) oder zusammengeführt (grün) ist.
• Zugangsdaten verlassen den Server nicht und werden verschlüsselt abgelegt.
• Der Reiter erscheint nur in Projekten, denen ein Repository zugeordnet ist. Ein leerer Reiter auf jeder Karte wäre ein Versprechen ohne Inhalt.