Come strutturate i vostri rami in TFS

Naviga le tue risposte
7

Il mio gruppo al lavoro ha cercato di elaborare un buon processo che possiamo utilizzare con TFS. Mi stavo solo chiedendo se alcuni di voi ragazzi avessero delle strategie di successo nell'usare TFS su più siti usando più filiali.

Un problema specifico che abbiamo è probabilmente il nostro motore di rilascio. Sul lato semplice, uno sviluppatore dovrebbe essere in grado di controllare le sue modifiche nel ramo DEV, e quindi ok certa data (ad esempio una data di congelamento) il ramo DEV sarà "reverse integrated" nel Main Trunk (QA) in che quindi le modifiche verranno trasferite al ramo Produzione. Il problema è sorto quando un utente effettua il check nel ramo DEV, ma non vuole che queste modifiche vengano spostate in QA (perché forse un'altra porzione del codice non è ancora stata eseguita) ... qualche idea su questo?

    
posta aggietech 15.10.2010 - 05:15
fonte

3 risposte

2

Lo uso da circa 4 anni in un paio di team diversi. Quello che ho trovato che funziona meglio per il nostro gruppo è la gestione delle filiali per versione / iterazione. Quindi tutte le modifiche per l'iterazione sono fatte su un ramo di sviluppo e quando tutte queste sono pronte per andare al QA, allora ci uniamo.

Questo diventa un po 'un problema se hai qualcosa sul ramo che non è realmente pronto per unire, ma puoi scegliere di non unire questi gruppi di modifiche. Ciò diventa complicato se il codice che non includi cambia qualche pezzo chiave o qualcosa del genere, ma ciò è stato raro nella mia esperienza. Quello che abbiamo fatto è gestire le iterazioni in modo che tutto sia veramente completato alla fine. Se c'è un pezzo che è rischioso puoi fare un ramo fuori dal tuo ramo DEV solo per quello in modo che tu possa gestirlo separatamente.

Mi terrei nel minor numero possibile di filiali in modo da non passare troppo tempo alla fusione.

    
risposta data 15.10.2010 - 06:58
fonte
2

La mia vecchia risposta a questa domanda funziona. Ma da quel momento il nostro processo è migliorato in modo significativo e abbiamo incorporato implementazioni automatizzate, quindi ora direi ....

Ora abbiamo due settimane di iterazioni ma implementiamo nuove funzionalità tanto velocemente quanto le modifiche apportate, le verifiche e le verifiche invece di aspettare tutto nell'iterazione. Per facilitare questo, ci siamo riorganizzati su un ramo principale (tronco) e quindi su un ramo di sviluppo fuori dal main. Qualsiasi modifica che passa la revisione viene unita a main e le implementazioni avvengono in modo semiautomatico fuori main. Questa strategia ha funzionato davvero bene per noi, ci sono pochissime volte in cui le fusioni sono difficili perché le modifiche vengono spostate al livello principale in blocchi più piccoli.

    
risposta data 13.04.2016 - 04:56
fonte
2

MS ha pubblicato un white paper che copre un approccio con dettagli sul perché.

link (questa è la versione 2008/2010, c'è anche una versione del 2005).

Questo link è ormai obsoleto e il consiglio è stato aggiornato. Si prega di consultare link

    
risposta data 15.10.2010 - 10:33
fonte

Leggi altre domande sui tag

In che misura devo testare cosa non dovrebbe accadere Quanto sono utili i punti di funzione? [chiuso]