Siamo un'azienda di piccole dimensioni con più team che gestiscono i propri repository git. Questa è una piattaforma web e gli artefatti di ogni squadra vengono distribuiti alla fine della giornata per i test notturni. Stiamo cercando di formalizzare il processo di versioning e packaging.
Ogni team ha un master branch in cui fanno lo sviluppo giorno per giorno. I membri dell'assicurazione della qualità di ogni team desiderano che i manufatti delle modifiche apportate al loro team vengano distribuiti in un banco di prova in cui tutti i componenti sono combinati dallo chef. Gli artefatti sono tarball ma mi piacerebbe convertirli in RPM in modo che possiamo pensare e ragionare sulle versioni correttamente.
Il processo di rilascio comporta il taglio di un ramo di rilascio dal ramo di sviluppo (master nella maggior parte dei casi) di ciascuno dei repository git. Questo viene poi dato alla garanzia della qualità che esegue test e firma su una serie di risorse.
Ad esempio, questo è un tipico repository git con i relativi rami di rilascio associati:
0-0-0-0-0-0-0-0-0-0 (master)
| |
0 0
(rel-1) |
0
(rel-2)
Sono bloccato cercando di capire uno schema per eseguire il controllo delle versioni dei pacchetti provenienti dai rami di sviluppo. Non vogliamo etichettare eccessivamente il ramo principale di ciascun repository e limitare i tag solo per rilasciare le filiali. 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 quando il ramo principale non ha tag? Capisco che git describe possa fornirmi una rappresentazione utile di una versione di build ma che funzioni bene quando vari punti di rilascio sul ramo sono taggati.
EDIT1: in risposta alla risposta di @ Urban48
Ho pensato che dovrei spiegare un po 'di più il nostro processo di rilascio. Per gli scopi di questa discussione, supponiamo di avere un ramo master in tutti i repository. Il ramo master è considerato il ramo di sviluppo ed è distribuito in un ambiente QA automatizzato abilitato per l'IC-CD. È qui che viene eseguito un sottoinsieme di test notturni per garantire la stabilità del master. Guardiamo questa pipeline di posti di lavoro prima di tagliare un ramo di rilascio. Le nostre filiali di rilascio sono di breve durata. Dite, dopo aver tagliato un ramo di rilascio (da un master stabile), viene eseguita una regressione completa, le correzioni vengono apportate e distribuite alla produzione. Questo richiede circa una settimana. Rilasciamo quasi ogni due settimane per la produzione.
I nostri rami di funzionalità sono sempre tagliati dal master e sottoposti a una certa quantità di test dello sviluppatore prima di fondersi con il master su cui sono sottoposti ai controlli di stabilità di CI-CD.
Le correzioni rapide vengono eseguite sui rami degli hotfix (tagliati dai rami di rilascio) e implementate con il test dell'impatto minimo in produzione.
La nostra strategia di versioning per i rami release e hotfix segue Semver. Rilasciare i rami durante il ciclo di QA passa attraverso versioni come v2.0.0-rc1 , v2.0.0-rc2 e infine dopo che il QA sign-off diventa v2.0.0 .
A volte facciamo rilasci puntati per piccole funzionalità che vengono unite per rilasciare i rami (e poi per diventare master) dove le versioni diventano v2.1.0 . E gli hotfix assumono il modello v2.1.1 .
La domanda tuttavia non riguarda la versione di questi rami. Preferirei non modificare completamente questo schema di controllo delle versioni. L'unico cambiamento riguarda il ramo di sviluppo, ad es. maestro. Come posso indicare in modo affidabile nell'ambiente CI-CD la versione esistente della versione precedente in produzione. Questo sarebbe idealmente fatto tramite smart git tagging ma è preferibile qualcosa che non tagga eccessivamente il master branch.
