strategie di pacchetto e versione in un ambiente multi repository

Siamo una piccola azienda con più team che gestiscono i propri repository git. Questa è una piattaforma web e gli artefatti di ogni squadra sono distribuiti alla fine della giornata per i test notturni. Stiamo cercando di formalizzare il processo di versioning e packaging.

Ogni squadra ha un ramo principale in cui svolgono lo sviluppo quotidiano. I membri dell'assicurazione della qualità di ogni squadra vogliono che gli artefatti delle modifiche apportate dal loro team vengano distribuiti in un banco di prova in cui tutti i componenti sono combinati dallo chef. Gli artefatti sono tarball ma vorrei convertirli in RPM in modo da poter pensare e ragionare correttamente sulle versioni.

Il processo di rilascio comporta l'interruzione di un ramo di rilascio dal ramo di sviluppo (master nella maggior parte dei casi) di ciascuno dei repository git. Questo viene poi dato all'assicurazione della qualità che esegue test e firma su una serie di artefatti.

Ad esempio questo è un tipico repository git con i suoi rami di rilascio associati:

 0-0-0-0-0-0-0-0-0-0 (master)
   |           |
   0           0
 (rel-1)       |
               0
            (rel-2)

Sono bloccato nel tentativo di capire uno schema per eseguire il versioning dei pacchetti provenienti dai rami di sviluppo. Non vogliamo etichettare eccessivamente il ramo principale di ciascun repository e limitare i tag solo al rilascio dei rami. Ma dovremmo essere in grado di interrogare i pacchetti distribuiti nelle macchine di test usando la semantica yum / rpm standard. Come sarebbero le versioni di sviluppo se il ramo master non ha tag? Capisco che git describemi può fornire una rappresentazione utile di una versione di build ma che funziona bene quando vengono taggati vari punti di rilascio sul ramo.

EDIT1: in risposta alla risposta di @ Urban48

Ho pensato che avrei dovuto spiegare un po 'di più il nostro processo di rilascio. Ai fini di questa discussione, supponiamo di avere una filiale masterin tutti i repository. Ilmaster ramo è considerato il ramo di sviluppo e viene distribuito in un ambiente di controllo qualità abilitato per CI-CD automatizzato. È qui che viene eseguito un sottoinsieme di test notturni per garantire la stabilità del master. Esaminiamo questa pipeline di lavori prima di tagliare un ramo di rilascio. I nostri rami di rilascio hanno vita breve. Ad esempio, dopo aver tagliato un ramo di rilascio (da un master stabile), viene eseguita una regressione completa, le correzioni vengono eseguite e distribuite alla produzione. Questa operazione richiede circa una settimana. Rilasciamo quasi ogni due settimane alla produzione.

I nostri rami delle funzioni sono sempre tagliati dal master e sottoposti a una serie di test degli sviluppatori prima di fondersi con il master su cui sono sottoposti ai controlli di stabilità del CD CI.

Gli hotfix vengono eseguiti sui rami degli hotfix (tagliati dai rami di rilascio) e distribuiti con test di impatto minimo in produzione.

La nostra strategia di versioning per i rami release e hotfix segue semver. Rilasciare rami durante il ciclo di QA Passare attraverso versioni come v2.0.0-rc1, v2.0.0-rc2e finalmente dopo QA sign-off diventano v2.0.0.

A volte facciamo rilasci punteggiati per piccole funzionalità che vengono unite per rilasciare rami (e quindi padroneggiare) dove diventano le versioni v2.1.0. E gli hotfix assumono il v2.1.1modello.

La domanda tuttavia non riguarda il controllo delle versioni di questi rami. Preferirei non modificare del tutto questo schema di versioning. L'unico cambiamento avviene per il ramo di sviluppo cioè. maestro. Come posso indicare in modo affidabile nell'ambiente CI-CD quale versione esiste rispetto alla versione precedente in produzione. Questo sarebbe idealmente fatto attraverso il tagging smart git ma si preferisce qualcosa che non tagga eccessivamente il ramo master.

Bene, ho un esempio .net che potrebbe essere agnostico dalla tecnologia.

Farò solo un breve riassunto.

• repository git per componente con strategia di branching gitflow

• tutti si impegnano a sviluppare innescare una squadra di città

• teamcity build modifica la versione con il maggiore minore manuale + il numero di build in AssemblyInfo.cs, ovvero 1.1.hotfix.build

• teamcity attiva il packaging di nuget utilizzando lo stesso numero di versione per le librerie pubblicate da nuget

• octopus distribuisce build finita a qa per i test manuali (presupponendo che tutti i test abbiano superato)

• se tutto è a posto, distribuisci manualmente la versione alla produzione tramite polpo.

Ora questo significa che ottieni MOLTI pacchetti con versione mobile. Abbiamo sperimentato l'uso del flag -prerelease ma ciò ha richiesto un ulteriore pacchetto di spostamento manuale dal prelease al passaggio "normale" e un requisito per ricostruire i componenti che dipendevano da essi.

La cosa fondamentale è la versione di ogni build in modo univoco tramite un processo centrale.

Quindi ti trovi nella situazione di "hmm quali versioni voglio" piuttosto che "omg, quale versione ho ??"

Modifica: ri commenti.

Solo per sottolineare quella cosa fondamentale davvero. Decidi quale filiale costituisce il software completo e la versione che TUTTI si impegna ad essa. distribuire solo software con versione da questo ramo.

La mia opinione è che devi affrontare la tua strategia di ramificazione.

• non rami delle funzionalità di versione (o di eventuali sviluppatori).
• fare master versione
• usa solo i pacchetti dal master

Consentitemi di offrire un flusso di lavoro alternativo, che potrebbe risolvere il problema del controllo delle versioni o semplicemente aiutarvi a pensare a più modi per la soluzione.

Prima un po 'di filosofia ..
(Sto facendo alcune ipotesi sul tuo flusso di lavoro, per favore correggimi se sbaglio)

1. I test vengono eseguiti in modo retroattivo :

   Esci dal ramo delle masercaratteristiche, quindi trasformalo in un artefatto per il test del QA.
   il problema è : cosa succede se i test falliscono, quindi masterpotrebbero essere rotti!

   effetti collaterali:

   • Rende gli sviluppatori non fidarsi master

   • Dal momento che esci dal master per rilasciare i rami, cosa succede se la versione precedente viene interrotta? interrompe l'integrazione della nuova funzionalità fino a quando il master non viene nuovamente corretto.

   • quando il bug è stato corretto nel ramo di rilascio, l'unione di nuovo masterpuò creare conflitti di unione. (e non ci piacciono i conflitti)

2. fusioni e correzioni di piccoli codici :

   È difficile tenere traccia di tutto il codice che viene unito master, ad esempio piccole correzioni o modifiche che non fanno parte di una determinata funzionalità.

   effetti collaterali:

   • lo sviluppatore non è sicuro di dover modificare questa piccola correzione ora o più tardi.

   • dovrei versione anche questa nuova piccola correzione?

   • In qualsiasi momento non è chiaro quale sia lo stato del masterramo e quale codice fluttui lì dentro

   • qualcosa ha rotto la build, che non fa parte della nuova funzionalità. ed è davvero difficile rintracciare la provenienza

La mia idea per il flusso di lavoro git è la seguente:

diramare masterper lo sviluppo di nuove funzionalità come già fai tu. ma ora invece di rilasciare da questo ramo appena creato, questa funzione viene selezionata e unita al releaseramo.

Ora hai un migliore controllo su ciò che sta succedendo in una certa versione.
Ora è davvero facile isolare le versioni di sviluppo e le versioni stabili.

Puoi continuare a costruire artefatti da quei rami delle funzioni per il QA.
Se tutto è a posto, ricollega quella funzionalità mastere seleziona questa funzionalità / bug-fix / hot-fix nel ramo di rilascio.

versioning
La versione dei rami delle caratteristiche può usare una convenzione del nome come1.2.3-rc.12345

le versioni nel releaseramo useranno solo 1.2.3 ( 1.2.3> 1.2.3-rc.12345anche una cosa in meno di cui preoccuparsi)

Questo flusso di lavoro risolve i problemi sopra menzionati e altro.
Propone inoltre una strategia di versioning sana e la maggior parte di questo ciclo di rilascio può essere automatizzato.

Spero che ti possa aiutare in qualche modo, parlerò volentieri di tutti i casi limite che puoi trovare.

ps:
mi scuso per il mio inglese, non è la mia lingua principale.

Il tuo processo sembra molto complicato e ottenere un po 'di tag sembra inevitabile.

Mi vengono in mente due idee:

1. Trattate il ramo "master" come quello che normalmente abbiamo nel ramo "sviluppo". Questo inquina molto il ramo del messaggio.

2. Al termine del controllo qualità, è possibile disporre del server build / CI per creare un report (ad es. Un file di testo) con i tag di tutti i repository in uso. Ora avrai un file con le versioni che possono essere postate nel repository. Quindi si tagga il ramo solo con la versione di rilascio e se si desidera controllare le versioni dei singoli componenti, è possibile controllare il report.