il modello gitflow con le versioni UAT è troppo caotico, come semplificare?

A $DAYJOB , abbiamo la seguente pipeline di rilascio / consegna:

1. Ottieni nuove funzionalità, lavora sulle nuove funzionalità.
2. Una volta completate tutte le funzioni, il nostro QA esegue le regressioni, ecc.
3. Il QA firma il primo build UAT, spedito al dipartimento UAT del cliente (questa è la vera forza del QA del cliente). Inizia la nostra versione iniziale (ad esempio v1.0)
4. Il controllo qualità clienti (UAT) rileva problemi, ci rimanda a un elenco.
5. Lo sviluppo risolve l'elenco di problemi. A volte potrebbero chiedere dei non difetti, come miglioramenti o piccole funzionalità. Noi li triage caso per caso. Anche il nostro QA verifica le correzioni. Si disconnettono, spediamo una nuova build (questo ottiene un bump della versione, come la v1.1)
6. Questo ciclo di operazioni "lista" e "lavoro nell'elenco" viene eseguito ciclicamente alcune volte, fino a quando il cliente non firma il build (UAT Pass).
7. Il build firmato diventa "produzione". Ora gli sviluppatori possono iniziare a lavorare sulle nuove funzionalità per la prossima versione.

Alcune note su questo processo:

• Usiamo una versione bastardata di git-flow per questo processo (spiegheremo più dettagliatamente in seguito).
• Per quanto riguarda il controllo delle versioni, non facciamo distinzioni tra le versioni UAT e le versioni di produzione. Dobbiamo supporre che qualsiasi versione di UAT possa essere firmata e diventare d'oro in qualsiasi momento. Per noi, ogni build "fuori dalla porta" viene considerata una "release di produzione".
• Gli sviluppatori lavorano su rami fuori da develop per le nuove funzionalità. Lavoriamo anche sulle funzionalità per la versione prossima . Tuttavia, non uniamo le funzionalità finché non sono pianificate per il rilascio. Questo perché non creiamo rami di "rilascio" (ne parleremo più avanti).

Ecco come il nostro processo di sviluppo riguarda sia i bug che le funzionalità:

1. Lo sviluppatore si disconnette da develop e inizia a lavorare.
2. Lo sviluppatore termina il lavoro, esegue la revisione del codice
3. Passa la revisione del codice e indichiamo al QA che il ramo è pronto per il test. Il nostro sistema di build CI crea ogni ramo nel repository remoto e QA può acquisire build ad-hoc su qualsiasi ramo. Il QA verifica le funzionalità nelle filiali (e non fuori da develop ) per alcuni motivi:
   1. Le build su develop potrebbero includere più funzionalità o correzioni di bug da parte di più sviluppatori nel corso del tempo. Quando si verificano regressioni, diventa più difficile rintracciare ciò che ha causato le regressioni. Il modello "test-ogni-ramo" ci consente di isolare le regressioni alle modifiche su quel ramo (ovvero, una caratteristica o una correzione).
   2. Tutte le funzionalità devono essere testate su un ramo perché non vengono uniti in develop finché il QA non è soddisfatto. Anche il controllo qualità controlla la pianificazione della distribuzione, in modo che sappiano quando lo sviluppo è pronto per le nuove funzionalità.
   3. Siamo a corto di risorse per il controllo qualità. Al momento abbiamo un rapporto 4 a 1 di sviluppatori per il personale di QA. Semplicemente non riescono a tenere il passo con il lavoro che facciamo.
4. Una volta che il QA è soddisfatto della funzionalità sul ramo, lo contrassegna come "verificato".
5. Una volta verificato, rimane invariato fino a quando qualcuno con l'autorizzazione appropriata "approva" la funzione o il ramo. A questo punto, uno sviluppatore rebase / si fonde più tardi nel ramo, corregge i conflitti, quindi lo unisce in develop .

Quando finalmente rilasciamo il software (di solito la nuova build UAT), facciamo una fusione da develop direttamente in master .

Sintomi del sistema attuale:

• tonnellate di rami seduti in attesa di essere uniti. Più di 100 al momento, e il tempo di consegna è a volte mesi prima che vengano unite.
• Il processo è complesso e strettamente controllato dal QA
• Lancia i sottomoduli nel mix e hai una ricetta per il disastro e la complessità.

Il motivo per cui non usiamo le filiali release al momento è perché abbiamo avuto un'esperienza negativa con loro. Il processo UAT può talvolta richiedere mesi. A volte richiedono funzionalità irragionevolmente e il management superiore lo consente. Abbiamo avuto i nostri rami di rilascio diventare numerosi, longevi, con enormi problemi di parità (in altre parole, accumulano tonnellate di cambiamenti nel corso della loro vita).

L'intera faccenda è piuttosto caotica e difficile da gestire. Tuttavia, il QA ci offre un sacco di feedback su questo processo perché le nostre versioni sono super stabili. Questo perché il QA tocca ogni ramo prima che venga unito, mentre prima gli sviluppatori si univano tutto il giorno a develop e QA non riusciva a tenere il passo con le modifiche, quindi un sacco di cose non è stato testato nelle versioni.

Ora che ho spiegato il nostro processo e la situazione, alcune domande:

1. Come possiamo semplificare questo processo?
2. Come devono essere gestiti release filiali quando hai un processo UAT nel mezzo? Idealmente vogliamo essere in grado di continuare lo sviluppo attivo su develop dopo si avvia UAT.