2015-12-08 38 views
9

La mia domanda si riferisce al primo fattore del manifesto delle app di 12 fattori: il codice base. (vedi http://12factor.net/codebase).Rispetto del fattore codebase (dal manifesto dell'app 12-factor) per un'applicazione Gradle/Spring distribuita su Cloudfoundry o Heroku

TL; DR:

questo fattore afferma c'è un rapporto uno a uno tra le basi di codice e dispiega, quindi in questo caso, non dovresti usare la stessa base di codice (repository) per entrambe le applicazioni

Il mio requisito: Ho un'applicazione Spring del sito Web e un'applicazione batch Spring che condividono entrambi un codice comune, ad esempio il modello di dominio (classi di entità JPA). Devo essere in grado di condividere questo codice comune. E entrambe le applicazioni devono utilizzare la stessa versione del codice comune in qualsiasi momento.

Il mio attuale configurazione: Ho attualmente tre repository "top-level" su GitHub:

  • modello di dominio (classi di entità JPA) pronti contro termine
  • applicazione Sito pronti contro termine modello
    • Domain directory/gradle project (incluso con git subtree pull/push)
  • Batch repo applicazione
    • modello di dominio directory/progetto Gradle (incluso con git subtree pull/push)

Si prega di notare, inoltre, che il modello di dominio repo vive separatamente (come sopra indicato), ma è nidificati anche all'interno del sito Web e dei repository delle applicazioni batch. Io uso un git subtree pull/push per includere questo repository del modello di dominio come una directory e un progetto gradle negli altri due repository. La ragione di ciò è che Heroku costruisce il codice stesso dai repository.

Tutto questo è molto noioso e soggetto a errori.

Qualcuno può consigliare una soluzione migliore?

+0

Non capisco davvero la tua domanda. Puoi abbatterlo ed essere più chiaro? – polka

risposta

2

Vorrei pubblicare il codice comune su un repository Maven privato su Bintray e quindi aggiungere tale repository privato alle altre app consumer e specificare il modulo comune come dipendenza. Ciò non garantisce che entrambi dipenderanno dalla stessa versione ma che potrebbero essere facilmente gestiti tramite processi esterni utilizzando strumenti come the Maven Versions Plugin. Ma potresti anche voler aggiungere un sistema di serializzazione più flessibile per accoppiare liberamente i modelli di dominio delle due app.

-1

Vorrei raggruppare i modelli di dominio in un pacchetto (non sono sicuro che cosa parli java/gradle per tali pacchetti sia, in ruby ​​sarebbe un gioiello) e installarlo in produzione come dipendenza. In caso contrario, è disponibile anche un'opzione

+0

Ciao. Puoi spiegare in che modo ciò è conforme al manifesto dell'applicazione a 12 fattori.Inoltre, si prega di indicare come viene soddisfatta la richiesta in grassetto qui sopra, vale a dire che entrambe le applicazioni devono utilizzare la stessa versione del codice comune in qualsiasi momento. – balteo

+0

Una dipendenza in bundle non farà effettivamente parte della base di codice dell'app. Gli aggiornamenti alle librerie comuni sarebbero gestiti dagli aggiornamenti delle dipendenze anziché dagli aggiornamenti codebase dell'app. Per quanto ne so, questo è uno dei motivi principali per cui sono state create delle dipendenze, anche se sono normalmente utilizzate per importare e utilizzare codice di terze parti. – Achilles