Una metologia che consente un singolo codice Java che copre molte versioni differenti?

Question

Io lavoro in un piccolo negozio dove abbiamo un sacco di codice Cobol legacy e dove è stata adottata una metologia che ci permette di ridurre al minimo il biforcarsi e ramificarsi il più possibile.

Per una data di rilascio abbiamo tre livelli:

• CORE - il livello di fondo, questo codice è comune a tutte le emissioni
• GROUP - Codice optional comuni a più clienti.
• CUSTOMER - codice opzionale specifico per un singolo cliente.

Quando un programma è necessario, viene prima cercato in CLIENTE, quindi in GRUPPO e infine in CORE. Una determinata applicazione per noi richiama molti programmi che sono tutti cercati in questa sequenza (si pensi ai file exe e al PERCORSO in Windows).

Abbiamo anche programmi Java che interagiscono con questo codice legacy, e poiché il mehchanism di ricerca del gruppo principale-cliente non si presta facilmente a Java, è cresciuto in un ramo CVS per ogni cliente, richiedendo troppo manutenzione. La parte Java e la parte backend tendono ad essere sviluppate in parallelo.

Sono stato assegnato a capire un modo per far incontrare i due mondi.

In sostanza, vogliamo un ambiente Java che ci consenta di disporre di un'unica base di codice con origini per ogni versione, in cui è facile selezionare un gruppo e un cliente e lavorare con l'applicazione come per quel cliente, quindi facilmente passare ad un altro codeset e THAT customer.

Stavo pensando a uno scenario con un progetto Eclipse per ogni core, cliente e gruppo e quindi uso i set di progetto per selezionare quelli necessari per un determinato scenario. Il problema che non riesco a capire è come creeremo codice robusto nei progetti CORE, che funzionerà indipendentemente dal gruppo e dal cliente selezionato. Una classe factory che conosce quale sottoclasse di un oggetto Class passato da invocare invece di ogni nuovo?

Altri devono avere avuto problemi di gestione della base di codice simili. Qualcuno con esperienze da condividere?

---

EDIT: La conclusione di questo problema sopra è stato quello CVS deve essere sostituito con un sistema di gestione del codice sorgente più adatto per trattare molti rami contemporaneamente e la migrazione di sorgente da un componente all'altro mantenendo storia. Ispirato alla recente migrazione di slf4j e al logback, stiamo attualmente esaminando git perché gestisce i rami molto bene. Abbiamo preso in considerazione anche la sovversione e il mercurial, ma git sembra essere migliore per i progetti multibranched. Ho chiesto di Perforce in un'altra domanda, ma la mia personale inclinazione è verso soluzioni open source per qualcosa di così cruciale.

---

EDIT: Dopo un po 'di più riflettere, abbiamo scoperto che il nostro punto di dolore reale è che usiamo filiali in CVS, e che si dirama in CVS sono le più facili con cui lavorare se si diramano tutti i file! La conclusione rivista è che noi possiamo fare questo con CVS da solo, passando a una foresta di progetti java, ognuno corrispondente ad uno dei livelli sopra, e usare i percorsi di costruzione di Eclipse per legarli insieme in modo che ogni versione CUSTOMER attinga appropriato progetto GROUP e CORE. Vogliamo ancora passare a un sistema di controllo delle versioni migliore, ma questa è una decisione così importante, quindi vogliamo ritardarla il più possibile.

---

EDIT: ora ho un implementazione proof-of-concept del concetto CORE-GRUPPO-cliente che utilizza Google Guice 2.0 - il tag @ImplementedBy è proprio quello che ci serve. Mi chiedo che cosa fanno tutti gli altri? Usando se è dappertutto?

---

MODIFICA: ora mi serve anche questa funzionalità per le applicazioni Web. Guice è stato fino a quando la JSR-330 è a posto. Qualcuno con esperienza di versioning?

---

EDIT: JSR-330/299 è ora in atto, con l'implementazione di riferimento JEE6 saldatura sulla base di JBoss Seam e ho reimplementato il proof-of-concept con saldatura e può vedere che se usiamo @Alternative lungo con ... in beans.xml possiamo ottenere il comportamento che desideriamo. Cioè fornire una nuova implementazione per una determinata funzionalità in CORE senza cambiare un po 'nei jar CORE. La lettura iniziale delle specifiche Servlet 3.0 indica che potrebbe supportare la stessa funzionalità per le risorse dell'applicazione (non codice). Effettueremo i test iniziali sull'applicazione reale.

Answer 1

Mi scuso in anticipo per non aver risposto direttamente alla sua domanda. Mi stai chiedendo "come possiamo progettare il nostro software per evitare di dover eseguire un determinato tipo di ingegneria del rilascio?" Non conosco la risposta a questa domanda, ma ho letto la tua descrizione, e sono preoccupato per questo. root, penso che sia un gioco perdente per far sì che il tuo core engineering del software abbia bisogno di sottomettere alle tue tecnologie di rilascio del firmware

In altre parole, se i tuoi clienti hanno davvero bisogno di rilasci separati, allora dovrai occupartene Quello che ho letto è che tu vuoi usare Eclipse per fare il lavoro che il tuo software di controllo della versione dovrebbe fare per te, non mi sembra una soluzione valida

Scommetto che puoi vedere dove sono Andiamo con questo: se il problema è in realtà "ramificarsi nel CVS è troppo doloroso", allora penso che la soluzione tecnica è "migrare verso CVS verso qualcosa che permetta una ramificazione e integrazione più robusta e più semplice."

Nel mondo del software libero, che in genere significa Subversion. Una buona alternativa commerciale è Perforce. Posso dire che ho lavorato per una società che ha rilasciato più versioni di software a molti clienti e spesso ha integrato i cambiamenti da una filiale all'altra. Abbiamo usato Perforce e la ramificazione (e l'integrazione) è stata abbastanza facile che ogni ingegnere ha potuto e fatto su base regolare senza interrompere il lavoro quotidiano.

Spero che questo aiuti.

Answer 2

Sono d'accordo con @peterb, Eclipse non è il modo per gestirlo. Branching nel tuo sistema di controllo del codice sorgente ha lo scopo di servire a questo scopo, quindi sceglierne uno che renda il più semplice possibile (Subversion dovrebbe funzionare bene).

Si consiglia inoltre di prendere in considerazione l'utilizzo di Maven (o qualcosa di simile) per definire la gestione delle dipendenze per i diversi scenari dei clienti. Quindi puoi generare sia i tuoi progetti Eclipse da parte di Maven per eseguire il tuo sviluppo effettivo, sia i build di rilascio.