Java Web Deployment: codice build o deploy .war?

Question

Due modi principali per distribuire un'app Web J2EE / Java (in un senso molto semplicistico):

Distribuisci i manufatti assemblati nella scatola di produzione

Qui creiamo il .war (o qualsiasi altra cosa) altrove, configuriamo per la produzione (possibilmente creando numerosi artefatti per numerose scatole) e posizioniamo gli artefatti risultanti sui server di produzione.

• Pro : nessuno strumento di sviluppo sulle scatole di produzione, può riutilizzare gli artefatti dai test direttamente, il personale che esegue la distribuzione non ha bisogno di conoscenza del processo di compilazione
• Contro : due processi per la creazione e la distribuzione di artefatti; una configurazione potenzialmente complessa di artefatti pre-costruiti potrebbe rendere difficile il processo di script / automazione; devi manufatti binari versione

Crea gli artefatti su la casella di produzione

Qui, lo stesso processo utilizzato quotidianamente per compilare e distribuire localmente su scatole di sviluppatori viene utilizzato per distribuire in produzione.

• Pro : un processo da mantenere; ed è fortemente testato / validato da un uso frequente. Potenzialmente più facile da personalizzare la configurazione al momento della creazione del manufatto piuttosto che personalizzare la postfazione del manufatto precostruita; non è necessario il controllo delle versioni degli artefatti binari.
• Contro : strumenti di sviluppo potenzialmente complessi necessari su tutte le scatole di produzione; il personale addetto alla distribuzione deve comprendere il processo di compilazione; tu non stai distribuendo ciò che hai testato

Ho usato principalmente il secondo processo, certamente per necessità (nessun tempo / priorità per un altro processo di distribuzione). Personalmente non compro argomenti come " la scatola di produzione deve essere pulita da tutti i compilatori, ecc. & Quot ;, ma posso vedere la logica nella distribuzione di ciò che hai testato (al contrario di costruire un altro manufatto).

Tuttavia, le applicazioni Java Enterprise sono così sensibili alla configurazione, è come chiedere problemi con due processi per la configurazione degli artefatti.

Pensieri?

Aggiornamento

Ecco un esempio concreto:

Usiamo OSCache e abilitiamo la cache del disco. Il file di configurazione deve essere all'interno del file .war e fa riferimento a un percorso di file. Questo percorso è diverso in ogni ambiente. Il processo di generazione rileva la posizione configurata dall'utente e garantisce che il file delle proprietà inserito nella guerra sia corretto per il suo ambiente.

Se dovessimo utilizzare il processo di compilazione per la distribuzione, si tratterebbe di creare la giusta configurazione per l'ambiente di produzione (ad esempio production.build.properties ).

Se dovessimo seguire gli "artefatti assemblati nella scatola di produzione", avremmo bisogno di un processo aggiuntivo per estrarre le proprietà (errate) di OSCache e sostituirle con una appropriata all'ambiente di produzione.

Questo crea due processi per realizzare la stessa cosa.

Quindi, le domande sono:

• È evitabile senza "compilare sulla produzione"?
• In caso contrario, ne vale la pena? È il valore di "nessuna compilazione sulla produzione" maggiore di " Non ripetere te stesso " ;?

Answer 1

Sono fermamente contrario a costruire sulla scatola di produzione, perché significa che stai usando una build diversa da quella con cui hai testato. Significa anche che ogni macchina di distribuzione ha un diverso file JAR / WAR. Se non altro, fai una build unificata solo in modo tale che durante il tracciamento dei bug non dovrai preoccuparti di incoerenze tra i server.

Inoltre, non è necessario mettere le build nel controllo versione se è possibile mappare facilmente tra una build e l'origine che l'ha creata.

Dove lavoro, il nostro processo di distribuzione è il seguente. (Questo è su Linux, con Tomcat.)

1. Verifica le modifiche e verifica in Subversion. (Non necessariamente in questo ordine; non richiediamo che il codice di commit sia testato. Sono l'unico sviluppatore a tempo pieno, quindi l'albero SVN è essenzialmente il mio ramo di sviluppo. Il tuo chilometraggio può variare.)

2. Copia i file JAR / WAR su un server di produzione in una directory condivisa che prende il nome dal numero di revisione di Subversion. I server Web hanno solo accesso in lettura.

3. La directory di distribuzione contiene collegamenti simbolici relativi ai file nelle directory con nome di revisione. In questo modo, un elenco di directory ti mostrerà sempre quale versione del codice sorgente ha prodotto la versione in esecuzione. Durante la distribuzione, aggiorniamo un file di registro che è poco più di un elenco di directory. Ciò semplifica il rollback. (Un gotcha, però; Tomcat verifica la presenza di nuovi file WAR entro la data di modifica del file reale, non il collegamento simbolico, quindi dobbiamo toccare il vecchio file quando eseguiamo il rollback.)

I nostri server Web scompattano i file WAR in una directory locale. L'approccio è scalabile, poiché i file WAR si trovano su un singolo file server; potremmo avere un numero illimitato di server Web e fare una sola distribuzione.

Answer 2

La maggior parte dei posti in cui ho lavorato hanno utilizzato il primo metodo con informazioni di configurazione specifiche per l'ambiente distribuite separatamente (e aggiornate molto più raramente) al di fuori della guerra / orecchio.

Answer 3

Consiglio vivamente " Distribuisci manufatti assemblati nella scatola di produzione " come un file di guerra. Questo è il motivo per cui i nostri sviluppatori usano lo stesso script di compilazione (nel nostro caso Ant) per costruire la guerra sul loro sandbox di sviluppo, così come viene usato per creare l'artefatto di fine. In questo modo viene eseguito il debug e il codice stesso, per non parlare del tutto ripetibile.

Answer 4

Esistono servizi di configurazione, come ZooKeeper e la maggior parte dei contenitori abilita utilizzare JNDI per eseguire alcune configurazioni. Questi separeranno la configurazione dalla build, ma possono essere eccessivi. Tuttavia, esistono. Molto dipende dalle tue esigenze.

Ho anche usato un processo in base al quale gli artefatti vengono creati con segnaposto per i valori di configurazione. Quando viene distribuito, il WAR viene esploso e i segnaposto vengono sostituiti con i valori appropriati.

Answer 5

Vorrei sostenere l'uso di una soluzione di integrazione continua che supporti build distribuite. Il codice registrato nel tuo SCM può attivare build (per test immediati) e puoi pianificare build per creare artefatti per il QA. È quindi possibile promuovere questi manufatti in produzione e disporli.

Questo è attualmente ciò su cui sto lavorando alla configurazione, utilizzando AnthillPro .

EDIT: ora stiamo utilizzando Hudson . Consiglio vivamente!

Answer 6

Se stai ponendo questa domanda relativa alla gestione della configurazione, la tua risposta deve essere basata su quello che consideri un artefatto gestito. Dal punto di vista CM, è inaccettabile che alcune raccolte di file sorgente funzionino in un ambiente e non in un altro. CM è sensibile alle variabili di ambiente, alle impostazioni di ottimizzazione, al compilatore e alle versioni di runtime, ecc. E devi tenere conto di queste cose.

Se stai ponendo questa domanda relativamente alla creazione di processi ripetibili, la risposta deve essere basata sulla posizione e sulla quantità di dolore che sei disposto a tollerare. L'uso di un file .war può comportare una maggiore sofferenza iniziale al fine di risparmiare fatica nei cicli di test e distribuzione. L'uso dei file di origine e degli strumenti di creazione può risparmiare costi iniziali, ma dovrai affrontare ulteriori problemi nel gestire i problemi in ritardo nel processo di distribuzione.

Aggiornamento per esempio concreto

Due cose da considerare rispetto al tuo esempio.

1. Un file .war è solo un file .zip con un'estensione alternativa. È possibile sostituire il file di configurazione in atto utilizzando le utilità zip standard.

2. Potenzialmente riconsiderare la necessità di inserire il file di configurazione nel file .war. Sarebbe sufficiente averlo sul percorso di classe o avere le proprietà specificate nella riga di comando di esecuzione all'avvio del server.

In genere, tento di mantenere i requisiti di configurazione della distribuzione specifici per il percorso di distribuzione.

Answer 7

L'uso di 1 file war di pacchetti per le distribuzioni è una buona pratica.
usiamo la formica per sostituire i valori che sono diversi tra gli ambienti. Controlliamo il file con una variabile @@@ che verrà sostituita dal nostro script ant. Lo script ant sostituisce l'elemento corretto nel file e quindi aggiorna il file di guerra prima della distribuzione a ciascuno

<replace file="${BUILDS.ROOT}/DefaultWebApp/WEB-INF/classes/log4j.xml" token="@@@" value="${LOG4J.WEBSPHERE.LOGS}"/>


<!-- update the war file We don't want the source files in the war file.-->
<war basedir="${BUILDS.ROOT}/DefaultWebApp" destfile="${BUILDS.ROOT}/myThomson.war" excludes="WEB-INF/src/**" update="true"/>

Per riassumere fa tutto e usiamo il formicaio per gestire la formica. form crea il file di guerra, sostituisce i percorsi dei file, aggiorna il file di guerra, quindi distribuisce nell'ambiente di destinazione. Un processo, in effetti un clic di un pulsante nel formicaio.