Come versione quando si utilizza lo sviluppo basato su trunk

2

Ho letto un po 'di più sullo sviluppo basato su trunk, la mia azienda attualmente utilizza principalmente il modello git flow e ho avuto una domanda riguardante i commit che si verificano sul trunk e su come sono versionati.

Utilizzerò il post di Paul Hammant blog per provare e mantenere la domanda meno soggettiva. Quindi di seguito abbiamo il modello di ramificazione dal suo post sul blog

Sonointeressatoaquale"versione" ciascuno dei commit verdi genera dal trunk. Esemplare dopo il cherry pick per generare 1.1.1 ci sono circa 15 commit sul trunk prima di passare alla versione 1.2.X. Ogni volta che questi commit si collegano al trunk, presumo che il trunk sia stato costruito e testato sull'unità (forse anche in un ambiente di staging), quindi quale versione è quella che commette? Importa?

TC prende uno dei commit e costruisce progetti e unit test. Genera un artefatto? Mi chiedo come lo distribuirai tramite Chef o simile all'ambiente di staging, se questo è davvero ciò che fai con dev come trunk.

Immagino che in ambienti ci siano dozzine di cambiamenti ogni giorno che il versioning deve essere automatizzato (un delta semantico aggiunto tramite il messaggio di commit) o non visto come molto importante a causa dell'alto volume e del flusso di modifiche .

    
posta PatrickWalker 15.10.2016 - 10:24
fonte

2 risposte

1

Quale numero di versione da utilizzare per le build fatte da trunk dipende interamente da te (o meglio dalla tua organizzazione).

Alcune opzioni possibili sono:

  • Nessun numero di versione affatto
  • Versione 0.0
  • La versione dell'ultima versione ufficiale
  • La versione della prossima versione ufficiale

Per differenziare "trunk-builds" dalle versioni ufficiali, è comune aggiungere un suffisso come snapshot-<DATETIME> al numero di versione. Aggiungere la data e l'ora della build aiuta anche a mantenere le varie "configurazioni del tronco" l'una dall'altra.

    
risposta data 15.10.2016 - 12:00
fonte
2

Leggendo quel post sul blog sembrerebbe che il controllo delle versioni sia eseguito solo sul ramo di rilascio.

Se ci pensate, dopo il ramo iniziale, le correzioni dei bug sono state sostituite con nuove modifiche al codice. vale a dire che il codice per il commit di release release 1.x non esisterà in nessun punto del trunk. Quindi, se hai eseguito il trunk della versione, non sarebbero sincronizzati con i numeri di versione della versione.

Non sono sicuro che i fautori di questo modello possano sostenere che una correzione di bug selezionata da un fuso è diversa da un commit di correzione di bug sul rilascio che viene unito al trunk.

Ovviamente il tronco commuta senza il beneficio dei commit prima che non sia garantito per lavorare sul rilascio e richiederà lavoro addizionale e test

    
risposta data 15.10.2016 - 11:06
fonte