Qual è il modo migliore per generare un changelog di rilascio accurato?

8

Sto lavorando su alcuni progetti in cui mi piacerebbe fornire un changelog accurato ad ogni rilascio, ma non ho trovato un metodo per raccogliere il log delle modifiche che avrebbe funzionato senza problemi. Il problema è soprattutto quando il tempo tra le versioni è lungo e ogni versione viene fornita con molte funzionalità e correzioni di bug e quando il software ha diversi rami sviluppati contemporaneamente.

Alcune opzioni che ho considerato:

  1. Costruisci il log delle modifiche dai messaggi di commit e richiedi agli sviluppatori di scrivere i messaggi come se stessero scrivendo una riga per il registro delle modifiche (cosa che effettivamente farebbero).
    • Potrebbe non funzionare quando ci sono più filiali e la fusione tra filiali (potrebbe essere difficile sapere quali commit sono finiti nel rilascio).
  2. Richiedere che per ogni modifica del codice ci sia un ticket corrispondente nel sistema di tracciamento dei bug. Il log delle modifiche potrebbe essere scritto in base ai ticket.
    • Gli sviluppatori potrebbero ritenere frustrante effettuare un ticket anche per modifiche minori, soprattutto se il ticket richiede più tempo rispetto alla correzione del bug.
  3. Richiede che gli sviluppatori aggiornino sempre il log delle modifiche (come file di testo nella root del progetto) nello stesso momento in cui apportano modifiche al codice.
    • Sembra che il lavoro manuale possa essere automatizzato.
  4. Chiedere al project manager di prendere il diff della versione corrente e quella precedente e scrivere il log delle modifiche in quel punto in base a ciò che vedono che è stato modificato.
    • Lavoro extra per il responsabile del rilascio e potrebbe non essere ovvio quale effetto pratico di un cambiamento è semplicemente guardando il codice.
  5. Spedire solo le funzionalità che sono state pianificate per il rilascio; puoi scrivere il registro delle modifiche anche prima di iniziare la codifica.
    • Non è un'opzione reale a meno che tu non stia utilizzando il modello a cascata.

Ho usato ognuno di questi o una loro variazione in passato, ma sono stati troppo inaffidabili, laboriosi o rigidi. Qualcuno ha una bacchetta magica o buone idee su come risolvere il problema?

    
posta JJJ 05.10.2011 - 17:15
fonte

3 risposte

6

Se non hai già il requisito di un ticket per ogni modifica, ottenere gli sviluppatori per creare un ticket per ogni modifica abbastanza importante da finire nel registro delle modifiche sembra ragionevole.

Se il cambiamento è abbastanza significativo da dire agli utenti, allora probabilmente vorrai apportare quel cambiamento sotto un biglietto in ogni caso, e scrivere biglietti descrittivi è una buona pratica. Inoltre puoi legare questo con qualsiasi versione di versione e roadmap che supporta il bug tracker.

    
risposta data 05.10.2011 - 17:40
fonte
0

Feels like manual labor that could be automated.

Come potrebbe essere automatizzato? Non è necessario modificare il log delle modifiche su ogni commit, ma solo quando viene aggiunta una feature che vale la pena menzionare. Succede così spesso sul tuo software che è una seccatura aggiungere una riga al log delle modifiche ogni volta?

    
risposta data 05.10.2011 - 17:23
fonte
0

Potresti dire che questo è il dovere del QA di mantenere aggiornato il log delle modifiche, ma alcuni sistemi di gestione della configurazione del software o tracker di problemi possono generare automaticamente il log delle modifiche, che è utile in un ambiente di sviluppo multiplo. Ciò presuppone che tu stia utilizzando il monitoraggio di funzionalità / problema nel modo previsto.

Ad esempio, il tracker dei problemi open source Trac ha un ChangeLogMacro .

Altri tracker di problemi potrebbero avere una macro o un plug-in che può generare il log delle modifiche per te. Di solito è una semplice query per selezionare tutti i ticket / problemi che sono stati chiusi tra l'ultima versione e la versione corrente.

    
risposta data 05.10.2011 - 17:38
fonte

Leggi altre domande sui tag