Strategie di ramificazione e fusione

Question

Sono stato incaricato di elaborare una strategia per la ramificazione, la fusione e il rilascio nei prossimi 6 mesi.

La complicazione deriva dal fatto che eseguiremo più progetti tutti con diverse modifiche al codice e diverse date di rilascio ma approssimativamente le stesse date di inizio dello sviluppo.

Attualmente stiamo utilizzando VSS per la gestione del codice, ma siamo consapevoli che probabilmente causerà alcuni problemi e verrà eseguita la migrazione a TFS prima dell'avvio del nuovo sviluppo.

Quali strategie dovrei utilizzare e quali aspetti dovrei prendere in considerazione prima di impostare un piano?

Scusate se questo è vago, non esitate a fare domande e aggiornerò con ulteriori informazioni se necessario.

Answer 1

Questo è il singolo migliore source control pattern che ho incontrato. Enfatizza l'importanza di lasciare il baule libero da eventuali cianfrusaglie (niente spazzatura nel bagagliaio). Lo sviluppo dovrebbe essere fatto in rami di sviluppo, e le fusioni regolari (dopo che il codice è stato testato) dovrebbero essere fatte rientrare nel trunk (Pic 1), ma il modello permette anche che la fonte venga riparata mentre è ancora in fase di sviluppo (Fig. 2). Consiglio vivamente di leggere il post nella sua interezza, per capire completamente.

  Pic 1

  Pic 2

Edit: Le immagini sono sicuramente fonte di confusione, senza parole. Potrei spiegare, ma fondamentalmente sto copiando l'autore originale. Detto questo, probabilmente avrei dovuto selezionare un'immagine migliore per descrivere il processo di fusione, quindi spero che questo aiuti. Raccomando comunque di leggere il post, tuttavia:

Answer 2

Il libro di sottoversione descrive some common branching patterns. Forse puoi anche applicarli a TFS.

Answer 3

La mia prima raccomandazione sarebbe quella di leggere Source Control HOWTO di Eric Sink - in particolare i capitoli branches e branch merge.

Abbiamo 3 contenitori - DEV, MAIN e RELEASE per il nostro lavoro. MAIN contiene tutto il nostro codice "ready-to-release" e tendiamo a considerarlo come "sostanzialmente stabile". DEV/Iteration (o DEV/Feature, o DEV/RiskyFeatureThatMightBreakSomeoneElse) sono rami di MAIN e vengono uniti quando Iteration/Feature è pronto per la promozione oltre l'ambiente DEV. Abbiamo anche configurazioni TFS create dal ramo DEV/Iteration e dal ramo MAIN.

Il nostro contenitore RELEASE contiene versioni numerate (simili al contenitore "tags" utilizzato in molti repository Subversion). Prendiamo semplicemente un ramo da MAIN ogni volta - mi piace dire che stiamo "tagliando" un ramo RELEASE per significare che questo non dovrebbe avere molte attività in corso una volta completata l'unione.

Per quanto riguarda VSS-> TFS - Microsoft supporta una upgrade path che dovrebbe mantenere la cronologia delle versioni, ma se non ne hai bisogno la storia, vorrei solo ottenere l'ultima versione da VSS, il check in TFS e archivia il repository VSS.

Un ultimo consiglio: fai familiarizzare i membri del tuo team con il controllo del codice sorgente. Devono capire la ramificazione e la fusione o si bloccherà facendo un sacco di lavori di pulizia :).

Buona fortuna!

Answer 4

Il modo più semplice e più comune in cui ho visto il lavoro di ramificazione è diverso da due premesse. Tronco e rilascio. Penso che questo sia noto come la filosofia del "tronco instabile, ramo stabile".

Il trunk è la fonte principale. Questo contiene il codice "ultimo e il più grande" ed è proiettato in avanti. In genere non è sempre stabile.

Release è un'associazione uno-a-molti con trunk. C'è un tronco ma molte versioni che derivano dal tronco. I rilasci in genere iniziano con un ramo del tronco una volta che è stata colpita una particolare pietra miliare della funzionalità, quindi le "sole" cose da fare per una specifica distribuzione dovrebbero essere solo correzioni di bug. Quindi dirama il trunk, assegnagli un'etichetta (ad esempio 1.6 Release è la nostra ultima versione corrente), crea e invia il rilascio a QA.Spingiamo anche il numero di versione (di solito il numero minore) del trunk in questo momento per assicurarci di non avere due rilasci con lo stesso numero.

Quindi si inizia il ciclo di test sul ramo di rilascio. Quando sono stati eseguiti test sufficienti, si applicano correzioni di bug al ramo di rilascio, si uniscono questi al tronco (per garantire che vengano apportate correzioni ai bug!) E quindi si rilasci una build del ramo. Questo ciclo con il controllo della qualità continua fino a quando non si è entrambi felici e il rilascio è finalmente dato al cliente (i). Eventuali segnalazioni di bug del cliente (es. Sono un bug!) Avviano un altro ciclo di QA con il ramo in questione.

Mentre crei le versioni future, è una buona idea anche provare a spostare i clienti più vecchi in rami più recenti per ridurre il numero potenziale di filiali che potresti dover applicare a una patch di correzione.

Utilizzando questa tecnica è possibile distribuire soluzioni che utilizzano la tecnologia a una varietà di clienti che richiedono diversi livelli di servizio (a partire dal primo), è possibile isolare le distribuzioni esistenti dal nuovo codice "pericoloso" nel bagagliaio e il peggiore Unisci scenario è un ramo.