Avere un server per l'intera squadra [chiuso]

Domanda molto valida e il mio team si trovava in una situazione simile: è per questo che attenersi alle specifiche principali dell'API in uso è molto più importante per evitare i lock-in dei fornitori. La mia risposta è supponendo che tu sia su uno stack Java ma puoi giustapporre per altri stack di lingue. Quindi sì, ottieni le impostazioni locali per il tuo team ma potresti non essere in grado di ottenere WebSphere così improvvisare - ecco alcuni suggerimenti ...

Per gli ambienti locali ti suggerisco di distribuire l'applicazione in Apache Tomcat preferibilmente se non hai requisiti per i server delle applicazioni. Se i requisiti del server delle applicazioni sono considerati Apache TomEE .

Altre opzioni in cui è possibile ridurre la dipendenza dall'applicazione (e dal server Web) è scrivendo e deviando gli sforzi verso il test delle unità ( JUnit o TestNg ) - questo riduce i tempi di sviluppo e distribuzione a lungo termine e riduce anche la concorrenza per risorse come il server WebSphere hai parlato.

Ora la parte critica - se in prod si sta distribuendo su WebSphere per qualsiasi motivo - si deve testare su WebSphere - anche se non di rado. Ciò è necessario in quanto vi sono casi in cui alcune librerie in WebSphere potrebbero entrare in conflitto con le librerie dell'applicazione e potrebbe essere necessario regolare il criterio ClassLoader! Questo è qualcosa che puoi scoprire solo quando l'applicazione è distribuita su WebSphere e non le 2 alternative che ho proposto sopra. Un'altra area notoriamente con WebSphere è JDBC se la si utilizza con tipi JDBC3 come CLOB, BLOB, ecc. Non segue gli standard e potrebbe essere necessario scrivere alcune regole condizionali per tali problemi, in modo da identificare l'ambiente in cui è Dev o Test dell'ambiente ed eseguire la logica condizionale. Se utilizzi framework di container sottostanti come Spring unit Testing, Funzionando con un contenitore web semplice come Tomcat, e persino eseguendo logic / config specifico per ambiente condizionale (chiamato anche profiles ) è molto più semplice.

Ovviamente non si tratta di cambiamenti durante la notte - ma dal momento che stai perdendo tempo comunque sul sistema condiviso, potresti anche considerare di investire in alcuni di questi suggerimenti. Quindi, come commento conclusivo, concentrati su come ridurre la dipendenza del tuo team da un prodotto server proprietario proprietario, anche se devi implementarlo per prod: è esattamente il motivo per cui abbiamo specifiche standardizzate.

Non so se è una buona pratica, ma mi piace avere un ambiente di sviluppo il più completo possibile. Compreso application server, database e applicazioni esterne che vengono invocate durante l'esecuzione, se possibile.

Questo mi consente di svilupparmi indipendentemente dagli altri. Posso ridistribuire e riavviare i server quando ne ho bisogno. Posso riempire il mio database con i miei dati di test e ripristinarlo quando ne ho bisogno. Posso installare diverse versioni di componenti. E quando ho bisogno di eseguire il debug, posso avviare un server in modalità di debug o modificare la configurazione di registrazione.

Inoltre, rende più semplice provare nuove cose, come cambiare le impostazioni di configurazione del server o sviluppare script di automazione.

Utilizzando software di virtualizzazione come Virtualbox, insieme a strumenti come Vagrant o Docker, la manutenzione e la condivisione delle istanze del server preconfigurate diventa abbastanza facile.

Come prima cosa potresti provare ad eseguire un'istanza di Websphere sul tuo computer di sviluppo. Ho lavorato in questo modo, collegandomi a un database condiviso. Forse il server non è molto veloce, ma potrebbe essere abbastanza buono.