Versioning semantico in Agile

Per la tipica gestione delle versioni, è necessario che un numero di build venga generato dal sistema di generazione in modo che le DLL vengano sottoposte a versione ogni volta che vengono distribuite. Ciò assicurerà che tu possa in seguito verificare quale versione è distribuita su un determinato server.

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

Se il classico schema di controllo delle versioni semantiche "MAJOR.MINOR.PATCH" ha senso, dipende da chi viene distribuito e, soprattutto, quando e quanto spesso viene distribuito a l'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 bug, mentre internamente si lavora già alla versione 4.6.

Ad esempio, se fornisci un "ramo stabile" al tuo utente finale, dagli una versione 4.5.0 per la distribuzione iniziale e 4.5.1, 4.5.2 ogni volta che rilasci una patch. Nel tuo sviluppo "agile" interno e nella distribuzione mid-sprint, puoi già avere una versione 4.6, chiamala semplicemente "versione beta". Ogni volta che lo si distribuisce in mid-sprint, aggiungere il numero di build generato automaticamente come "4.6.beta build 123". Al termine dello sprint, assegnarlo a "4.6.0" e passare internamente il numero di versione dello sprint successivo a "4.7". A partire da ".0" è solo una convenzione, puoi anche utilizzare ".0" per codificare le versioni beta e iniziare con ".1" per gli utenti finali. IMHO la parola "beta" è molto più espressiva, dicendo a tutti lo sprint "non è ancora completato".

Se pubblichi un registro modifiche completo per utente finale con ciascuna versione beta, ma almeno alla fine dello sprint il registro delle modifiche dovrebbe essere completato e ogni volta che fornisci un bugfix all'utente finale, dovrebbe anche aggiornare i documenti della cronologia.

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 una nuova versione ogni giorno all'utente finale, dovresti anche incrementare un numero di versione ogni giorno. In questo caso, i numeri di versione "4.5.1", "4.5.2", ... probabilmente rifletteranno le vostre distribuzioni individuali e non indicano la differenza tra correzioni di errori e altre modifiche. Questo può essere ok, non è più solo la classica "versione semantica". In questo scenario, puoi anche distribuire le versioni 4.5, 4.6, 4.7, 4.8, che non danno alcuna vera differenza.

Per quanto riguarda la tua domanda sulle voci nel tuo log delle modifiche: IMHO quando qualcosa è visibile all'utente finale, vale la pena entrare nel log delle modifiche, non appena si distribuisce la modifica. Ad esempio, se si utilizzano i selettori di funzionalità e si apportano modifiche ad alcune funzionalità semi-cotte che non sono ancora state attivate all'utente, ciò non appartiene a un log delle modifiche. Se fai solo il refactoring, senza modifiche visibili all'utente, questo non appartiene a un log delle modifiche. Se correggi un bug che potrebbe aver influito su alcuni utenti, questo appartiene sicuramente al changelog - e dovrebbe essere menzionato lì allo stesso tempo quando si distribuisce il bugfix. E non importa se pubblichi quotidianamente o mensilmente o annualmente.

Vorrei usare i numeri di build. Di solito un numero di build corrisponde alla versione più alta del sistema di controllo della versione. Se il numero di build del lunedì era il 1745 e sono stati controllati 5 cambi durante il martedì, il numero di build di martedì sera sarebbe il 1750.

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

Quindi ogni volta che aggiorni il numero di versione del tuo sistema puoi sommare tutti i brevi riassunti dai build per ottenere le modifiche dall'ultimo numero di versione al nuovo.

Il mio metodo preferito che uso da almeno qualche anno è quello di aumentare il numero dopo che ogni storia è stata completata. Ciò significa che le versioni rilasciate alla fine dello sprint non saranno continue, ad es. dopo 1.2.3 potresti trovare 1.5.2 invece di 1.4.0.

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

Inizialmente, temevo che gli utenti trovassero problematici i "buchi" tra 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 devi controllare l'intero lavoro da 2 settimane per decidere quale sarà il prossimo numero di versione - quando guardi una singola storia, è ovvio . Inoltre, i "salti" nei numeri di versione tra ogni versione danno una stima approssimativa del numero di modifiche apportate alla versione. Tutto sommato, ho trovato che questo sistema funzionava bene (era con i clienti interni dell'azienda, ma se lavori già in un ciclo di rilascio agile dovrebbe funzionare anche per i clienti esterni).