Suggerimenti sul modello di diramazione per più client dello stesso progetto

Abbiamo un grande progetto che include diverse applicazioni che fungono da base per diversi clienti.

Ogni cliente ha la propria personalizzazione del prodotto, pietre miliari diverse, requisiti diversi e così via, e quindi ogni progetto si evolverà indipendentemente sulla base delle proprie esigenze.

Il nucleo del progetto è simile (ma non uguale) in ogni progetto e l'organizzazione è realizzata in modo tale che ci siano team che gestiscono ciascun cliente in modo indipendente (ma con comunicazione tra di loro secondo necessità). Finora, non sono stato in grado di trovare uno schema adatto alle nostre esigenze, cercando in Internet o trovando un'idea geniale :)

Finora, abbiamo lavorato ottenendo il prodotto adatto a tutte le esigenze, con rami specifici per le modifiche necessarie ma, sebbene il prodotto abbia una buona architettura, sta lentamente diventando un grosso problema. Ecco i principali problemi che affrontiamo:

• Pietre miliari diverse per ogni cliente: ciò significa che ogni squadra deve produrre versioni come tempi diversi senza che il resto degli impegni influenzi la stabilità o il loro prodotto.
• Requisiti diversi, che possono o meno influire sul nucleo del sistema in alcuni casi.
• Team di grandi dimensioni (oltre 20 membri del team)
• Gestione dei bug nel sistema: cosa fai se una squadra trova un bug nel suo progetto che potrebbe interessare altri clienti?

Nota: stiamo parlando di un progetto che ha 10 + M LOC.

Nota: stiamo utilizzando Team Foundation System, Visual Studio 2008 e C # (principalmente).

Qualche suggerimento, fonte o idea su come affrontare la situazione? Esiste un modello sul mercato che presenta un problema simile?

In realtà, suggerirei che non è necessario un modello di diramazione, ma piuttosto un approccio completo completo per gestire i vincoli multidimensionali in relazione al sistema senza diramazione. In pratica, credo che sarà sempre un problema mantenere più sistemi che hanno alcuni punti in comune ma si evolveranno in modo diverso nei rami, quindi è meglio trasformare tutto in un unico sistema che si evolverà nel suo insieme, ma è costituito da diverse configurazioni. Ciò può sembrare troppo semplicistico, ma esiste una ricerca approfondita in questo settore, con molte applicazioni industriali di successo.

Il nome per questo approccio è Software Product Lines o talvolta Product Line Engineering . Dalla pagina Linee di prodotti software di CMU SEI :

Una linea di prodotti software (SPL) è un insieme di sistemi ad alta intensità di software che condividono un insieme comune e gestito di funzionalità che soddisfano le esigenze specifiche di un particolare segmento di mercato o missione e che sono sviluppati da un insieme comune di risorse principali in un modo prescritto .

L'idea chiave è che ogni requisito, ogni pietra miliare, ogni caratteristica (un termine chiave in questo dominio) fa parte del sistema completo al più alto livello. I sistemi attuali distribuiti a vari clienti sono essenzialmente una raccolta di funzionalità. Tuttavia, ogni funzione non è solo un componente fisico integrato nel sistema, ma è definito come dipendente o abilitato da altre funzionalità (in modo che, selezionando una funzione, è possibile includerne automaticamente le dipendenze, ecc.)

Invece di mantenere tutte queste filiali, si finisce per mantenere un sistema insieme a una serie di configurazioni specifiche del cliente.

In pratica può essere difficile o addirittura impossibile migrare a un tale approccio con un sistema molto ampio, ma anche in quel caso sarà utile investigare gli approcci utilizzati in SPL al fine di valutare quali approcci utilizzati possono almeno essere (parzialmente) integrato nel tuo lavoro.

Alcuni link utili aggiuntivi:

• Wikipedia: ingegneria della linea di prodotti
• Casi studio di CMU SEI
• Software Product Lines , un sito con molto materiale introduttivo.

Quando ho iniziato il mio primo lavoro, ho lavorato su progetti simili (ma con scala minore) e abbiamo riscontrato gli stessi problemi. Abbiamo anche iniziato con i requisiti generali di gestione della soluzione per tutti i clienti, ma ciò è stato possibile solo allo stesso punto in cui i requisiti diventano contraddittori. Abbiamo fatto ciò che hai suggerito e avviato una versione separata per ciascun client. Anche questo ha risolto il problema con requisiti e personalizzazione che diventa un incubo di manutenzione per la risoluzione di bug e cambiamenti globali.

Poiché il codice nell'applicazione era solo simile, l'unione delle modifiche da una versione del cliente a un'altra era molto complessa e richiedeva di ripetere il test di ciascuna versione separatamente (non avevamo test automatici!). Spesso causava bug di regressione in diverse versioni. Nel tuo scenario questo può essere anche peggio perché una squadra risolverà il bug nella sua versione e un'altra squadra dovrà unire quella modifica dalla versione che non comprendono completamente (eravamo una squadra che lavorava su tutte le versioni).

A meno che tu non abbia un nucleo globale condiviso, avrai gli stessi problemi. Prima di lasciare l'azienda abbiamo scoperto che il nostro approccio era errato. Per supportare tale scenario di sviluppo, avevamo bisogno di un modello di dati e core estendibile condiviso che sarà configurabile dai livelli applicativi superiori personalizzabili. Questo core dovrebbe essere usato come base per ogni personalizzazione specifica del cliente e gestito da un team separato. Comprenderà alcune complicazioni gestionali perché più project manager avranno bisogno delle risorse dello stesso team, ma è l'unico modo per rendere coerente l'architettura, controllare l'intero processo e mantenere sincronizzate le versioni.

Potrei essere un modo di base, ma penso che ciò che stai affrontando con il tuo core del tuo sistema sia lo stesso problema che tutti affrontano chi usa componenti e ha bisogno di mantenere e supportare diverse versioni del loro software e quelle diverse versioni richiedono ciascuna un set diverso delle versioni dei componenti.

Per esempio

• la versione 1.0 richiede la libreria A 1.0, la libreria B 2.0, la libreria C 5.6
• la versione 2.0 richiede la libreria A 1.0, la libreria B 3.7, la libreria C 5.7
• la versione 3.0 richiede la libreria A 1.2, la libreria B 3.7, la libreria C 5.8

Il modo in cui abbiamo risolto il problema del componente è di avere tutte le versioni delle librerie nel nostro sistema di controllo della versione (le costruiamo sul sorgente) e di far sì che ogni progetto usi la versione corretta della libreria cambiando il loro percorso di ricerca (percorso di riferimento?).

In Delphi questo viene fatto facilmente attraverso il file di configurazione del progetto (sotto il controllo del codice sorgente) se non hai bisogno delle librerie in fase di progettazione, altrimenti è ancora fattibile ma diventa un po 'più complicato perché devi cambiare l'IDE Delphi per usare anche la versione corretta (i file di registrazione (.reg) sotto il controllo della versione possono venire in soccorso qui).

Una soluzione per il tuo sistema principale potrebbe essere quella di trattarla come una libreria per la quale gestisci versioni diverse. Il che in sostanza significa che è necessario impostare diversi rami per ogni versione. L'applicazione di un client può quindi utilizzare la "versione" corretta del sistema principale facendo riferimento alla cartella di diramazione del sistema principale appropriato.

Laddove le dipendenze per il tuo sistema principale assomigliano quindi all'esempio sopra, le dipendenze per le tue applicazioni client hanno "solo" un riferimento in più: la versione del tuo sistema principale.

Un ulteriore vantaggio con l'applicazione client multipla è che puoi scegliere quando iniziare a utilizzare una versione specifica del tuo sistema principale e che non sei interessato dalle modifiche al sistema principale che non sei ancora pronto per l'uso per un'applicazione client specifica.