Von gemergten Pull Requests zum veröffentlichten Changelog
Okou liest die Pull Requests, die ihr diese Woche gemergt habt, behält die nutzerrelevanten, schreibt den Changelog-Beitrag und veröffentlicht ihn nach eurer Freigabe im selben Lauf auf dem Blog, über Resend und auf X.
Was ist Changelog-Automatisierung?
Changelog-Automatisierung heißt, das Produkt-Update aus der Arbeit zu erzeugen, die euer Team tatsächlich gemergt hat, statt es am Ende der Woche aus dem Gedächtnis zu schreiben. Okou ist der Agent dazwischen: Er liest gemergte Pull Requests in GitHub, behält die nutzerrelevanten, gruppiert sie zu Themen, schreibt den Changelog-Beitrag und veröffentlicht ihn in einem Lauf auf dem Blog, als Resend-Newsletter und als X-Thread. Das Ergebnis ist ein wöchentliches Produkt-Update, das pünktlich erscheint und auf jedem Kanal dasselbe sagt.
Warum der wöchentliche Changelog einen Freitag frisst
Freitagnachmittag. Diese Woche wurden gut dreißig Pull Requests gemergt, und jemand muss daraus ein Update machen, das Leute tatsächlich lesen. Man überfliegt die Merge-Liste, rät, welche Änderungen nutzerrelevant sind, schreibt den Beitrag, kürzt ihn für die Mail, kürzt ihn nochmal für X und kopiert jede Fassung in ein anderes Tool. Dreimal dieselbe Lektüre, und was auf X landet, sagt meistens etwas anderes als das, was im Postfach ankam.
Wie Okou aus einer Woche Merges einen veröffentlichten Changelog macht
Schritt 1: Tools verbinden
Schritt 2: Okou fragen
Schritt 3: Weiterführende Aktionen
GitHub-, Resend-, X- und Slack-Integration für die Changelog-Automatisierung
Dieser Workflow liest aus einem Tool und schreibt in drei. GitHub ist die einzige Quelle dafür, was ausgeliefert wurde; Resend und X sind Ziele; Slack ist der Ort, an dem der Entwurf auf einen Menschen wartet. Jeder Connector wird einzeln freigegeben und auf das beschränkt, was der Workflow tatsächlich nutzt. Lesezugriff auf euer Repository bedeutet also nie das Recht, aus eurem Konto zu posten.
GitHub-Integration: was Okou für den Changelog liest
ErforderlichOkou fragt die Pull Requests ab, die im gewählten Zeitraum in die genannten Repositories gemergt wurden, und liest zu jedem Titel, Beschreibung, Labels, Merge-Zeitpunkt, Autor und die geänderten Dateipfade. Diese fünf Signale trennen eine nutzerrelevante Änderung von einem internen Refactoring: Ein Release-Notiz-Label ist das stärkste, die geänderten Pfade fangen die ungelabelten ab, und die Beschreibung liefert die Details, die der Titel auslässt. In diesem Workflow ist die GitHub-Integration schreibgeschützt. Okou legt keine Issues an, pusht keine Commits und bearbeitet keine Pull Requests. Nennt ihr mehrere Repositories, liest Okou sie im selben Durchlauf, sodass getrenntes Frontend und Backend trotzdem einen einzigen Changelog ergeben.
Resend-Integration: der Newsletter, den Okou verschickt
ErforderlichOkou liest eure Resend-Zielgruppen, damit ihr die gewünschte über den Namen statt über eine ID ansprechen könnt, und erstellt und versendet dann die Kampagne: Betreff, Preheader, HTML-Text und Nur-Text-Variante. Nach dem Versand liest Okou das Ergebnis zurück und meldet, wie viele Nachrichten zugestellt, zurückgestellt und abgewiesen wurden. Deshalb widersprechen sich Report und Kampagne nie. Versandrechte werden getrennt vom Lesezugriff auf Zielgruppen erteilt, und Okou fügt niemals Kontakte hinzu, entfernt oder exportiert sie.
X-Integration: der Thread, den Okou postet
ErforderlichDer Thread ist für X geschrieben, nicht aus dem Blogbeitrag gekürzt: ein Beitrag pro Thema, ein Auftakt, der sagt, was sich geändert hat, und ein Abschluss, der auf den vollständigen Text verlinkt. Okou postet jeden Eintrag als Antwort auf den vorherigen, damit der Thread zusammenhält, und prüft die Länge vor dem Posten, statt einen Beitrag abschneiden zu lassen. Der Schreibzugriff ist auf das verbundene Konto beschränkt, und mehr als den Thread zu posten tut Okou nicht. Timeline, Erwähnungen und Direktnachrichten liest Okou nicht.
Slack-Integration: wo der Entwurf auf die Freigabe wartet
OptionalSlack ist optional und verdient sich seinen Platz beim Freigabeschritt. Okou postet den vollständigen Entwurf in den genannten Kanal, inklusive Blogtext, Betreffzeile und jedem Beitrag des Threads, und hält dann an. Nichts wird veröffentlicht, bevor jemand freigibt, und ihr könnt im selben Thread eine Überarbeitung anfordern und bekommt den aktualisierten Entwurf an Ort und Stelle. Ohne Slack läuft der Workflow trotzdem vollständig durch; der Entwurf kommt dann dort zurück, wo ihr den Lauf gestartet habt.
Okou im Vergleich zu Handarbeit und zu einem Changelog-Generator
Changelog-Automatisierung zerfällt in zwei Probleme: zu entscheiden, was eine Ankündigung wert ist, und diese Ankündigung auf jeden Kanal zu bringen. Die meisten Tools lösen nur eines davon.
Von Hand geschrieben
Jemand liest die Merge-Liste, entscheidet, was zählt, schreibt den Beitrag und formuliert ihn zweimal für Mail und X neu. Das Urteil ist gut und der Text sitzt, aber es kostet jede Woche dieselben 90 Minuten und fällt in einer vollen Woche als Erstes weg.
Ein Changelog-Generator
Commit- oder Pull-Request-Titel landen automatisch auf einer Release-Notes-Seite. Kein Merge geht verloren, aber veröffentlicht werden Titel statt Themen, ein Refactoring lässt sich nicht von einem Feature unterscheiden, und es bleibt bei einem Ziel.
Okous Changelog-Workflow
Okou liest dieselben Merges, wendet eure Regel für nutzerrelevant an, gruppiert den Rest zu Themen und schreibt den Text pro Kanal. Blog, Resend und X werden aus einem freigegebenen Entwurf in einem Lauf veröffentlicht, und der Lauf meldet, was zurückgehalten wurde und warum.
Tipps für bessere Ergebnisse
Häufige Fragen
Wie automatisiert man einen Changelog aus GitHub-Pull-Requests?
Verbindet GitHub mit Okou und gebt einen Zeitplan oder einen Release-Auslöser vor. Okou liest die im Zeitraum gemergten Pull Requests, filtert sie mit eurer Regel für nutzerrelevante Änderungen, gruppiert den Rest zu Themen und schreibt den Changelog-Beitrag. Kommen Resend und X dazu, veröffentlicht derselbe Lauf ihn auch auf diesen Kanälen.
Woran erkennt Okou, welche Merges nutzerrelevant sind?
An der Regel, die ihr vorgebt, angewandt auf vier Signale: das Release-Notiz-Label, die geänderten Dateipfade, den Titel des Pull Requests und seine Beschreibung. Ein Label ist das stärkste Signal und das, worauf sich die meisten Teams festlegen. Alles, was Okou ausschließt, steht mit Begründung im Report des Laufs, sodass eine falsche Einschätzung sichtbar wird statt still zu verschwinden.
Lässt sich ein Entwurf gleichzeitig als Newsletter und auf X veröffentlichen?
Ja. Okou schreibt die Themen einmal und passt sie dann pro Kanal an: den Beitrag in voller Länge auf dem Blog, die Mail in Postfachlänge mit Betreff und Preheader und einen Thread mit einem Beitrag pro Thema. Alle drei erscheinen im selben Lauf aus demselben freigegebenen Entwurf, sodass die Fakten zwischen den Kanälen nicht auseinanderlaufen können.
Wird etwas ohne meine Freigabe veröffentlicht?
Nur wenn ihr es so wollt. Standardmäßig postet Okou den Entwurf in einen Kanal und wartet. Ihr könnt freigeben, im selben Thread eine Überarbeitung anfordern oder ihn verwerfen. Soll es unbeaufsichtigt veröffentlicht werden, schreibt das in den Prompt, und Okou überspringt den Freigabeschritt.
Welche Tools braucht diese Changelog-Automatisierung?
GitHub ist als Quelle dafür erforderlich, was ausgeliefert wurde. Resend und X sind als die beiden Veröffentlichungsziele erforderlich. Slack ist optional und wird nur für den Freigabeschritt genutzt; ohne Slack kommt der Entwurf dort zurück, wo ihr den Lauf gestartet habt.
Welche Berechtigungen braucht dieser Workflow?
GitHub braucht Lesezugriff auf die Repositories, aus denen ihr veröffentlicht. Resend braucht Versandrechte und Lesezugriff auf die Zielgruppen. X braucht Schreibzugriff auf das Konto, das den Thread postet. Slack braucht, falls genutzt, das Recht, im Freigabekanal zu posten. Jeder Connector wird in Okou einzeln freigegeben, und ein Widerruf lässt die anderen unberührt.
Kann Okou einen Changelog aus mehreren Repositories bauen?
Ja. Nennt jedes Repository im Prompt, dann liest Okou sie im selben Durchlauf und gruppiert die Änderungen danach, welches Verhalten sich ändert, nicht danach, aus welchem Repository sie stammen. Getrenntes Frontend und Backend ergeben trotzdem einen Beitrag.
Kann ich ihn statt wöchentlich per Release-Tag auslösen?
Ja. Legt eine Automatisierung an, die den Workflow startet, sobald in GitHub ein Release getaggt wird. Okou baut den Changelog dann aus den Pull Requests dieses Releases statt aus einem Zeitfenster, der Rest des Laufs bleibt identisch.
Veröffentlicht den Changelog dieser Woche
Verbindet GitHub, Resend und X und nutzt den Wochen-Prompt, um den ganzen Lauf zu sehen: prüfen, gruppieren, entwerfen, freigeben, veröffentlichen.