Eines der Werkzeuge auf dieser Seite stammt von uns. Wir haben versucht, die anderen danach zu beschreiben, wofür sie gebaut sind, statt danach, wo sie zurückfallen, und der Abschnitt zu unserem eigenen Produkt sagt deutlich, wer es nicht nehmen sollte.
Die drei Kategorien
Gehostetes Widget und gehostete Seite
Sie schreiben Einträge in deren Editor, sie hosten die Seite und geben Ihnen ein In-App-Widget. Am schnellsten startklar, und die Einträge liegen auf deren Infrastruktur statt auf Ihrer. Beamer und AnnounceKit sind die deutlichsten Beispiele.
Feedback-Suite mit angehängtem Changelog
Das Changelog ist ein Modul neben Feature-Voting, einer öffentlichen Roadmap und einem Feedback-Postfach. Lohnend, wenn Sie die ganze Schleife von einem Anbieter wollen, überdimensioniert, wenn Sie nur Release Notes veröffentlichen möchten. Canny, Frill und Featurebase gehören hierher.
Aus Ihrem Repository erzeugt
Das Changelog entsteht aus Commits, Pull Requests oder Issues statt von Hand getippt zu werden. Die Spanne reicht von einer in der CI gebauten Datei bis zum entworfenen, geprüften, veröffentlichten Eintrag. git-cliff und github-changelog-generator stehen am Datei-Ende; LaunchNotes, Released und unser eigenes Produkt am veröffentlichten Ende.
Auf einen Blick
| Werkzeug | Art | Am besten für |
|---|---|---|
| Beamer | Gehostetes Widget | Noch heute Nachmittag ein In-App-Panel mit Neuigkeiten live bringen, ganz ohne Entwicklungszeit. |
| AnnounceKit | Gehostetes Widget | Dasselbe, mit mehr Augenmerk darauf, wer welche Ankündigung zu sehen bekommt. |
| Canny | Feedback-Suite | Teams, die Feature-Voting und eine öffentliche Roadmap wollen, mit dem Changelog als letztem Schritt dieser Schleife. |
| Frill | Feedback-Suite | Kleinere Teams, die dasselbe Prinzip wie Canny wollen, nur schlanker. |
| LaunchNotes | Aus dem Repository | Größere Organisationen, die Ankündigungen über Teams hinweg abstimmen, oft mit Jira als Mittelpunkt. |
| Released | Aus dem Repository | Teams, die in Jira leben und das Changelog aus Issues erzeugen wollen, ohne Jira zu verlassen. |
| git-cliff | Datei-Generator | Open-Source-Projekte, die eine CHANGELOG.md aus Conventional Commits in der CI bauen wollen, ganz ohne gehosteten Dienst. |
| Changeloop | Aus dem Repository | Teams, die den Eintrag aus gemergten Pull Requests entwerfen lassen und ihn dann mit ihrem eigenen Frontend aus einem JSON-Feed rendern wollen. |
Wie Sie wählen
- Beginnen Sie damit, wo das Changelog erscheinen muss. Wenn es wie ein Teil Ihres Produkts aussehen soll, wird eine gehostete Seite, die Sie verlinken, Sie enttäuschen, so gut ihr Editor auch ist; dann wollen Sie entweder ein Widget, das Sie umgestalten können, oder einen Feed, den Sie rendern. Reicht eine verlinkte Seite, sind die gehosteten Werkzeuge deutlich weniger Aufwand.
- Fragen Sie dann, wer die Einträge schreibt. Lautet die Antwort „die Person, die es gemergt hat“, nehmen Sie etwas, das Ihr Repository liest, denn alles andere fügt genau dann einen manuellen Schritt hinzu, wenn alle beschäftigt sind. Lautet die Antwort „eine Person im Produktmarketing, die nach Releaseplan arbeitet“, passt ein Editor besser, und Repository-Automatisierung steht nur im Weg.
- Fragen Sie dann, ob Sie den Rest der Schleife brauchen. Feature-Voting und eine öffentliche Roadmap sind wirklich nützlich und wirklich eine größere Verpflichtung. Eine Suite wegen ihres Changelog-Moduls zu kaufen ist der Weg, auf dem Teams am Ende vier Dinge bezahlen, um eines zu nutzen.
- Prüfen Sie zuletzt, was mit Ihren Einträgen passiert, wenn Sie gehen. Ein Werkzeug, das sie als strukturierte Daten exportiert, unterscheidet sich grundlegend von einem, bei dem sie in einer gehosteten Seite liegen, die Sie scrapen müssten.
Wo unser eigenes Werkzeug passt, und wo nicht
Changeloop liest jeden gemergten Pull Request, entwirft daraus einen Eintrag für Nutzende, sortiert Dependency-Bumps und Refactorings aus und hält den Entwurf zur Durchsicht bereit. Was veröffentlicht wird, geht in einen öffentlichen JSON-Feed mit einem Roadmap-Feed daneben, dazu ein zweizeiliges Widget und eine gehostete Seite als Rückfalloptionen. Der Feed ist der Punkt: Vorgesehen ist, dass Sie Ihr Changelog mit Ihren eigenen Komponenten in Ihrem eigenen Produkt rendern.
Nehmen Sie es nicht, wenn:
- Ihre Releases nicht aus Ihren Repositories kommen. Es erstellt Entwürfe aus Merges oder, im Push-Modus, aus Pushes, ein Team, das außerhalb eines Git-Workflows ausliefert, bekommt also nichts zum Durchsehen.
- Sie Feature-Voting und eine Roadmap wollen, über die Ihre Nutzenden abstimmen. Es gibt einen Roadmap-Feed, aber er wird aus beschrifteten Issues gespeist, nicht aus Abstimmungen. Dafür ist eine Feedback-Suite die richtige Kategorie.
- Sie einen ausgefeilten Editor und eine gehostete Seite als Hauptprodukt wollen. Die gehostete Seite gibt es als Rückfalloption, und die Werkzeuge, die um ihre herum gebaut sind, machen das besser.
- Sie ein Open-Source-Projekt allein betreiben und einfach eine CHANGELOG.md im Repository möchten. Nehmen Sie git-cliff, das ist kostenlos und genau dafür gemacht.
Häufige Fragen
Brauchen wir überhaupt ein Werkzeug?
Eine ganze Weile nicht. Eine Markdown-Datei oder eine Seite auf Ihrer eigenen Website ist ein völlig brauchbares Changelog und kostet nichts. Ein Werkzeug beginnt sich zu lohnen, wenn das Schreiben der Einträge der Schritt ist, der ausfällt, oder wenn Sie dieselben Einträge an drei Stellen möchten, ohne drei Kopien zu pflegen.
Können wir später wieder von einem dieser Werkzeuge weg?
Das hängt vollständig davon ab, ob die Einträge wieder als strukturierte Daten herauskommen. Fragen Sie vorher, nicht hinterher: Das ist die eine Frage dieser Liste, deren falsche Antwort teuer ist, denn ein Changelog ist ein wachsendes Archiv, und zwei Jahre davon abzutippen ist kein Projekt, das jemand genehmigt.
Und Release Notes mit einem KI-Assistenten schreiben?
Die meisten dieser Werkzeuge entwerfen inzwischen irgendwo mit einem Modell. Wichtiger als das ist, was das Modell zu sehen bekommt. Ein Werkzeug, das nur eine Commit-Betreffzeile sieht, kann auch nur diese Betreffzeile umformulieren; eines, das Titel und Beschreibung des Pull Requests sieht, hat genug, um die Änderung danach zu beschreiben, was sie für Nutzende bewirkt. Fragen Sie nach der Eingabe, nicht danach, ob KI drinsteckt.
Weiterlesen: Changelog-Automatisierung und ihre Grenzen, dazu, welcher der vier Schritte automatisch laufen sollte.
Die Feed-zuerst-Variante
Entworfen aus Ihren gemergten Pull Requests, zur Durchsicht zurückgehalten, veröffentlicht in einen JSON-Feed, den Sie selbst rendern. Kostenlos für ein Repository, ohne Karte.
Kostenlos starten