L'intera confusione deriva dalla diversa semantica che MS utilizza per "Build number" e in particolare "Revision". I termini significano solo cose diverse.
La maggior parte delle persone (me compreso) utilizza uno schema di numerazione delle versioni semantico in cui si ottiene semplicemente un numero BUILD più elevato ogni volta che è necessario creare una nuova build per qualsiasi motivo. Per noi, un aggiornamento rapido è considerato solo un'altra modifica del codice e la parte BUILD aumenta automaticamente ad ogni esecuzione di CI. I moduli con lo stesso MAJ.MIN.REV sono considerati intercambiabili e BUILD ti dice quale è il più recente.
La REVISIONE in aumento, tuttavia, indica un nuovo ramo di rilascio permanente, ecco perché lo posizioniamo prima di BUILD. L'aspetto negativo di questo approccio è che potremmo ottenere la seguente sequenza di eventi:
- numero di commit 4711: Alice ha aggiunto la funzione A
- CI produce la build 1.2.3.100
- numero di commit 4712: Bob ha modificato la funzione B
- numero di commit 4713: Alice ha risolto la funzione A ("hotfix")
- CI produce la build 1.2.3.101
Come puoi vedere, l'aggiornamento rapido non è l'unica modifica contenuta nella build successiva, ma anche la modifica di Bob diventa parte di quella build. Se si desidera stabilizzare il ramo corrente, è possibile che si verifichino problemi poiché non si è mai sicuri se Bob abbia aggiunto o meno un mucchio di bug.
MS utilizza entrambi i termini in modo diverso. Il numero BUILD non viene incrementato automaticamente, ma può essere considerato come una specie di ramo di rilascio, per bloccare il codice utilizzato per una particolare versione del codice. REVISION indica ulteriori modifiche "attive" applicate a quel ramo BUILD. La sequenza sarebbe quindi la seguente:
- numero di commit 4711: Alice ha aggiunto la funzione A al trunk / master
- Carl crea il ramo build
1.2.100
- CI produce build 1.2.100.0
- numero di commit 4712: Bob ha modificato la funzione B nel trunk / master
- numero di commit 4713: Alice ha corretto la funzione A nel
1.2.100ramo
- CI produce la build 1.2.100.1
Il termine REVISIONE può riferirsi a
- una revisione del prodotto (è così che la maggior parte delle persone lo usa)
- una revisione di una particolare build giornaliera (ecco cosa fa la SM)
La differenza chiave tra i due processi è, indipendentemente dal fatto che si desideri o meno la possibilità di applicare gli hotfix ai build degli elementi della configurazione e, quindi, a che punto del processo viene creato il ramo. Questo aspetto diventa importante quando vuoi essere in grado di scegliere una particolare build in qualsiasi momento dopo che tutti i test hanno avuto successo e promuovere esattamente quella versione alla prossima versione ufficiale del tuo prodotto.
Nel nostro caso lo strumento CI crea un tag repository, quindi abbiamo sempre le informazioni necessarie pronte per l'uso, quando necessario. Con SVN diventa ancora più semplice, perché i tag e i rami sono implementati esattamente allo stesso modo: un tag non è altro che un ramo situato sotto /tags.
Guarda anche
Dalla sezione FAQ della strategia di diramazione TFS :
In quale ramo devo riparare il ticket P1 (hotfix)?
Il P1 dovrebbe essere corretto nel ramo più vicino alla base di codice in esecuzione in Produzione. In questo caso il P1 dovrebbe essere riparato nel ramo Prod. Applicando la correzione in qualsiasi altra filiale e implementando le modifiche alla produzione, si rischia di rilasciare codice semilavorato o non testato dalle successive iterazioni.
Ora puoi discutere se è sicuro lavorare direttamente contro il ramo Prod, ripensaci, un P1 che richiede attenzione immediata non dovrebbe essere un problema fondamentale nel sistema. Nel caso in cui si tratti di un problema fondamentale, è necessario aggiungerlo all'arretrato di prodotto poiché potrebbe richiedere ulteriori analisi e discussioni con il cliente.
Un'altra buona lettura è la guida alle ramificazioni TFS