Suggerimento di modello di ramificazione per lo stesso progetto di più client

Naviga le tue risposte
11

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

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

Il nucleo del progetto è simile (ma non uguale) in ogni progetto e l'organizzazione è fatta in modo tale che ci siano team che gestiscono ciascun client in modo indipendente (ma con la comunicazione tra di essi se necessario) . Finora, non sono stato in grado di trovare uno schema che si adatta alle nostre esigenze, sia effettuando ricerche su Internet sia ottenendo qualche idea geniale:)

Finora, abbiamo lavorato ottenendo il prodotto come un seme 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:

  • Diverse pietre miliari per ogni cliente: il che significa che ogni squadra deve produrre versioni come tempi diversi senza che il resto dei commit influisca sulla stabilità o sul loro prodotto.
  • Requisiti diversi, che possono o non possono influire sul core del sistema in alcuni casi.
  • Grandi team (oltre 20 membri del team)
  • Gestione dei bug nel sistema: cosa fai se un team trova un bug nel suo progetto che potrebbe interessare altri client?

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

Nota: utilizziamo il sistema Team Foundation, Visual Studio 2008 e C # (principalmente).

Qualche suggerimento, fonte o idea su come affrontare la situazione? C'è qualche modello sul mercato che ha un problema simile?

    
posta Jorge Córdoba 30.04.2011 - 14:53
fonte

3 risposte

9

In realtà, suggerirei di non aver bisogno di un modello di ramificazione, ma piuttosto di un approccio completo e completo per gestire i vincoli multidimensionali rispetto alla ramificazione di sistema senza . In pratica, credo che sarà sempre un problema mantenere più sistemi che hanno alcune caratteristiche comuni, ma si evolverà in modo diverso nelle filiali, quindi è meglio trasformare tutto in un unico sistema che si evolverà nel suo insieme, ma consiste in diverse configurazioni. Questo può sembrare troppo semplicistico, ma c'è una vasta ricerca in questo campo, con molte applicazioni industriali di successo.

Il nome di questo approccio è Linee prodotto software o talvolta Linea di prodotti . Dalla pagina delle linee di prodotti software CMU SEI :

A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

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

Invece di mantenere tutti questi rami, si finisce per mantenere un sistema insieme a una serie di configurazioni specifiche del cliente.

Potrebbe essere difficile o addirittura impossibile, in pratica, migrare a un simile approccio con un sistema molto ampio, ma anche in questo caso sarà utile indagare sugli approcci utilizzati in SPL per valutare quali approcci utilizzati possono essere almeno (parzialmente) integrato nel tuo lavoro.

Alcuni link utili aggiuntivi:

risposta data 30.04.2011 - 21:53
fonte
11

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

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

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

    
risposta data 30.04.2011 - 16:51
fonte
2

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

Ad esempio

  • versione 1.0 richiede Libreria A 1.0, Libreria B 2.0, Libreria C 5.6
  • versione 2.0 richiede Libreria A 1.0, Libreria B 3.7, Libreria C 5.7
  • 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 delle versioni (li costruiamo all'origine) e di far sì che ogni progetto utilizzi la versione della libreria corretta cambiando il percorso di ricerca (percorso di riferimento?) .

In Delphi questo è 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ù doloroso dato che devi cambiare il Delphi IDE per usare anche la versione corretta (i file di registrazione (.reg) sotto controllo di versione possono venire in soccorso qui).

Una soluzione per il tuo sistema principale potrebbe essere trattarla come una libreria per la quale mantieni diverse versioni. Ciò significa in sostanza 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 core appropriato.

Dove le dipendenze per il tuo core system sarebbero quindi simili all'esempio sopra, le dipendenze per le tue applicazioni client quindi "solo" hanno un riferimento in più: la versione del tuo core system.

Un ulteriore vantaggio con più applicazioni client qui è che puoi scegliere quando iniziare a utilizzare una versione specifica del tuo sistema principale e che non sei influenzato dalle modifiche al sistema principale che non sei ancora pronto per utilizzare per un cliente specifico applicazione.

    
risposta data 30.04.2011 - 18:59
fonte

Leggi altre domande sui tag

Quali lezioni hai imparato da un progetto che quasi / effettivamente fallisce a causa di un cattivo multithreading? [chiuso] Che cosa fanno i progettisti di linguaggi per decidere o dimostrare che una particolare funzionalità funziona correttamente?