Quali sono le moderne tecniche di sviluppo-implementazione-test per le lingue non interpretate?

3

Ho una solida esperienza di sviluppo web, dove per mostrare al cliente una demo ho caricato una soluzione in ambiente demo e inviata tramite un link. Se il client del caso ha chiesto di apportare modifiche, li ho fatti in PhpStorm, dev-testato su env locale, distribuito in un clic dall'IDE e chiesto loro di ricaricare la pagina. In era così semplice e molto efficiente.

Ora sto lavorando in Java e mi manca profondamente l'efficienza che avevo con PHP. La distribuzione dimostrativa rimane semplice, ma i cambiamenti sono un disastro totale. Devo:

  1. Ricrea il pacchetto con Maven;
  2. Carica 100Mb in Nexus;
  3. Esegui una distribuzione tramite uno strumento specializzato, che scarica 100 MB, cancella la vecchia distribuzione e distribuisce nuovamente tutto.

La maggior parte dei JAR all'interno del bundle - librerie di terze parti - non cambiano mai. Ridistribuirli sembra inefficiente.

Potrei usare JRebel o strumenti di questo tipo, ma non sono nella posizione di fare in modo che l'organizzazione acquisti software proprietario.

Credo che là fuori ci siano squadre che non possono contare anche su software a pagamento. Come eseguire il ciclo di sviluppo del processo di sviluppo più veloce implementando un'architettura intelligente e utilizzando strumenti gratuiti?

Aggiornamento: scusami se la domanda ha un sapore un po 'raro. Quello che mi piacerebbe sapere è Come si dev-deploy-test ovunque si lavori? Solo gli eco-sistemi di programmazione Java non interpretati rientrano nella portata della domanda.

    
posta user1065145 03.03.2016 - 09:02
fonte

1 risposta

3

Puoi fare le patch da solo se sai cosa stai facendo. Ma se lo script, avrai definitivamente un problema: in ogni release dovrai elencare ogni singolo file modificato.

L'obiettivo di Maven è di fornire una consegna pacchettizzata completa, quindi, naturalmente, per impostazione predefinita si avrà una guerra di 100 mb. Questo è il comportamento predefinito perché è il più semplice e il più sicuro. Ma se non vuoi avere sempre una consegna di 100 MB puoi fare quanto segue:

  1. Ottieni tutti i barattoli nella tua guerra attuale che non provengono dal tuo codice
  2. Inseriscili nella cartella della libreria del tuo server web
  3. Imposta tutte le tue dipendenze nell'ambito "fornito".

Questa è una strada da percorrere, ma se si aggiorna uno di questi componenti e si dimentica di aggiornarlo sul server, è possibile che si sia verificato un errore e probabilmente si verificheranno dei problemi nel rintracciarlo dall'aggiornamento della libreria.

Ma personalmente considero che finché non devi caricare 100 MB da solo su ogni compilation per il tuo ambiente di sviluppo, questo non vale la pena, non devi consegnare cose che spesso così puoi solo aspettare un minuto o due. Aggiungerò questo è il motivo per cui utilizzo Tomcat e non il server delle applicazioni, non ho conflitti di libreria già incorporata nel server. JBoss mi ha dato un sacco di problemi quando volevo usare una versione più recente di Jackson su di esso.

    
risposta data 03.03.2016 - 14:01
fonte