Uno degli strumenti di questa pagina lo facciamo noi. Abbiamo cercato di descrivere gli altri per ciò per cui sono costruiti, non per dove sono carenti, e la sezione sul nostro prodotto dice chiaramente chi non dovrebbe usarlo.
Le tre categorie
Widget e pagina ospitati
Scrivi le voci nel loro editor, loro ospitano la pagina e ti danno un widget in-app. Il più rapido da avviare, e le voci vivono sulla loro infrastruttura, non sulla tua. Beamer e AnnounceKit sono gli esempi più chiari.
Suite di feedback con changelog incluso
Il changelog è un modulo accanto alla votazione delle funzioni, una roadmap pubblica e una casella di feedback. Vale la pena se vuoi tutto il ciclo da un solo fornitore, sovradimensionato se vuoi solo pubblicare release notes. Canny, Frill e Featurebase stanno qui.
Generato dal tuo repository
Il changelog nasce da commit, pull request o issue invece che scritto a mano. Va da un file costruito nella CI a una voce redatta, rivista, pubblicata. git-cliff e github-changelog-generator stanno all'estremo del file; LaunchNotes, Released e il nostro prodotto all'estremo pubblicato.
Colpo d'occhio
| Strumento | Tipo | Ideale per |
|---|---|---|
| Beamer | Widget ospitato | Mettere online già oggi pomeriggio un pannello di novità nell'app, senza tempo di sviluppo. |
| AnnounceKit | Widget ospitato | Lo stesso, con più attenzione a segmentare chi vede quale annuncio. |
| Canny | Suite di feedback | Team che vogliono la votazione delle funzioni e una roadmap pubblica, con il changelog come passo finale di quel ciclo. |
| Frill | Suite di feedback | Team più piccoli che vogliono la stessa impostazione di Canny, ma più leggera. |
| LaunchNotes | Dal repository | Organizzazioni più grandi che coordinano gli annunci tra team, spesso con Jira come riferimento. |
| Released | Dal repository | Team che vivono in Jira e vogliono il changelog prodotto dalle issue senza uscirne. |
| git-cliff | Generatore di file | Progetti open source che vogliono un CHANGELOG.md costruito da conventional commits nella CI, senza nulla di ospitato. |
| Changeloop | Dal repository | Team che vogliono la voce redatta dalle pull request unite e poi renderizzata dal proprio front end a partire da un feed JSON. |
Come scegliere
- Inizia da dove deve apparire il changelog. Se deve sembrare parte del tuo prodotto, una pagina ospitata da collegare ti deluderà per quanto sia buono l'editor; allora vuoi o un widget ristilizzabile o un feed che renderizzi tu. Se una pagina collegata va bene, gli strumenti ospitati sono molto meno lavoro.
- Chiediti poi chi scrive le voci. Se la risposta è «chi l'ha unito», scegli qualcosa che legga il tuo repository, perché qualsiasi altra cosa aggiunge un passaggio manuale proprio quando tutti sono impegnati. Se la risposta è qualcuno del marketing di prodotto che lavora da un piano di rilasci, un editor si adatta meglio e l'automazione dal repository sarà solo d'intralcio.
- Chiediti poi se ti serve il resto del ciclo. La votazione delle funzioni e una roadmap pubblica sono davvero utili e davvero un impegno maggiore. Comprare una suite per il suo modulo di changelog è il modo in cui i team finiscono per pagare quattro cose per usarne una.
- Controlla infine cosa succede alle tue voci se te ne vai. Uno strumento che le esporta come dati strutturati è molto diverso da uno in cui vivono in una pagina ospitata che dovresti scrapare.
Dove si adatta il nostro strumento, e dove no
Changeloop legge ogni pull request unita, redige una voce rivolta all'utente, filtra aggiornamenti di dipendenze e refactor, e trattiene la bozza per la revisione. Ciò che viene pubblicato va su un feed JSON pubblico con un feed di roadmap accanto, più un widget di due righe e una pagina ospitata come alternative. Il feed è il punto centrale: l'idea è che tu renderizzi il tuo changelog con i tuoi componenti nel tuo prodotto.
Non sceglierlo se:
- I tuoi rilasci non nascono dai tuoi repository. Redige a partire dalle unioni oppure, in modalità push, dai push, quindi un team che rilascia al di fuori di un flusso di lavoro Git non ha nulla da rivedere.
- Vuoi la votazione delle funzioni e una roadmap votata dai tuoi utenti. C'è un feed di roadmap, ma è alimentato da issue etichettate, non da voti. Per questo, una suite di feedback è la categoria giusta.
- Vuoi un editor curato e una pagina ospitata come prodotto principale. La pagina ospitata esiste come alternativa, e gli strumenti costruiti attorno alla propria lo faranno meglio.
- Gestisci da solo un progetto open source e vuoi solo un CHANGELOG.md nel repository. Usa git-cliff, che è gratis e fatto proprio per questo.
Domande frequenti
Ci serve davvero uno strumento?
Per un po', no. Un file Markdown, o una pagina sul tuo sito, è un changelog perfettamente valido e non costa nulla. Uno strumento inizia a valere la pena quando scrivere le voci è il passaggio che salta, o quando vuoi le stesse voci in tre posti senza mantenere tre copie.
Possiamo lasciare in seguito uno di questi strumenti?
Dipende interamente dal fatto che le voci escano di nuovo come dati strutturati. Chiedilo prima di iniziare, non dopo: è l'unica domanda di questa lista la cui risposta sbagliata costa cara, perché un changelog è un archivio che cresce, e riscrivere due anni di esso non è un progetto che qualcuno approva.
E scriverle con un assistente IA?
La maggior parte di questi strumenti ormai redige con un modello da qualche parte. Conta meno questo di cosa viene dato in pasto al modello. Uno strumento che vede solo l'oggetto di un commit può solo riscrivere quell'oggetto; uno che vede titolo e descrizione della pull request ha abbastanza per descrivere il cambiamento in termini di cosa fa per l'utente. Chiedi qual è l'input, non se c'è l'IA.
Per continuare a leggere: Automazione del changelog, e i suoi limiti, su quale dei quattro passaggi dovrebbe essere automatico.
Quella che dà priorità al feed
Redatta dalle tue pull request unite, trattenuta per la revisione, pubblicata su un feed JSON che renderizzi tu. Gratis per un repository, nessuna carta.
Inizia gratis