L'attuale compagnia per cui lavoro ha quello che considero un set insolito per il loro sistema di controllo delle versioni. Ci sto lavorando ma non posso fare a meno di sentire che quello che stanno facendo è subottimale e che avrebbero un processo molto migliore se usassero quello che considero un approccio Trunk, Branch, Tag più standard.
Ho presentato questa idea a loro e loro erano aperti a cambiare tuttavia prima di iniziare a spingere affinché questo cambiamento abbia luogo (e possibilmente essere colui che lo implementa) voglio assicurarmi che non mi manchi alcuni vantaggi alla loro attuale configurazione che andrebbe persa.
Usano ciò che potrebbe essere descritto come un approccio "ambiente a tre stadi", ogni progetto avrà il proprio repository e in quel repository le cartelle di primo livello saranno sempre DEV, UAT, PROD:
Untipicociclodisviluppoperquestoèilseguente:
- LosviluppatorecontrollalacartellaDEV,eseguelemodificheeloricontrolla.
- IlteamdisupportodistribuiscelemodifichedaDEVnell'ambienteUATecontrollalemodifichenellacartellaUAT.Poichéquestanonèunamiaresponsabilità,nonèchiarosequestoèprimaodopoiltest.
- IlteamdisupportodistribuiscelemodifichedaUATnell'ambienteProdecontrollalemodifichenellacartellaProd.
SonopiùabituatoalavorareconilmodelloTrunk,Branch,Tag:
(Immagineda
Quale mapperebbe al ciclo di sviluppo corrente dell'azienda come:
- Lo sviluppatore crea un ramo per il lavoro di sviluppo, esegue modifiche e taggalo.
- Supporto distribuire il tag nell'ambiente UAT. Non è necessario che controllino qualcosa.
- Tutto sta bene Sostieni il tag su Prod. Contro non c'è bisogno che controllino qualcosa (o potremmo taggare ancora per un record distinto di un rilascio di prodotto).
Riesco a vedere molti vantaggi del metodo TBT, ma ho davvero difficoltà a scoprire perché l'approccio a tre fasi sarebbe meglio.
Anche se non riesco a trovare alcun punto di forza, ecco i problemi che sto riscontrando con l'approccio a tre fasi per coloro che troverebbero più facile rispondere rispetto ad alcuni punti specifici:
- Quasi sempre il codice tra tutte e tre le fasi non corrisponde e quindi c'è un periodo di fusione all'inizio di ogni progetto.
- Quando effettuo il check-in per DEV, non posso garantire che le mie modifiche siano trasferite a UAT e Prod alla fine del progetto. Questo non dovrebbe essere una mia responsabilità controllare (IMHO) ma quando sono necessari ulteriori cambiamenti diventa il mio problema, perché devo assicurarmi che DEV non sia andato alla deriva da UAT e Prod.
- L'idea delle filiali di feature non si adatta proprio a questo, a meno che non ci dirammo su DEV e facciamo un ramo corrispondente in UAT dove viene promosso il ramo DEV. Normalmente abbiamo un solo sviluppatore su un progetto quindi non è un problema, posso lavorare direttamente sul trunk senza conflitti, ma preferirei comunque utilizzare le migliori pratiche in modo da poter crescere senza dolore se lo facessimo.
- Non c'è un modo solido per confermare quale versione è attualmente in quale ambiente. Con un tag posso dire che la versione UAT1.2.3 è stata pubblicata il 1 ° gennaio, con l'attuale configurazione ho bisogno di guardare la cronologia delle revisioni, vedere cosa è stato registrato quando e sposarlo con le date di rilascio.
Non so se è la mancanza di una terminologia corretta o se è solo perché è un approccio intrinsecamente sbagliato, ma sto facendo fatica a trovare risorse che promuovano o discutano questa struttura. Eccone uno che ho trovato con qualcuno che chiede la stessa domanda e sto ancora cercando attivamente.
Cosa mi manca qui? Quali sono i vantaggi dell'approccio a tre fasi rispetto a TBT e ad altri? O non ce ne sono e l'approccio in tre fasi non è in realtà una cosa?