2009-11-26 16 views
6

Abbiamo il seguente problema. Gli sviluppatori devono spesso apportare piccole modifiche alle nostre applicazioni web. Quando dico piccolo, intendo cose come correggere l'ortografia in una pagina web o simili. Generare e ridistribuire archivi di guerra può essere lento e costoso in tali scenari.Implementazione incrementale di applicazioni web java

In che modo è possibile automatizzare e installare le modifiche in modo incrementale? Ad esempio, genera una nuova guerra esplosa, confronta i file con la guerra esplosa in produzione e poi sostituisce nella produzione solo i file interessati dalle modifiche: .jsp .html .class ecc.

Non è necessario essere una distribuzione a caldo, è necessario riavviare il server. Quello che desidero evitare è dover copiare e distribuire guerre che possono avere una dimensione di 80Mb. Talvolta le connessioni sono lente e rendono minuscole le modifiche all'applicazione Web, poiché la semplice correzione ortografica può richiedere ore.

Utilizziamo Maven per automatizzare il nostro processo di compilazione. Il problema chiave è automatizzare l'intero processo, così posso essere sicuro che l'app v2.2.3 nella mia Subversion è esattamente ciò che ho in produzione dopo la distribuzione incrementale.

+0

Davvero? Due ore per gli schieramenti di guerra da 80 MB? – Jherico

+0

Utilizziamo websphere e talvolta è necessario distribuire EAR/WAR non solo per la produzione, ma anche per le macchine di staging/testing ecc., Spesso virtualizzate e con caratteristiche non così grandi. Inoltre, a volte gli archivi devono essere inviati via cavo in altri paesi/continenti e questo può richiedere tempo. – Dan

risposta

1

Abbiamo sempre fatto questo genere di cose tutto il tempo. Abbiamo lavorato in una banca e talvolta sono state apportate modifiche alle frasi legali o ai termini e alle condizioni che dovevano essere modificati oggi (o, più spesso, ieri).

Abbiamo fatto due cose per aiutarci a implementare rapidamente. Abbiamo avuto un buon controllo delle modifiche e un processo di costruzione. Potremmo cambiare e distribuire qualsiasi versione che ci piacesse. Avevamo anche una suite di test buona , con la quale potevamo testare facilmente le modifiche.

Il secondo era più controverso. Tutti i nostri html sono stati distribuiti come file separati sul server. Non c'era nessuna GUERRA. Pertanto, quando sono emerse le circostanze che abbiamo dovuto modificare qualcosa di testuale rapidamente, potremmo farlo. Se java aveva bisogno di essere cambiato, abbiamo sempre fatto una build FULL e l'implementazione.

Questo non è qualcosa che consiglierei, ma è stato positivo per la nostra situazione.

Il punto di una GUERRA è che tutto viene distribuito allo stesso tempo. Se stai usando un WAR, significa che vuoi che venga distribuito tutto in una volta.

Un suggerimento non è quello di fare tali correzioni così spesso (una volta alla settimana?). Allora non hai così tanto dolore.

+0

@MatthieuF: "Tutti i nostri html sono stati distribuiti come file separati sul server. Non c'era WAR." Pensi di poter essere un po 'più specifico? Che cosa vuoi dire che non c'era nessuna GUERRA? Stiamo ancora parlando di applicazioni web Java standard in esecuzione su Tomcat ecc.? – Dan

+0

Era un'applicazione standard (in effetti di Weblogic), ma invece di distribuire un singolo file WAR, abbiamo decompresso tutti i file e li abbiamo inseriti nelle directory corrette da soli (abbiamo mantenuto i JAR come JAR ovviamente). Il server non era in esecuzione al momento della distribuzione, quindi non ci sarebbero incoerenze. –

0

È possibile eseguire la master guerra da qualche parte in cui i server in esecuzione possono accedervi e invece di distribuire file di guerra sui singoli server è possibile utilizzare rsync e perl per determinare se sono presenti modifiche a qualsiasi file nella guerra principale, distribuire loro ai server ed eseguono riavvii.

1

Difficile dire. Ovviamente puoi sostituire i file di una sola classe in una webapp esplosa, ma questa è generalmente una cattiva idea e non vedi molte persone farlo.

Il motivo è che quando si apportano piccole modifiche diventa sempre più difficile rilevare le differenze tra produzione e sviluppo. Le probabilità di invio di un file di classe errato e di interruzione del server di produzione aumentano nel tempo.

Quando si dice che il testo cambia, non è un'idea tenere le risorse di testo separate dal file di guerra? In questo modo, non solo gli sviluppatori ma forse anche il cliente possono facilmente aggiungere/modificare le traduzioni.

Per il cliente è importante, ma tecnicamente è sciocco fare un 80MB di implementazione su una linea lenta per correggere un errore di battitura.

Si può anche provare a guardare il ciclo di costruzione/consegna e aumentare gli sforzi di test per evitare queste piccole modifiche.

Spero che questo aiuti.

+0

@Rolf: "La ragione è che quando si apportano piccole modifiche diventa sempre più difficile rilevare le differenze tra produzione e sviluppo, con la possibilità che l'invio di un file di classe errato e l'interruzione del server di produzione aumentino nel tempo." Penserei che ci siano strumenti in grado di confrontare due file con grande certezza, anche quelli testuali? – Dan

+0

Sì, ci sono strumenti per farlo e alcuni sono descritti in alcune risposte. Dalla mia esperienza, inviare file di classe per aggiornare una guerra di produzione è SEMPRE una cattiva idea. Non avere il problema è sempre meglio che avere strumenti per gestire il problema. – Rolf

0

Al momento ho installato SVN sul server remoto quindi in caso di un semplice udate si può semplicemente aggiornare il file singolo. Il trasferimento del grande file WAR non sarebbe pratico.

È possibile eseguire l'automazione per una distribuzione con un solo clic utilizzando stucco/plink [se si utilizza Windows] creando un semplice script sulla macchina locale e un altro nella macchina remota.

Al momento ho SVN SVELOPMENT e SVN LIVE. La build ANT sta unendo DEV al LIVE e il commit torna nuovamente al repository LIVE. A quel punto il server remoto può eseguire un SVN UP e otterrà automaticamente il file richiesto.

È possibile migliorare lo script di aggiornamento per riavviare il server nel caso in cui alcune classi vengano modificate e non si riavvino in caso di aggiornamento di script/JSP.

In questo modo avrete anche la possibilità di eseguire il rollback a una versione precedente per essere sicuri di avere un'app Web funzionante tutte le volte.

Per migliorare il processo di unione di SVN questo strumento è molto utile. : http://www.orcaware.com/svn/wiki/Svnmerge.py

0

La solita risposta è utilizzare un sistema di Continuous Integration che controlla la subversion e crea gli artefatti e li distribuisce: vuoi solo che la tua applicazione web sia pronta a funzionare anche dopo essere stata ridistribuita. La domanda è se è abbastanza veloce per te?

0

Non penso che ci sia una risposta semplice a questo. T

La chiave qui è la modularizzazione - un problema che non penso sia risolto molto bene con le applicazioni Java attualmente. Potresti voler vedere OSGi o moduli dinamici non sono sicuro di quanto siano efficaci in termini di questo problema.

Ho visto soluzioni in cui le persone rilasciano le classi nel contenitore server/servlet delle applicazioni, non sono d'accordo, ma sembra funzionare ... Sono sicuro che ci siano comunque storie dell'orrore!

Maven facilita le cose da applicazioni suddivisione in moduli, ma se fate questo e distribuire i moduli in modo indipendente è necessario fare in modo che le varie versioni bel gioco insieme in un ambiente di test per cominciare ...

Un'alternativa è quella di partizionare l'applicazione in termini di funzionalità e ospitare funzioni separate su vari server, ad es.g:

  • Conti clienti - Server Un
  • Ricerca - Server B
  • Booking Online - Server C
  • pagamento Servizi - Server D

Il partizionamento rende più semplice per distribuire le applicazioni , ma di nuovo devi assicurarti che i tuoi moduli suonino bene insieme prima. Spero possa aiutare.

0

Ho avuto una situazione simile prima. È davvero un problema di separazione delle preoccupazioni, e non è troppo semplice. Quello che devi fare è separare il testo dalla pagina modello/HTML.

Abbiamo risolto questo problema inserendo il nostro testo in una tabella di database e utilizzando la tabella come risorsa di messaggio, nello stesso modo in cui le persone utilizzano myMessages.properties per l'internazionalizzazione (i8n). Questo ti dà due vantaggi, puoi scrivere il testo e apportare modifiche ai prodotti istantaneamente e facilmente senza una distribuzione del codice. Abbiamo anche memorizzato nella cache la tabella per garantire che le prestazioni non abbiano sofferto molto.

Non è una soluzione per tutti, ma ha funzionato davvero bene per noi.

Problemi correlati