Controllo origine / versione per l'applicazione utilizzata da più società

Il supporto di un prodotto personalizzato per più clienti non è un problema di controllo della versione. È un problema di progettazione e distribuzione.

Mantenere più basi di codice è un vero dolore. È già abbastanza grave dover duplicare la base di codice per supportare più piattaforme e linguaggi, per non parlare di più clienti. Meglio invece costruire un prodotto modulare. Certo, ci saranno elementi che richiederanno un maggior grado di personalizzazione e una piccola percentuale di sovrapposizione in cui il codice potrebbe dover essere effettivamente duplicato, ma è meglio creare un sistema modulare molto finemente strutturato per far fronte, invece di tentare ramificarsi dove il rischio è che i rami possano divenire così divergenti da non poter mai unire.

Io stesso lavoro su un'API che attualmente supporta 3 piattaforme hardware e più di 3 clienti. Come minimo, avremmo bisogno di gestire 9 basi di codice separate se il nostro codice non fosse progettato per essere modulare sin dall'inizio. Quando sono arrivato per la prima volta in azienda circa 10 anni fa, la base di codice esistente utilizzava le direttive condizionali del compilatore per gestire 3 varianti su una singola piattaforma, era circa 50 volte più piccola della presente incarnazione dell'API e richiedeva il doppio dello sforzo di manutenzione. Ci è voluto molto lavoro, ma ora abbiamo un prodotto che non ha mai bisogno di essere ramificato e sarà in grado di supportare letteralmente qualsiasi numero di client, piattaforme e personalizzazioni.

Quindi, per rispondere in modo specifico alla tua domanda, è meglio mantenere un singolo ramo principale a condizione di implementare un design che supporterà un approccio di sviluppo più modulare e se la tua personalizzazione è richiesta per non essere disponibile per più di un singolo cliente, quindi risolvi il problema nel modo in cui i tuoi moduli sono accessibili dal tuo codice e in che modo vengono distribuiti.

Mentre S.Robins è corretto quando dice che questo è un problema di progettazione e distribuzione non un problema di controllo della versione , dobbiamo essere pragmatici. Se non riesci a riprogettare il tuo prodotto (per utilizzare iniezione di dipendenza per la configurazione, ad esempio), potresti ancora essere in grado di utilizzare il tuo VCS per aiutarti a gestire la complessità introdotta dal tuo design.

Il grosso problema con l'utilizzo delle filiali per mantenere versioni diverse di un prodotto per diversi clienti è la gestione dell'ambito e degli effetti collaterali delle unioni.

Se sviluppi sempre nuove funzionalità al di fuori della filiale specifica del cliente, e solo sempre apporterai modifiche specifiche del cliente nel ramo cliente, allora starai bene. Le nuove funzionalità possono essere estratte dal ramo della funzione e le modifiche del cliente non devono mai essere unite su .

I problemi arrivano quando si tenta di aggiungere una nuova funzione in una filiale del cliente o di correggere un bug e quindi estrarre tali modifiche dal ramo del cliente. Quindi devi essere molto attento per non eseguire modifiche specifiche del cliente insieme a loro.

Avendo già lavorato in un ambiente del genere e sperimentato il dolore di districare un'unione sconsiderata, ora lavorerei in un altro modo se avessi bisogno di supportare nuovamente questo tipo di ambiente.

Inserirò tutte le modifiche specifiche del cliente in una coda di patch, gestita in un repository per cliente separato dal repository di codice principale (o repository).

Con Mercurial , ti suggerisco di dare un'occhiata a Mercurial Queues , un'estensione che viene fornita di serie con TortoiseHg (devi solo abilitarlo). Con git , quindi questa risposta per git equivalente a hg mq? ha alcuni puntatori eccellenti per equivalenti funzionalità git .

L'ultima cosa che vuoi è una versione diversa del tuo codice sorgente per diversi client. Mantenere sincronizzate tutte queste versioni mentre si aggiungono funzionalità e si risolvono i bug sarà un enorme problema e più a lungo si opera in questo modo, più difficile sarà risolvere il problema.

Una soluzione molto migliore è quella di rendere il software configurabile in tutti gli aspetti che i clienti desiderano personalizzare e creare file di configurazione separati per ciascun client. Non è necessario consegnare i file di configurazione ai client: le configurazioni potrebbero essere file di origine incorporati in ogni versione consegnata a un client, se si creano build separati per ciascun client. Alla fine, tuttavia, con l'aumentare dell'elenco dei client, sarà probabilmente più semplice creare un singolo binario da consegnare a tutti i client insieme ai file di configurazione personalizzati.

Contrariamente alle risposte precedenti, autori dei quali vivono nel mondo ideale, devo dire: I rami (con buon VCS) sono single way (non "più facili": solo perché non ci sono modo più difficile ) per mantenere la personalizzazione del cliente.

Le fusioni permanenti dal ramo di vaniglia alla dogana non sono facili, ma - funziona