Qual è il modo migliore per gestire il versioning del prodotto e la ramificazione di progetti a lungo termine?


21

In senso generale, per i progetti a lungo termine che possono avere più versioni durante il ciclo di vita dei prodotti e che richiedono il supporto di prodotti precedenti, qual è il modo migliore per gestire le versioni dei prodotti e la ramificazione della base di codice?

In un senso più specifico, supponiamo che sia in atto un adeguato controllo della versione distribuita (ovvero git) e che i team siano di dimensioni da piccole a grandi e che lo sviluppatore possa lavorare su più progetti contemporaneamente. Il problema principale che si sta affrontando è che esiste un obbligo contrattuale a supportare le vecchie versioni esistenti al momento, il che significa che il nuovo sviluppo non può patchare il vecchio codice (i prodotti Microsoft Office potrebbero essere un esempio di questo, si ottengono solo patch per l'anno che possiedi).

Di conseguenza l'attuale versione del prodotto è un tocco contorto in quanto ogni prodotto principale ha dipendenze multiple, ognuna con le proprie versioni che possono cambiare tra le versioni annuali. Allo stesso modo, mentre ogni prodotto ha il proprio repository, la maggior parte del lavoro non viene eseguita sul trunk di origine principale, ma piuttosto su un ramo per quegli anni rilascio del prodotto con un nuovo ramo fatto quando il prodotto viene rilasciato in modo che possa essere supportato. Questo a sua volta significa che ottenere la base di codice di un prodotto non è una cosa semplice come si potrebbe pensare quando si utilizza il controllo versione.


2
Senza ulteriori informazioni su prodotti, progetti e organizzazione dei team di sviluppo, sarà molto difficile fornire una risposta a questo che non è coperto da avvertenze.
ChrisF

@ChrisF - Sto lavorando su alcuni retroscena ma sono abbastanza sicuro che anche altri sviluppatori stiano qui, quindi ho bisogno di proteggere gli innocenti / colpevoli.
rjzii,


La tua scommessa migliore sarebbe quella di controllare altre domande - come quella collegata sopra - e quindi chiedere i bit che non coprono.
ChrisF

@ChrisF - Sì, ho analizzato alcune delle altre domande e ho messo in coda alcune letture basate su di esse, ma non mi ci sono ancora arrivato. Probabilmente ho intenzione di modificare questa domanda molto col passare del tempo. Il problema più grande che stiamo incontrando è il supporto per build precedenti che preclude l'uso del trunk per le pietre miliari della versione che altri hanno menzionato per git.
rjzii,

Risposte:


20

Quanto (e che tipo di) struttura hai bisogno dipende molto da cosa vuoi essere in grado di fare. Scopri cosa non puoi vivere senza, cosa vuoi avere e cosa non ti interessa.

Un buon esempio di decisioni potrebbe essere:

Cose senza le quali non possiamo vivere:

  • essere in grado di ricostruire qualsiasi versione precedente in qualsiasi momento
  • essere in grado di gestire in qualsiasi momento più versioni principali supportate del prodotto

Cose che vorremmo avere:

  • essere in grado di eseguire lo sviluppo delle funzionalità principali in corso (per la prossima versione principale) senza preoccuparsi delle fusioni di filiali
  • essere in grado di eseguire aggiornamenti di manutenzione per le versioni precedenti

Cose che possiamo vivere senza:

  • backporting automatizzato delle modifiche dal lavoro corrente alle versioni precedenti
  • non interrompere mai lo sviluppo delle funzionalità principali nemmeno per alcuni giorni o una settimana alla volta

Se quanto sopra fosse il tuo obiettivo, potresti quindi adottare una procedura come questa:

  1. Fai tutto il lavoro di sviluppo sul bagagliaio del tuo VCS ("master" in git)
  2. Quando sei vicino a una versione principale, interrompi lo sviluppo delle funzionalità principali e concentrati sulla stabilità del sistema per circa una settimana
  3. Quando il trunk sembra stabile, creare un ramo per questa versione principale
  4. Lo sviluppo delle funzionalità principali ora può procedere sul trunk, mentre sul ramo sono consentite solo correzioni di bug e preparazione del rilascio
  5. Tuttavia, tutte le correzioni di bug da apportare al ramo devono prima essere testate sul trunk; questo assicura che saranno presenti anche in tutte le versioni future
  6. Crea un tag (VCS) sul ramo quando sei pronto per il rilascio; questo tag può essere utilizzato per ricreare il rilascio in qualsiasi momento, anche dopo ulteriori lavori sullo stesso ramo
  7. Ulteriori versioni di manutenzione di questa versione principale (versioni secondarie) possono ora essere preparate sulla filiale; ognuno verrà taggato prima del rilascio
  8. Nel frattempo, lo sviluppo di funzionalità principali orientate alla prossima versione principale può continuare sul trunk
  9. Quando ti avvicini a quella versione, ripeti i passaggi precedenti, creando un nuovo ramo di versioni per quella versione . Ciò consente di disporre contemporaneamente di più versioni principali, ognuna nel proprio ramo, nello stato supportato, con la possibilità di rilasciare versioni secondarie separate rispetto a ciascuna.

Questo processo non risponderà a tutte le tue domande - in particolare, avrai bisogno di un processo in atto per decidere quali correzioni possono essere apportate a un ramo di rilascio e per garantire che i bug non vengano corretti prima su un ramo di rilascio (tali correzioni dovrebbe sempre essere testato sul tronco ove possibile). Ma ti darà un quadro in cui prendere tali decisioni.


+1 Tuttavia, aggiungerei che il controllo del codice sorgente è solo una parte del tuo ambiente. Vorrei fare un'istantanea della VM su qualsiasi server di compilazione e anche un'istantanea di un ambiente di sviluppo, in modo da poter andare direttamente in un ambiente di build reale quando è necessario.
Neal Tibrewala,

2
Andrei d'accordo con tutto questo, tranne per il punto 5. Quando si effettua una correzione di bug su un ramo, si dovrebbe preoccuparsi solo di far funzionare quel ramo correttamente. Una volta che la correzione di bug è stata testata su quel ramo, è possibile unire la correzione di bug al trunk o al ramo per una versione più recente. Quindi prova di nuovo e cambia tutto ciò che ti serve per cambiarlo. (continua)
Dawood dice di ripristinare Monica l'

1
Ad esempio, se la versione 4.3 è in fase di sviluppo sul trunk e è necessario correggere un bug nella versione 4.1.x, quindi correggere il bug sul ramo 4.1, testarlo sul ramo 4.1, unirlo al ramo 4.2, test (e possibilmente ripararlo) sul ramo 4.2, unirlo al tronco, quindi testarlo (e possibilmente ripararlo) sul tronco.
Dawood dice di ripristinare Monica l'

1

Il "lungo termine" indica che è necessario il controllo delle versioni, ma non implica alcuna strategia specifica per il controllo delle versioni e delle ramificazioni. La domanda più interessante è quante linee di prodotti o linee di versioni principali si desidera supportare (che dipende dal contratto con i clienti). Avrai almeno bisogno di una filiale per ogni linea di prodotto / linea di versione principale per cui hai un contratto di manutenzione.

D'altra parte, dipende dalle dimensioni della tua squadra. Se hai un grande team di sviluppo, con persone diverse che lavorano su diverse funzionalità in parallelo, avrai ovviamente bisogno di più rami di funzionalità rispetto a un team di una o due persone. Se stai lavorando con un team più grande, dovresti considerare l'utilizzo del controllo della versione distribuita, che rende molto più efficiente il lavoro parallelo su diversi rami (e il loro reinserimento in seguito nel trunk).


Il controllo della versione è attivo (git) ma ci sono alcuni disaccordi su come gestire le versioni dei componenti (probabilmente una domanda separata) e le versioni del prodotto. Attualmente a ogni versione del prodotto viene assegnato un nome in codice e viene creato un nuovo ramo nel repository, il che significa che il nuovo codice è abbastanza remoto dal trunk principale che non viene nemmeno utilizzato in alcuni prodotti.
rjzii,

1

Git è uno strumento di controllo della versione: gestisce le versioni dei file. Quello che stai cercando è uno strumento di gestione della configurazione. Ci sono molti di questi disponibili, ma soprattutto a prezzi elevati da artisti del calibro di IBM.

Gli strumenti di controllo della versione forniscono diramazioni e tag, che consentono una gestione della configurazione scortese senza supporto di strumenti aggiuntivi, quindi gli sviluppatori menay non capiscono la differenza. Le tue esigenze probabilmente vanno oltre ciò che GIT è progettato per fare.

Non sono a conoscenza, ma sono certo che esisterà, un'aggiunta strumento CM per Git.


0

Questa domanda sembra essere molto simile a un'altra a cui ho risposto di recente.

In breve, sembra più un problema di progettazione e distribuzione del prodotto che un problema di controllo / ramificazione della versione. Certo, è facile per me dirlo e più difficile da risolvere se hai già il collo nel problema.

Senza conoscere più in dettaglio i dettagli del tuo problema specifico. In generale, tuttavia, se avessi più versioni di prodotti basate su una base di codice con una grande quantità di codice condiviso tra prodotti, se fosse possibile, cercherei di refactoring i prodotti in modo da renderli più modulari e assicurarsi che i moduli stessi non richiedano ulteriori ramificazioni di codice. Guarderei anche il mio modello di distribuzione, per vedere se esistessero mezzi migliori per supportare i miei clienti mantenendo unificata gran parte della base di codice. Laddove è richiesta una personalizzazione specifica del cliente, potrebbe essere necessaria una maggiore granularità dei moduli per ridurre la quantità di codice duplicato nel sistema.

Non è un compito facile, ma risolvibile in più fasi se si gestisce bene il lavoro e se è possibile pianificare il lavoro in modo da non dover "aggiornare" tutto in una volta.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.