Strategia di ramificazione per lo sviluppo parallelo che non sarà nella stessa versione?

Question

Strategia di ramificazione per lo sviluppo parallelo che non sarà nella stessa versione?

#1 da (3 voti)
#2 da (1 voti)
#3 da (1 voti)

3

Il mio team sta lavorando a un prodotto, che per motivi aziendali deve essere rilasciato a intervalli regolari. È emerso un problema in cui vogliamo fare lo sviluppo in parallelo per la prossima versione, così come la "prossima" versione. Questo è quello di diventare una pratica standard, quindi non è così semplice come tagliare un ramo di funzionalità per il nuovo lavoro. Avremo continuamente più di 2 team che lavorano su versioni diverse dello stesso prodotto.

Esiste una best practice SCM per questo tipo di accordo?

version-control branching

posta Telastyn 18.09.2012 - 19:39

fonte

3 risposte

Leggi altre domande sui tag version-control branching

Che cosa rende un buon flusso di lavoro JIRA con un team di sviluppo software? [chiuso] Come implementare un editor di testo in un browser? [chiuso]

score 3 · Answer 1

Ho visto cose come questa essere gestite su progetti open source, anche se devo ammettere che ho un'esperienza limitata.

immagina questa struttura ramificata.

- R0 --- > R1 --- > --- > R2 --- > --- > - R3

... / ........... / ................. / ............. ...... /

--- > --- > trunk --- > --- > --- > --- > --- > --- >

| (clone) ..... / .... / .. / ..... / ..... / .. / .... /

- > --- > --- > versione successiva --- > --- > --- >

In questo scenario, si scattano istantanee del trunk ogni volta che si effettua un rilascio e questo diventa il codice finale per quella versione. La versione successiva è un clone del tronco in un punto arbitrario nel tempo. Man mano che le nuove funzionalità vengono sviluppate, possono essere inserite nel bagagliaio ogni volta che la direzione decide che sono pronte.

ANCHE: Idealmente dovresti includere quale SCM nella descrizione della domanda, perché cose come perforce si comportano in modo molto diverso da git.

score 1 · Answer 2

Un'alternativa interessante che ho letto di recente è ciò che Martin Fowler chiama un Attiva / disattiva funzionalità . L'idea è che puoi evitare la ramificazione semplicemente disattivando le funzionalità che hanno del codice ma non sono ancora pronte.

Che ne valga la pena dipende da quanto sia dolorosa ogni opzione, e Fowler sta parlando da una prospettiva Agile in cui è importante che tutti si sentano liberi di refactoring, che la ramificazione può inibire.

score 1 · Answer 3

Credo che questo post ti sia di aiuto.

Dall'esperienza, aiuta anche a non pensare ai numeri di versione fino a quando non è stata creata la build effettiva del rilascio. In altre parole, non associare i nomi dei tuoi rami ai numeri di versione.

Il motivo per cui non lo vuoi è che ti dà la possibilità di cambiare l'ordine di rilascio delle versioni su cui stai lavorando. Significa anche che non si finisce con rami con numeri di versione nei loro nomi ("rel_0_9", "rel_1_0").