Creazione di un sistema di patch automatico per Spring Hibernate Application

3

Ho questa domanda da qualche mese.

Abbiamo un'applicazione web che ha cambiamenti mensili e correzioni di bug settimanali, se presenti.

Solitamente, costruiamo solo la nuova guerra, annulliamo la distribuzione di quelli vecchi e ne ridistribuiamo di nuovi, e riavviamo il server se necessario.

Voglio costruire un sistema di patching in grado di creare una patch che possa essere facilmente applicata per la guerra in corso.

Ho cercato su Google molto ma non ne ho trovato.

I miei dubbi sono:

  1. Va bene creare un'applicazione del genere? (In particolare per questa applicazione WAR)
  2. Quale lingua usare? (Stavo pensando a Go o JAVA ma aperto ai suggerimenti.

Indicami eventuali documenti dei blog. Grazie in anticipo:)

    
posta Aditya Peshave 08.04.2015 - 02:02
fonte

2 risposte

2

Sì, è del tutto possibile, e l'ho fatto anch'io.

La situazione in cui mi trovavo era la distribuzione di un grande file .war. La parte dell'applicazione Web non era così grande - ma anche conteneva al suo interno un'applicazione Java Web Start. La dimensione combinata di tutto questo era di poche centinaia di megabyte. Questo ha rappresentato un problema per l'implementazione: quando si spingeva tutto il tubo verso tutti i siti che lo richiedevano (circa 300), si poteva saturare completamente la rete tutta la notte, il che significava che non stavano accadendo altri aggiornamenti (era una cosa brutta) .

La soluzione a questo era in due parti. Innanzitutto, abbiamo eseguito una distribuzione esplosa di tutto il codice che abbiamo usato (i file .jar di terze parti erano ancora .jar). In secondo luogo, come parte del nostro server CI, avevamo uno script di compilazione speciale che poteva richiedere a due build di identificare il delta dei file di classe e altre risorse (delta del file intero, patch di file secondari) e quindi con esso creare il pacchetto di distribuzione (un file .tar e uno script di shell che interrompevano il server, si distribuivano e riavviavano il server - il JWS eseguiva la propria distribuzione al momento dell'avvio dei client) che collegava un ambiente di produzione da una build all'altra.

Una cosa da togliere a tutto questo è che ci sono stati diversi vincoli qui - una molto grande applicazione e utilizzo della rete. Ciò ha reso necessaria una distribuzione incrementale.

Per una situazione in cui hai alcuni server, guarderei un altro approccio.

Innanzitutto, esegui la versione del file .war. Non distribuisci "FooApp", distribuisci "FooApp_1_0_1". Ciò significa anche che hai entrambi "FooApp_1_0_0" e "FooApp_1_0_1" sul server allo stesso tempo.

In secondo luogo, il proxy forward o il bilanciamento del carico hanno il suo punto di configurazione "FooApp" su "FooApp_1_0_0" e quindi cambiano la configurazione quando si desidera capovolgere l'interruttore. Questo in genere viene eseguito dopo aver verificato che la nuova distribuzione funzioni completamente.

La distribuzione può essere effettuata tramite il tuo server CI (e se non ne hai uno funzionante, sarebbe una buona cosa su cui lavorare). Jenkins ha plug-in di distribuzione per tutti i principali server EE. Maven ha anche plugin di distribuzione - sono sicuro che anche gradle e formiche fanno lo stesso. Puoi anche scrivere il tuo utilizzando JMX per alcuni server delle app. Se desideri davvero , potresti probabilmente scrivere un'altra app che viene eseguita sul server dell'app per distribuire l'altra app. Sarei riluttante ad avere un aggiornamento stesso nel codice in esecuzione. Sembra solo un incubo se qualcosa si rompe in parte.

I maggiori vantaggi con la distribuzione con versione e un commutatore di bilanciamento del carico / inoltro proxy è che è possibile eseguire questa distribuzione con zero down e verificare la distribuzione prima che sia avviata. Come parte di questo, stai aggiornando il codice in esecuzione o addirittura riavviando il server delle applicazioni. Il passaggio per quale codice da eseguire è completamente un altro sistema. Questa situazione consente anche rollback istantanei e commutazione client speciale ("sei stato selezionato per provare il nostro nuovo look and feel, fai clic qui per accedere alla nuova versione dell'applicazione e fornire feedback").

    
risposta data 08.04.2015 - 15:24
fonte
2

Sì. È possibile applicare una patch a un file JAR usando jar -u. È anche possibile applicare patch a un file WAR allo stesso modo.

Ma NON lo consiglierei. Il file JAR o WAR dovrebbe essere l'unità di implementazione / gestione. Se si avvia la patch dei file JAR / WAR sui server di produzione, è difficile tenere traccia di ciò che viene effettivamente utilizzato dove. Se non stai attento, regnerà il caos e la confusione.

L'unica situazione in cui l'applicazione delle patch è inevitabile è quella in cui si dispone di una libreria di terze parti o qualcosa che non è possibile creare dall'origine, ma è comunque necessario modificarla. Ma anche in questo caso è meglio modificare il JAR / WAR sulla piattaforma di build e distribuire il JAR / WAR modificato. Cercare di applicare patch JAR, WAR o applicazioni web distribuite sulla piattaforma di produzione è una cattiva idea.

    
risposta data 08.04.2015 - 13:17
fonte

Leggi altre domande sui tag