Per la versione basata su branch, dobbiamo parlare del seguente diagramma, che illustra perfettamente il panorama del processo di gestione della configurazione. Innanzitutto, questo diagramma è scritto basandosi sul modello Git, ma in realtà Git e Subversion hanno capito il concetto di gestione del controllo versione, anche se Git fa un salto qualitativo rispetto a Subversion nella gestione delle filiali e nelle prestazioni distribuite (ma questo non è il fulcro di questo articolo).
Prima di introdurre il principio di questo grafo, parliamo di due diverse strategie per il controllo generale delle versioni: una è "backbone pioneer, ramo stabile", e l'altra è "backbone stabile, ramo pioniere". Come suggerisce il nome, è la versione stabile (versione di produzione), sul tronco o sul ramo. Nel caso dei team di progetto tradizionali che utilizzano VSS, è difficile dire a quale modalità appartenga, principalmente perché VSS stesso non ha una strategia di gestione delle filiali, quindi molti team di progetto stabiliscono rispettivamente due librerie di versioni (o tre), corrispondenti all'ambiente di produzione e all'ambiente di sviluppo; naturalmente, anche questo è una sorta di gestione di filiale mascherata. Tuttavia, se si passa a Subversion o Git come strumento di controllo versioni, la maggior parte dei team utilizza la modalità trunk stabile, cioè il trunk (truck o master) corrisponde a un ambiente di produzione stabile e tagga diverse release per indicare la versione di produzione. Personalmente, penso che il modello di codice backbone stabile dovrebbe essere attualmente la soluzione di gestione delle versioni più mainstream del codice. L'immagine sopra è il modello standard di gestione della "backbone stabile".
padrone: La corrispondente Subversion è truck。 Corrispondente alla versione di produzione, viene taggato una volta ad ogni release.
Branch di rilascio (noto anche come branch di integrazione): Finché la produzione viene aggiornata, deve prima essere integrata nel ramo di rilascio (ramo di integrazione). È in qualche modo simile a ciò che il team di progetto chiama attualmente il concetto di "pre-produzione" e "ambiente simulato".
Branch di sviluppo (branch di sviluppo o branch di sviluppo): L'ambiente affrontato dall'ambiente di sviluppo.
Filiale delle caratteristiche (ramo delle caratteristiche): Alcune funzioni indipendenti possono essere separate da un ramo di sviluppo separato. Questo serve principalmente a gestire il fatto che alcune funzionalità potrebbero richiedere un tempo relativamente lungo per essere aggiornate, così da non trascinare il rilascio e i rami separati.
Branch delle correzioni rapide (ramo di correzione di bug): Il bug qui è principalmente un bug di produzione.
Dopo aver introdotto il tronco e i rami, devo indicare la direzione della generazione e della fusione di questi rami.
Master è la versione di produzione, e il trunk accetta solo due rami per la fusione, uno è il ramo di rilascio (branch di integrazione) e l'altro è il ramo hotfixes. Nessun altro ramo può essere fuso in un ramo di produzione.
Il ramo di rilascio viene inizialmente creato contemporaneamente alla produzione, che è esattamente lo stesso della produzione. Accetta solo il ramo di sviluppo per fondersi con esso. In altre parole, non accetta la fusione diretta dal branch feature o dal ramo bugfixes.
Il ramo sviluppo, il ramo di sviluppo, come il ramo di integrazione, è lo stesso dell'ambiente di produzione in un certo momento. Tuttavia, con il progredire dello sviluppo, nuove funzionalità continueranno a essere create nel ramo di sviluppo. La teoria di sviluppo accetta solo la fusione di due rami, uno è per hotfix e l'altro per il ramo di caratteristiche.
Feature Branch, a partire da un certo punto (versione) con il Dev Branch, il Feature Branch alla fine si fonderà con il Dev Branch.
Presentiamo brevemente il metodo di controllo versione sotto forma di scenario
Supponiamo che una versione di produzione sia divisa in rami (dev, hotfixes, release), e a questo punto lo sviluppo inizi a sviluppare un totale di dieci funzioni. Quando 8 delle 10 funzionalità sono state sviluppate, il team di testing ha iniziato a intervenire per i test interni e l'amministratore di configurazione ha distribuito il ramo di sviluppo nell'ambiente di sviluppo per testare tramite strumenti di integrazione continua (un argomento a parte qui). Quando la verifica di test ha rilevato che due delle funzioni erano completamente inaccettabili e dovevano essere rifasce, come semplice assicurazione assicurativa e restituzione dei sinistri, due rami di funzionalità sono stati separati dallo sviluppo, corrispondenti a assicurazione semplice e rimborso del sinistro, e nel ramo di sviluppo anche il codice corrispondente ha dovuto essere riportato (operazione manuale qui). Quando il team di test constata che non ci sono problemi con il test del dev branch, questo soddisfa le condizioni dell'UAT, quindi l'amministratore di configurazione fusiona il dev branch nel release branch e poi utilizza strumenti di integrazione continua per pubblicare questo branch nell'ambiente di pre-produzione e consegnarlo all'utente per il test. Quando la verifica utente trova un problema, lo sviluppatore modifica il ramo di sviluppo e poi lo integra nel branch di rilascio (qui, nella foto originale, viene modificato direttamente nel ramo di rilascio, penso che non sia una buona idea, consiglio allo sviluppatore di affrontare solo il ramo di sviluppo), quando il processo di verifica e rilascio scopre improvvisamente che c'è un bug serio nell'ambiente di compilazione che deve essere risolto immediatamente, viene modificato urgentemente sul ramo hotfixes e viene lanciato urgentemente dopo aver verificato che sia corretto. Allo stesso tempo, il ramo degli hotfix viene fuso con dev (qui è per lo più manuale, perché a questo punto la versione di produzione è già molto diversa da quella di sviluppo, e spesso è impossibile completare la fusione automatica), e poi dev viene integrato nella versione. Dopo un certo periodo di tempo, la funzione di restituzione richieste potrebbe non essere più necessaria e deve essere annullata, quindi il ramo della funzione di restituzione della richiesta verrà eliminato. Un'altra funzione è facile da assicurare ed è stata sviluppata e integrata nuovamente nel ramo di sviluppo per lanciare la prossima versione online.
Lo scenario sopra citato include fondamentalmente lo sviluppo di routine, lo smontaggio, gli aggiornamenti d'emergenza e altri scenari nel processo quotidiano di sviluppo.
|
Pubblicato su 08/04/2018 10:25:39
|
|
|
|
