Gli ambienti di sviluppo / test / QA / Staging dovrebbero essere simili?

My question is, should we develop on the same application server we're deploying to?

Non esattamente lo stesso server. Non è possibile testare aggiornamenti e nuove versioni se si fa la regola sciocca che tutti i server siano identici. [Alcune persone cercano di passare la regola. Non può funzionare perché impedisce gli aggiornamenti o crea un caso speciale che non è poi così speciale e succede così spesso che la regola viene rapidamente considerata stupida.

Tuttavia, la situazione di più server, non solo di più versioni, è pericolosa.

Dovresti avere lo stesso stack tecnologico. Puoi avere diverse versioni. Ma non prodotti diversi.

Tuttavia, gli sviluppatori avranno spesso versioni più nuove di quelle in produzione. Ecco come i cambiamenti marciano lungo la pipeline fino alla produzione (e alla fine) dello staging.

La parte difficile è ottenere un consenso su qual è la cosa giusta. Se alcune persone si rifiutano semplicemente di collaborare, è tempo che i loro manager trovino nuove cose da fare per loro.

È necessario un server di integrazione simile al server di produzione.

IMHO è importante che gli sviluppatori sviluppino ciò che vogliono (ad esempio, sviluppo localhost con Tomcat perché è veloce, buona fortuna con 10 distribuzioni al giorno con WAS ...). Ma dopo lo sviluppo è finita, allestire un server di integrazione e testare la tua app lì. Questo dovrebbe essere il più simile possibile al server di produzione.

Se puoi permetterti di avere più di un ambiente (ad es. abbiamo provato una volta su 4 tipi di server).

Penso che quello che vuoi sia abbastanza sensato. Se la tua applicazione funziona solo su un tipo di server, allora ha senso imitare la configurazione di quel server in modo che tu sappia subito durante lo sviluppo se qualcosa funzionerà o meno. Non ha senso far accumulare bug dovuti a ambienti diversi.

Un'altra alternativa è utilizzare uno strumento di integrazione continua, in modo che gli sviluppatori sappiano subito se funzionerà sul server di distribuzione, ma possono utilizzare qualsiasi ambiente sia più produttivo per loro.

Per quanto riguarda Websphere, se i problemi di licenza impediscono agli sviluppatori di utilizzarlo anche per lo sviluppo, l'alternativa migliore (rispetto a JBoss ecc.) è forse Websphere Community Edition . Anche se ha un codice diverso rispetto al normale WAS, IBM sta cercando di renderlo il più compatibile possibile per convincere gli sviluppatori a usarlo al posto di altri server delle applicazioni.

Penso che tutti quegli ambienti dovrebbero essere il più vicino possibile. Sono stato un po 'da bug che sono accaduti su Tomcat (testing) ma non su Jetty (dev). Mentre li abbiamo catturati prima di andare in diretta, sarebbe stato molto più facile catturarli prima durante lo sviluppo.

Ancora peggio, alcuni bug si sono verificati solo sul computer dello sviluppatore, ma non sui test (che è più vicino alla produzione), facendoci perdere tempo in problemi irrilevanti.

Più vicini alla produzione più i server dovrebbero essere identici. Lo scopo è quello di assicurarsi che l'installazione finale sia priva di problemi imprevisti, vale a dire la sindrome "lavora per me". Tuttavia, più ci avviciniamo allo sviluppo, abbiamo bisogno di più libertà di sperimentare. Quindi direi che l'intero set di piattaforme non ha bisogno di essere identico, e in realtà non può essere.

Una delle cose che stai facendo bene è usare uno script di build automatico. Sia che si tratti di ANT o di Maven non è importante quanto il fatto che l'applicazione sia compilata e che i JAR siano assemblati allo stesso modo ogni volta. Ciò consentirà di evitare una serie di problemi.

Il punto dolente che hai menzionato - i bug dovuti alle differenze nei server delle applicazioni - è un'arma a doppio taglio. Maggiore è il numero di server delle applicazioni a cui è esposta la tua app, più sarà portatile quando avrai risolto i problemi. D'altra parte, a meno che non si stia costruendo un'applicazione che i tuoi clienti saranno liberi di installare sui propri server di app, il lavoro extra necessario per la portabilità si limiterà a perdere tempo a sistemare altri bug, probabilmente più importanti.

È un triste fatto della vita che a volte la nostra scelta di application server sia limitata dalle politiche IT dei nostri clienti. "Userai IBM o Oracle, sì e in verità" Se questo è il caso, almeno tutto dal server di prova dovrebbe utilizzare lo stesso server di applicazioni della produzione. Nel campo dello sviluppo, potresti voler standardizzare solo uno dei server delle applicazioni alternativi. Se ti stai trasferendo a Maven (come sembra che tu sia), allora Jetty è una partita naturale. Maven ha una preferenza per Jetty, quindi eseguire l'applicazione nel server dell'app è semplice come digitare mvn jetty:run ( leggi questo articolo ).

Essenzialmente, vorrai minimizzare il numero di cose che possono andare storte. Se riesci a cogliere la maggior parte dei problemi di incompatibilità nella fase di test, sei molto avanti rispetto al gioco. La messa in scena dovrebbe essere un passaggio obbligato con la produzione, in quanto sarà la tua ultima possibilità di trovare problemi di installazione che potrebbero morderti durante la produzione. Gli stessi processi di hardening da utilizzare nella produzione dovrebbero essere utilizzati anche nella gestione temporanea. I test dovrebbero utilizzare lo stesso stack tecnologico che verrà utilizzato su staging e produzione, ma non devono essere tenuti in una fase di blocco. Sarà la tua prima opportunità di trovare problemi a causa dell'aggiornamento del server o delle librerie che stai utilizzando.