Rilascio hotfix automatico con versioning semantico basato su ramo principale

0

Ho uno script Python che vive nella mia pipeline CI che è responsabile della pubblicazione di rami e tag, pubblicazione di AAR sul nostro Maven Artifactory, caricamento di Javadoc, ecc.

Abbiamo seguito una versione modificata di Git Flow in cui pubblicheremo un ramo "di supporto /" (per il supporto a lungo termine di una versione di prodotto secondaria, come "supporto / 5.10") o un "rilascio / "ramo (per i test di regressione del rilascio.

Il mio script si basava in gran parte sul nome di Git Branch per determinare i dump della versione Major / Minor / Patch.

Ora stiamo abbandonando le filiali di supporto e ci stiamo spostando verso un flusso di lavoro Git Flow più vanilla in cui eseguiremo gli HotFix esclusivamente da Master (beh, avremo ancora i rami di rilascio, ma il problema è risolto ...)

Tuttavia, non riesco a trovare un modo per determinare in modo sicuro la versione della patch del ramo Master, poiché ovviamente non ha caratteristiche identificative nel suo nome che possiamo scrub (mi sono sempre sentito un po 'a disagio sul metodo stanno usando, ma ... ha funzionato).

Posso accedere ai tag e sfiorare sempre quello più alto, ma è impreciso.

Posso inserire una versione di destinazione, ma questo interferisce con l'IC e ci costringerebbe a eseguire questo script manualmente.

Qualche altra idea su come affrontarlo? Qualcuno ha già risolto questo problema?

    
posta jesses.co.tt 08.08.2017 - 23:04
fonte

1 risposta

1

Una pratica che ho visto utilizzata con successo è stata:

  1. Le versioni principali / secondarie, ad es .: n.0.0 o n.m.0 vengono attivate premendo un tag, probabilmente generato da uno script python, per il numero di versione con un hook pre-commit a:

    1. Assicurati che sia stato seguito il pattern corretto &
    2. Accertati che si trattasse della prossima versione incrementale maggiore o minore,
    3. Assicurarsi che non ci siano stati test falliti e amp; nessuna modifica dall'ultimo push di sviluppo.
  2. Le modifiche apportate al master, dopo aver completato con successo i test, hanno causato la creazione e l'ampli push di un tag che era la prossima versione incrementale della patch, cioè x in m.n.x - poiché tutti i tag erano generati, non c'era alcun problema durante l'analisi dei tag
  3. Quel tag è stato automaticamente creato e amp; schierato.

Si noti che lo script per il tag richiederebbe all'utente:

  • Versione principale o secondaria?
  • Pre-Release Alpha, Beta o Final?

Qualsiasi pre-release è stata "rilasciata" in un'area di anteprima per i tester e / o i client di prova per l'accesso.

    
risposta data 09.08.2017 - 07:46
fonte

Leggi altre domande sui tag