Nous fabriquons l'un des outils de cette page. Nous avons essayé de décrire les autres selon leur objectif, pas selon leurs manques, et la section sur notre propre produit dit clairement qui ne devrait pas l'utiliser.
Les trois catégories
Widget et page hébergés
Tu écris les entrées dans leur éditeur, ils hébergent la page et te donnent un widget in-app. Le plus rapide à lancer, et les entrées vivent sur leur infrastructure, pas la tienne. Beamer et AnnounceKit en sont les exemples les plus clairs.
Suite de feedback avec changelog intégré
Le changelog est un module à côté du vote de fonctionnalités, d'une roadmap publique et d'une boîte de feedback. Ça vaut le coup si tu veux toute la boucle chez un seul fournisseur, surdimensionné si tu veux seulement publier des release notes. Canny, Frill et Featurebase sont ici.
Généré depuis ton dépôt
Le changelog naît de commits, de pull requests ou d'issues plutôt que d'être écrit à la main. Ça va d'un fichier construit en CI à une entrée rédigée, relue, publiée. git-cliff et github-changelog-generator sont à l'extrémité fichier ; LaunchNotes, Released et notre propre produit à l'extrémité publiée.
En un coup d'œil
| Outil | Type | Idéal pour |
|---|---|---|
| Beamer | Widget hébergé | Mettre en ligne dès cet après-midi un panneau de nouveautés dans l'app, sans mobiliser l'équipe technique. |
| AnnounceKit | Widget hébergé | La même chose, avec plus d'attention au ciblage : qui voit quelle annonce. |
| Canny | Suite de feedback | Les équipes qui veulent du vote de fonctionnalités et une roadmap publique, avec le changelog comme dernière étape de cette boucle. |
| Frill | Suite de feedback | Les petites équipes qui veulent le même principe que Canny, en plus léger. |
| LaunchNotes | Depuis le dépôt | Les grandes organisations qui coordonnent les annonces entre équipes, souvent autour de Jira. |
| Released | Depuis le dépôt | Les équipes qui vivent dans Jira et veulent produire le changelog à partir des issues sans en sortir. |
| git-cliff | Générateur de fichier | Les projets open source qui veulent un CHANGELOG.md construit en CI à partir de conventional commits, sans rien d'hébergé. |
| Changeloop | Depuis le dépôt | Les équipes qui veulent une entrée rédigée à partir des pull requests fusionnées, puis rendue par leur propre front end à partir d'un flux JSON. |
Comment choisir
- Commence par où le changelog doit apparaître. S'il doit ressembler à une partie de ton produit, une page hébergée que tu relies te décevra aussi bon que soit son éditeur ; il te faut alors soit un widget restylisable, soit un flux que tu rends toi-même. Si une page reliée suffit, les outils hébergés demandent beaucoup moins de travail.
- Demande-toi ensuite qui écrit les entrées. Si la réponse est « la personne qui l'a fusionné », choisis quelque chose qui lit ton dépôt, car toute autre solution ajoute une étape manuelle précisément quand tout le monde est occupé. Si la réponse est quelqu'un du marketing produit travaillant à partir d'un plan de sortie, un éditeur convient mieux et l'automatisation depuis le dépôt ne fera que gêner.
- Demande-toi ensuite si tu as besoin du reste de la boucle. Le vote de fonctionnalités et une roadmap publique sont vraiment utiles et représentent vraiment un engagement plus important. Acheter une suite pour son module changelog, c'est comment les équipes finissent par payer pour quatre choses afin d'en utiliser une.
- Vérifie enfin ce qui arrive à tes entrées si tu pars. Un outil qui les exporte comme données structurées est très différent d'un outil où elles vivent dans une page hébergée qu'il faudrait scraper.
Où notre propre outil convient, et où il ne convient pas
Changeloop lit chaque pull request fusionnée, rédige une entrée orientée utilisateur, filtre les montées de dépendances et les refactors, et garde le brouillon pour relecture. Ce qui est publié va sur un flux JSON public avec un flux roadmap à côté, plus un widget de deux lignes et une page hébergée comme solutions de repli. Le flux est l'essentiel : l'idée est que tu rendes ton changelog avec tes propres composants dans ton propre produit.
Ne le choisis pas si :
- Tes versions ne proviennent pas de tes dépôts. Il rédige à partir des fusions ou, en mode push, des pushs, donc une équipe qui livre en dehors d'un flux de travail Git n'a rien à relire.
- Tu veux du vote de fonctionnalités et une roadmap votée par tes utilisateurs. Il y a un flux roadmap, mais il est alimenté par des issues étiquetées, pas par des votes. Pour ça, une suite de feedback est la bonne catégorie.
- Tu veux un éditeur soigné et une page hébergée comme produit principal. La page hébergée existe comme solution de repli, et les outils construits autour de la leur le feront mieux.
- Tu gères seul un projet open source et veux juste un CHANGELOG.md dans le dépôt. Utilise git-cliff, qui est gratuit et fait exactement pour ça.
Questions fréquentes
Avons-nous vraiment besoin d'un outil ?
Pendant un moment, non. Un fichier Markdown, ou une page sur ton propre site, est un changelog parfaitement valable et ne coûte rien. Un outil commence à valoir le coup quand écrire les entrées est l'étape qui saute, ou quand tu veux les mêmes entrées à trois endroits sans maintenir trois copies.
Pouvons-nous quitter l'un de ces outils plus tard ?
Ça dépend entièrement de si les entrées ressortent comme données structurées. Demande-le avant de commencer, pas après : c'est la seule question de cette liste dont la mauvaise réponse coûte cher, car un changelog est une archive qui grandit, et retaper deux ans d'archives n'est pas un projet que quiconque approuve.
Et les écrire avec un assistant IA ?
La plupart de ces outils rédigent désormais avec un modèle en coulisses. Ce qui compte moins que ça, c'est ce qu'on donne au modèle. Un outil qui ne voit qu'un objet de commit ne peut que réécrire cet objet ; un outil qui voit le titre et la description de la pull request a de quoi décrire le changement en termes de ce qu'il apporte à l'utilisateur. Demande quelle est l'entrée, pas s'il y a de l'IA.
Pour aller plus loin : Automatisation du changelog, et ses limites, sur laquelle des quatre étapes devrait être automatique.
Celui qui privilégie le flux
Rédigée à partir de tes pull requests fusionnées, gardée pour relecture, publiée sur un flux JSON que tu rends toi-même. Gratuit pour un dépôt, sans carte.
Commencer gratuitement