Come posso lavorare contemporaneamente sulla versione 1.1 e sulla versione 2.0?

Question

La situazione:La versione beta è terminata e la versione 1.0 è stata rilasciata su diversi siti di clienti.Il team A è già impegnato a lavorare sulla versione 1.1 che avrà correzioni di bug incrementali e modifiche all'usabilità, mentre un altro team lavora sulla versione 2.0 con modifiche su larga scala, in cui il nucleo del prodotto potrebbe essere stato completamente riprogettato.Ora, la maggior parte delle modifiche apportate per la versione 1.1 dovranno essere implementate nella versione 2.0 ad un certo punto, e alcune delle correzioni di bug apportate nel ramo 2.0 potrebbero infatti dover essere programmate per una versione precedente.Il problema è che poiché la versione 2.0 presenta differenze fondamentali, nessuna modifica dalla versione 1.1 può essere incorporata senza conversione manuale, né viceversa.

La mia domanda:Quali sono le migliori pratiche di controllo delle revisioni per ridurre al minimo i conflitti di unione e la duplicazione del lavoro in questo tipo di situazione?Come posso garantire che i miei team dedichino il minor tempo e impegno possibile ai problemi di controllo delle revisioni, fornendo comunque patch regolari ai clienti?

Answer 1

Un buon modo è correggere ogni bug nel ramo stabile e unire il ramo stabile nel ramo di sviluppo.Questo è il Linee parallele di manutenzione/sviluppo modello, e la chiave è fondersi presto e spesso.Unire poco frequentemente e tardivamente significa che il ramo di sviluppo è irriconoscibile rispetto a quello stabile, oppure il bug non può ripetersi nello stesso modo.

Sovversione include il monitoraggio dell'unione a partire dalla versione 1.5 in modo da garantire che lo stesso set di modifiche non venga unito due volte, causando stupidi conflitti.Esistono altri sistemi (ad es. Idiota, Mercuriale, Accurev, Per forza) che ti consentono di fare query del tipo "Quali modifiche al ramo A non sono state unite nel ramo B?" E raccolta ciliegia le correzioni di cui hai bisogno per il ramo di dev.

Answer 2

L'articolo Qui (Day-to-day with Subversion) menziona che un metodo è aggiornare costantemente la versione 2 con i dati della build della versione 1.1.Nell'articolo, il ragazzo dice di farlo ogni giorno.

La parte che vorrai leggere si intitola "Cameriere, c'è un insetto nel mio bagagliaio!".Siamo circa a metà dell'articolo.

Answer 3

Probabilmente farei affidamento su un sistema di tracciamento dei problemi a questo scopo e mi assicurerei di contrassegnare ogni modifica che doveva essere apportata al codice trunk.Puoi quindi assicurarti che i commenti di check-in per ogni modifica facciano riferimento al problema rilevante e siano chiari nell'esprimere l'intento della modifica del codice in modo che possa essere facilmente compresa quando si tenta di reimplementarla nel trunk.

Answer 4

Più o meno quello che hanno detto tutti gli altri, ma ho pensato di mettere a frutto la mia esperienza nella gestione dello sviluppo in più rami utilizzando SVN

Con il nostro prodotto principale, abbiamo la necessità di sviluppare contemporaneamente più di 2 versioni contemporaneamente.

Inizialmente utilizzavo il trunk principale come versione di "sviluppo principale", con i tag utilizzati per ogni versione effettiva.I rami sono stati utilizzati per sostanziali sforzi di sviluppo per un nuovo set di funzionalità.Successivamente, quando abbiamo iniziato a lavorare su 2, 3 e 4 versioni alla volta, ho iniziato a utilizzare un ramo per ciascuna revisione.

Dal momento che mantengo il repository e gestisco anche il push delle build del QA, mi assicuro di eseguire "rollup" ogni mattina, che consistono nell'unire le modifiche sull'albero a partire dal ramo più basso attualmente attivo.Quindi finisco per unire le modifiche dalla 1.1 alla 1.2, che viene unita alla 1.3 con qualsiasi altra modifica dalla 1.2 dall'ultima unione, ecc.

Quando eseguo l'impegno, mi assicuro di commentare sempre l'impegno con qualcosa di simile

unito 1.1 rev 5656-5690

Può essere un po' fastidioso, ma funziona :)

Answer 5

Unisci presto, unisci spesso e assicurati che il QA sulla linea principale conosca e regredisca/verifichi i difetti risolti in ciascuna patch delle versioni di manutenzione.

È davvero facile lasciarsi sfuggire qualcosa e "risolvere" un bug in una versione successiva e, lascia che te lo dica, ai clienti non interessa quanto possa diventare complicato gestire più filiali: questo è il tuo lavoro.

Assicurati di utilizzare un sistema di controllo del codice sorgente che supporti la ramificazione e l'unione (ho avuto esperienza con Perforce e SVN e, sebbene Perforce sia migliore, SVN è gratuito).

Ritengo inoltre che avere un'unica persona responsabile dell'esecuzione delle fusioni in modo coerente contribuisca a garantire che avvengano regolarmente.In genere sono stato io o una delle persone senior del nostro team.

Answer 6

Il modo in cui gestiamo questo problema nel mio lavoro è mantenere il ramo trunk come il codice più all'avanguardia (ovvero 2.0 in questo caso).Si crea un ramo per il codice 1.x e si apportano lì tutte le correzioni.Qualsiasi modifica alla versione 1.x dovrebbe essere unita (manualmente, se necessario) nel ramo trunk (2.0).

Vorrei quindi insistere affinché gli sviluppatori 1.x prendano nota sia del numero di revisione per il commit 1.x sia del numero di revisione per l'unione 2.0 nel ticket per quel bug.In questo modo, sarà più facile notare se qualcuno dimentica di unire le proprie modifiche, e il fatto che debbano tenerne traccia lo aiuterà a ricordarlo.

Answer 7

Viene catturato un punto chiave questa immagine da The Build Doctor:unisci solo una direzione.

Answer 8

Per rispondere a questa domanda specifica molti sviluppatori sono passati da Subversion a Git.Acquista github.com.