Versione semantica in Agile

Diciamo che ho iterazioni di sprint di 14 giorni in cui ho diverse storie per nuove funzionalità, alcuni miglioramenti e alcuni bug da correggere. Distribuisco anche quei cambiamenti quando sono pronti, non aspetto la fine dello sprint.

Il mio problema è: come tenere traccia delle versioni semantiche dei prodotti sviluppati e gestiti in questo modo? Se ci sarà un rilascio ogni 14 giorni, sarà facile, aumenterò il numero di versione e prenderò nota di tutte le modifiche nel log delle modifiche. Ma cosa succede se le modifiche vengono implementate continuamente? È necessario aumentare la versione ogni volta che viene distribuito qualcosa? O dovrei aspettare fino al termine dello sprint e, successivamente, fare un po '"riprendere" e aumentare il numero di versione una sola volta per iterazione indipendentemente dalla distribuzione effettiva? Quali sono le migliori pratiche per il versioning semantico in Agile?

EDIT: Per spiegare meglio le mie esigenze, voglio in primo luogo il log delle modifiche per le parti interessate. Non credo che saranno interessati a nuovi record nel log delle modifiche dopo ogni modifica implementata.

Per la tipica gestione delle versioni, è necessario che venga generato un numero di build dal proprio sistema di build in modo tale che le DLL vengano aggiornate ogni volta che vengono distribuite. Ciò garantirà in seguito la possibilità di verificare quale versione è distribuita su un determinato server.

La tua versione "marketing", che di solito viene messa nelle note di rilascio o pubblicata sul tuo sito non dovrebbe essere aggiornata ad ogni versione. Le note di rilascio dovrebbero essere accumulate e raggruppate insieme, probabilmente a tempo con la fine dello sprint.

Se lo schema di versione semantico classico "MAJOR.MINOR.PATCH" ha senso, dipende da chi si distribuisce e in particolare quando e con quale frequenza lo si distribuisce all'utente finale . Lo schema è molto utile se lavori con la versione stabile "4.5", dove inizi con 4.5.0. Le versioni 4.5.1, 4.5.2 e così via contengono solo correzioni di errori, mentre già lavori internamente alla versione 4.6.

Ad esempio, se si fornisce un "ramo stabile" all'utente finale, assegnargli una versione 4.5.0 per la distribuzione iniziale e 4.5.1, 4.5.2 ogni volta che si rilascia una patch. Nel tuo sviluppo "agile" interno e nella distribuzione a metà sprint, puoi già avere una versione 4.6, chiamala semplicemente "versione beta". Ogni volta che lo distribuisci a metà sprint, aggiungi il numero di build generato automaticamente come "4.6.beta build 123". Al termine dello sprint, assegnalo "4.6.0" e cambia internamente il numero di versione per lo sprint successivo su "4.7". Iniziare con ".0" è solo una convenzione, è inoltre possibile utilizzare ".0" per contrassegnare le versioni beta e iniziare con ".1" per gli utenti finali. IMHO la parola "beta" è molto più espressiva, dicendo a tutti che lo sprint "non è ancora completato".

Se rilasci un registro delle modifiche completo per l'utente finale con ciascuna versione beta, dipende da te, ma almeno alla fine dello sprint il registro delle modifiche dovrebbe essere completato e ogni volta che fornisci un bugfix all'utente finale, dovresti anche aggiornare i documenti storici.

Troverai la strategia di rilasciare due rami separati, un ramo "stabile" con numeri di versione semantici e un "ramo di sviluppo" contrassegnato con numeri di build o qualcosa di simile, in molti prodotti open source come Inkscape, Firefox o 7-zip.

Se, tuttavia, non lavori con rami stabili e di sviluppo separati e rilasci quotidianamente una nuova versione per l'utente finale, dovresti anche incrementare un numero di versione ogni giorno. In tal caso, i numeri di versione "4.5.1", "4.5.2", ... probabilmente rifletteranno le tue singole implementazioni e non indicheranno la differenza tra correzioni di bug e altre modifiche. Può essere ok, non è più il classico "versioning semantico". In questo scenario, è anche possibile distribuire le versioni 4.5, 4.6, 4.7, 4.8, che non danno alcuna differenza reale.

Per quanto riguarda la tua domanda sulle voci nel tuo registro delle modifiche: IMHO quando qualcosa è visibile all'utente finale, vale la pena inserire una voce nel registro delle modifiche, non appena distribuisci la modifica. Ad esempio, se si utilizza la funzione di attivazione / disattivazione delle modifiche e si apportano modifiche ad alcune funzioni parzialmente cotte che non sono ancora state attivate per l'utente, che non appartengono a un log delle modifiche. Se esegui solo il refactoring, senza modifiche visibili all'utente, ciò non appartiene a un log delle modifiche. Se correggi un bug che potrebbe aver interessato alcuni utenti, questo appartiene sicuramente al log delle modifiche - e dovrebbe essere menzionato lì allo stesso tempo quando distribuisci il bugfix. E non importa se rilasci giornalmente, mensilmente o annualmente.

Vorrei usare i numeri di build. Di solito un numero di build corrisponderebbe alla versione più alta del sistema di controllo della versione. Se il numero di build del lunedì era 1745 e sono state verificate 5 modifiche durante il martedì, il numero di build delle serate di martedì sarebbe 1750.

Quindi fai un breve riassunto di ciò che è cambiato tra il 1745 e il 1750.

Quindi, ogni volta che aggiorni il numero di versione del tuo sistema, puoi aggiungere tutti i brevi riassunti delle build per portare le modifiche dall'ultimo numero di versione al nuovo.

Il mio metodo preferito che uso da almeno alcuni anni è aumentare il numero dopo che ogni storia è stata completata. Ciò significa che le versioni rilasciate alla fine dello sprint non saranno continue, ad esempio dopo 1.2.3 potresti trovare 1.5.2 anziché 1.4.0.

Nel log delle modifiche puoi elencare le versioni intermedie con le relative descrizioni o semplicemente raggruppare tutte le modifiche nella versione "rilasciata" e saltare le versioni intermedie.

Inizialmente, temevo che gli utenti trovassero problematici i "buchi" tra i numeri di versione, ma una volta che ne sono a conoscenza, in pratica non è un problema. Il grande vantaggio è che aumentare il numero dopo ogni storia rende il processo meno soggetto a errori - non è necessario controllare l'intero lavoro da 2 settimane per decidere quale sarà il prossimo numero di versione - quando si guarda una singola storia, è ovvio . Inoltre, i "balzi" nei numeri di versione tra ciascuna versione forniscono una stima approssimativa di quante modifiche sono state apportate alla versione. Tutto sommato, ho trovato che questo sistema funziona bene (questo era con i clienti interni all'azienda, ma se lavori già in un ciclo di rilascio agile dovrebbe funzionare anche per i clienti esterni).