Progetto Java che diventa troppo grande

Question

Abbiamo un grande progetto Java 8 Spring Hibernate Maven che si sta ingrandendo.

Problemi:

• tempo di compilazione è 10-12 minuti al meglio; 3 minuti senza prove
• Abbiamo già un commando da riga di comando per saltare i moduli modificati raramente, che è il sintomo del processo di costruzione che raggiunge limiti pratici
• Eclipse sta faticando a gestire il progetto (anche se IntelliJ è ok per ora)
• Le cose stanno peggiorando man mano che il progetto cresce e dal momento che più scenari del team di test vengono integrati come test di integrazione nel codice base.

Come lavoriamo ora

• Il progetto è configurato in circa 20 moduli Maven, in questo modo:

 
    Parent 
    |--- Tier1 
    |--- Tier2 
    |--- WebTier 
     |---- ModuleA 
     |---- ModuleB 
     |---- ModuleC 
     |---- ... 
     |---- Entities 
     |---- Shared 
     |---- Batch 
     |---- IntegrationTests 

• L'applicazione è costruita come una singola GUERRA
• Gli sviluppatori distribuiscono un singolo livello (tipicall y WebTier) come artefatto da Eclipse o IntelliJ al loro Tomcat locale
• Anche se il progetto sembra diviso in modo graduale nei moduli, ci sono molti punti di accoppiamento indesiderati tra di loro. Specialmente in Shared, in cui i moduli che necessitano di "cross-moduli" accesso mettono i loro servizi
• Tutti i test di integrazione sono in un modulo dedicato (idea del perché)

idee per rendere meglio

• Aggiungere un modulo MessageBroker per consentire l'accoppiamento lento, se del caso. Forse JMS, o semplicemente un componente muto in memoria per la comunicazione sincrona
• Sbarazzarsi del modulo Shared
• Assicurarsi che i moduli hanno a grana grossa punti di entrata
• Rimuovere accoppiamento indesiderato tra fratelli e preferiscono il broker messaggio quando possibile
• Potrebbe mantenere Entities. Almeno le entità del core-business (Cliente, CustomerFile, ...). Ma alcune entità, ovviamente, appartengono ad un singolo modulo (Info esecuzione lotto sarebbe nel modulo Batch)

In questo modo, chiunque fare un cambiamento per ModuleA sarebbe il più delle volte solo costruire e eseguire i test in quel modulo senza temendo di rompere l'applicazione.

Domande

• Ti sembra come un buon piano?Per buono intendo a prova di futuro, con buone possibilità di migliorare le cose, e non richiedendo una quantità eccessiva di lavoro data la situazione
• Se avessimo 1 progetto Eclipse/IJ per livello, lascia che l'IDE costruisca il manufatto e lo distribuisca a Tomcat, o dovremmo avere 1 progetto per modulo e dipendenze verso Nexus? O forse la seconda opzione è eccessiva?
• Altri suggerimenti?

Alcune metriche

• di Windows 7, Java 8, Maven 3.0.3, TestNG.
• SSD o HDD 7200rpm (impatto limitato)
• 6Gb di RAM
• Heap 1Gb (Maven)
• CI con Jenkins

Grazie un mazzo!

Answer 1

CI sarebbe una risposta reale ma sembra che il tuo progetto non sia modulare come dovrebbe essere. Non costruisci l'intero progetto da zero ogni volta. Costruisci barattoli, li collaudi in diversi progetti e poi li usi come singoli elementi. Ogni progetto dovrebbe essere abbastanza piccolo e coprire solo un'area. Pensi che i build Java dicano i barattoli di sicurezza quando funzionano sul pacchetto io? Dividi e conquista: questa è l'intera idea di OOP e incapsulamento.

Answer 2

Questo potrebbe non essere così male come pensi. I progetti coinvolti con test unitari e analisi statiche richiedono un po 'di tempo.

Una società per la quale ho lavorato aveva> 1 ora di costruzione + unitàTest + CodeCover tempi di integrazione. Ciò non conta il tempo necessario per spedire l'artefatto a vSphere per il test di click-through automatico dell'installatore su 26 lingue x 8 sistemi operativi supportati.