Mantenimento di una linea di progetto principale con progetti satellite

Question

Mantenimento di una linea di progetto principale con progetti satellite

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

3

Alcuni progetti su cui lavoro hanno una linea principale di funzionalità, ma sono personalizzabili per cliente. Fino ad ora queste personalizzazioni sono state implementate come preferenze, ma ora ci sono 2 problemi con il sistema ...

La pagina delle impostazioni sta uscendo controllo con funzionalità. Ci sono probabilmente alcuni miglioramenti potrebbe essere fatto per l'interfaccia utente delle impostazioni, ma a prescindere, è abbastanza ingombrante impostare nuove istanze per i nuovi clienti.
I clienti hanno iniziato a chiedere personalizzazioni che sarebbero più facilmente mantenuto come separato discussioni invece di avere tonnellate di codice personalizzazioni.

In modo ottimale sto immaginando una sorta di controllo del codice sorgente in cui le funzioni sono nella linea principale del progetto e le personalizzazioni per cliente sono mantenute in un repository per impostazione del cliente. Le personalizzazioni per progetto dovrebbero rimanere separate, ma se un bug viene trovato e risolto in un particolare progetto, avrei bisogno di ricollocare la correzione sulla linea principale e in tutti gli altri repository clienti.

Il problema è che non l'ho mai visto prima, e prima di passare il tempo a cercare il controllo del codice sorgente che possa adattarsi a questo scenario e implementarlo, immagino che sia meglio chiedere a qualcuno se qualcosa di meno complicato o di un controllo sorgente prodotto che può gestire questo con pochissima trazione dei capelli.

version-control

posta Nick Larsen 01.02.2011 - 03:31

fonte

3 risposte

Leggi altre domande sui tag version-control

Cosa fare quando sono necessarie le proprietà di HashMap e ArrayList? È considerata una cattiva pratica di codifica scrivere metodi / proprietà che supportano (solo) test? [duplicare]

score 4 · Answer 1

Poiché stai già parlando di creare build separate per ogni cliente, perché non implementare ciascuna funzionalità con il proprio switch di compilazione. Quindi, quando si crea un makefile separato per ogni cliente con i #define appropriati inclusi. Ciò ti consentirebbe quanto segue:

C'è solo un posto dove sistemare i bug, questo da solo vale molto perché avere più posti per controllare una correzione è una bomba a orologeria. Non importa quanto duramente ci provi, ci saranno dei cambiamenti che non si trasformeranno in tutti i rami, se non altro per caso.
Se un altro cliente richiede una funzionalità già implementata, è sufficiente aggiungere la definizione al makefile.

score 2 · Answer 2

Abbiamo un paio di prodotti con qualcosa di simile.

Un sistema è configurato avendo librerie con il codice base e altro supporto e quindi le app specifiche per il cliente (in termini di codice) relativamente piccole vengono create utilizzando tali librerie. Questo è per le modifiche basate sul codice.

Un altro prodotto ha una base di codice singola e genera pacchetti di configurazione per ciascun sistema da installare. Il codice è installato, quindi viene installato il pacchetto di configurazione per quel sistema. I pacchetti di configurazione sono creati da file all'interno della stessa base di codice del file eseguibile dell'esecuzione.

score 1 · Answer 3

Questo è sicuramente possibile con la ramificazione. Immagina la tua linea di prodotti principale come un fiume. Faresti dei rami per i singoli clienti, questi sarebbero affluenti al largo del fiume. Lo sviluppo del prodotto primario continuerebbe sulla linea di prodotti principale e quando le caratteristiche sono pronte per gli altri rami, le unireste (essenzialmente il fiume torna di nuovo negli affluenti). A volte, un problema viene identificato e riparato su un ramo, se la correzione è utile per la linea di prodotti principale viene ricondotta al main e da lì può essere unita agli altri rami.

Se utilizzi Visual Studio e TFS, è disponibile un documento che descrive varie strategie di ramificazione incluso quello appena citato.

Se hai la possibilità di scegliere il controllo della versione (ad esempio, non ti sei ancora impegnato su uno), sceglierei uno dei DVCS (Distributed Version Control Systems) come Git, Mercurial o Bazaar. Branching and merging è molto più semplice con loro.