Strategie di gestione del codice sorgente (branching, tagging, biforcazione, ecc.) Per le app Web

Question

Questo post qui ( Come gestite le revisioni del database su un progetto di medie dimensioni con filiali? ) mi sono chiesto come lavorare al meglio su un progetto Web usando la ramificazione e la distribuzione in sviluppo, gestione temporanea e produzione (insieme alle copie locali).

Non abbiamo " rilasci " di per sé: se una funzionalità è abbastanza grande da essere evidente, la spingiamo dal vivo (dopo aver richiesto i test / ecc.), altrimenti ne accumuliamo alcune e, quando ci si sente "a proprio agio", le spingiamo in diretta. L'obiettivo non è mai avere una distribuzione più di una o due volte al mese o giù di lì perché un sito in costante evoluzione tende a rendere gli utenti un po 'a disagio.

Ecco come lo facciamo, e sembra un po 'fragile (attualmente usando svn ma considerando un passaggio a git):

1. Due "rami" - DEV e STAGE con una data versione di STAGE contrassegnata come TRUNK
   • Lo sviluppatore verifica una copia di TRUNK per ogni modifica e crea una succursale per essa
   • Lo sviluppatore lavora localmente, controllando frequentemente il codice (proprio come votare: presto e spesso)
   • Quando lo sviluppatore è a proprio agio, non è completamente rotto, unire il ramo con DEV e distribuirlo nel sito di sviluppo.
   • Ripeti 3-4 se necessario fino a quando la modifica è "quotata"
   • Unisci il ramo delle modifiche con STAGING, distribuiscilo sul sito dello stage. Effettuare i test finali previsti.
   • Dopo un certo periodo di tempo, segna una data revisione di STAGE come TRUNK e attiva il trunk
   • Unisci le modifiche a TRUNK di nuovo in DEV per mantenerle sincronizzate

Ora, alcuni di questi passaggi hanno una significativa complessità sventolata a mano e in pratica sono molto difficili da fare (TRUNK - > DEV si rompe sempre) quindi devo immaginare che c'è un modo migliore.

Pensieri?

Answer 1

La diramazione è utile se si prevede che il lavoro NON venga completato in tempo e non si dispone di un numero sufficiente di test per far funzionare l'integrazione continua. Tendo a vedere lo sviluppo pazzo delle filiali nei negozi in cui le attività di programmazione sono troppo grandi per essere completate in modo prevedibile e quindi il management vuole aspettare fino a poco prima di un rilascio per determinare quali funzionalità dovrebbero essere fornite. Se stai facendo quel tipo di lavoro, potresti prendere in considerazione l'uso del controllo della versione distribuita, dove OGNI directory di lavoro è un ramo naturalmente e ottieni tutto il check-in locale e la cronologia locale che puoi mangiare senza danneggiare nessuno. È anche possibile unire in modo incrociato con altri sviluppatori al di fuori del trunk.

La mia preferenza è quando lavoriamo in un trunk instabile con rami per i candidati al rilascio, che vengono quindi etichettati per il rilascio e che diventano lo stream per le patch di emergenza. In un tale sistema, raramente si hanno più di tre rami (ultima versione, candidato alla versione corrente, trunk instabile). Funziona se stai facendo TDD e hai CI sul trunk instabile. E se hai bisogno di suddividere tutte le attività in modo da poter consegnare il codice tutte le volte che vuoi (di solito un'attività dovrebbe essere solo uno o due giorni e rilasciabile senza tutte le altre attività che ne compongono la funzione). Quindi i programmatori prendono lavoro, controllano il bagagliaio, fanno il lavoro, sincronizzano e controllano in qualsiasi momento tutti i test passano. Il trunk instabile è sempre disponibile per il branch come candidato di rilascio (se tutti i test superano) e quindi il rilascio diventa un non-evento.

Nel complesso, mezzi migliori: meno rami, attività più brevi, tempi di rilascio più brevi, più test.

Answer 2

Un pensiero ovvio sarebbe più "rebase" (si fonde più spesso dall'ambiente "padre" STAGE all'ambiente "figlio" ambiente "DEV" al ramo sviluppatore) al fine di ridurre al minimo l'impatto finale di TRUNK- > DEV, che non sarebbe più necessario.

Vale a dire, qualsiasi cosa fatta in STAGE, che è destinata a entrare in produzione in una sola volta (TRUNK) dovrebbe essere unita il prima possibile nel DEV e nel ramo degli sviluppatori privati, altrimenti quelle fusioni di retrofit in ritardo sono sempre un dolore.

MA, se il flusso di lavoro di fusione sopra è troppo scomodo, suggerirei un ramo REBASE, basato sull'ultimo DEV appena dopo un rilascio (nuovo TRUNK). Il rebase TRUNK- > DEV diventerebbe TRUNK- > REBASE, dove tutti i problemi sono stati risolti, quindi un ultimo fusione DEV- > REBASE per verificare che qualsiasi sviluppatore corrente sia compatibile con il nuovo sistema aggiornato. Un'ultima banale fusione da REBASE a DEV (e ai rami di sviluppo privati) completerebbe il processo.
Il punto di un ramo è quello di isolare uno sforzo di sviluppo che non può essere condotto insieme ad altri sforzi di sviluppo attuali. Se TRUNK- > DEV è troppo complicato per andare d'accordo con gli attuali DEV, deve essere isolato. Da qui la proposta di ramo "REBASE".

Answer 3

Leggi: http://oreilly.com/catalog/practicalperforce/chapter/ ch07.pdf

Answer 4

Usiamo SVN nel negozio in cui lavoro. Mentre facciamo lo sviluppo in C ++, la gestione delle versioni è piuttosto universale. Di seguito è riportato il nostro approccio, puoi decidere quale, se del caso, è ragionevole per il tuo approccio.

Per noi, TUTTO lo sviluppo avviene in un ramo. Ci ramifichiamo per ogni bug e ogni caratteristica. Idealmente, quel ramo è dedicato SOLO a 1 funzione, ma a volte non è destinato a esserlo.

Quando il lavoro è completato, testato e "pronto" uniamo le modifiche nel bagagliaio. La nostra regola è che in nessun caso il trunk dovrebbe mai avere un codice rotto in esso. Se il codice non funzionante dovesse trovarsi nel trunk, risolverlo diventa la priorità 1.

I rilasci vengono effettuati quando tutte le funzionalità sono state completate e unite: un ramo per il rilascio viene creato come un tag. Il tag ci consente di recuperare un'istantanea se necessario. La filiale ci consente il supporto della nostra versione precedente. La correzione dei bug in una versione rilasciata viene eseguita andando al ramo di quella versione, ramificandosi da esso. Quando tutto va bene, le modifiche vengono ricondotte al ramo del rilascio e, se lo si desidera, fino al trunk.