Ambiente di sviluppo diverso dall'ambiente di test

Ecco alcune idee:

Se è possibile ottenere hardware o macchine aggiuntive, ecco un paio di idee:

1. Ottieni un server di sviluppo che è un mirror del server di prova. Ciò fornirà un modo per testare la funzionalità su un server piuttosto che sui computer degli sviluppatori per garantire che le funzionalità che potrebbero richiedere la configurazione vengano rilevate correttamente. L'uso dell'integrazione continua qui può anche essere uno strumento utile per verificare le correzioni dei bug e prevenire la regressione se gli sviluppatori continuano a effettuare test appropriati.

2. Garantire che gli sviluppatori dispongano di una macchina separata, possibilmente virtualmente, in modo che i test possano essere eseguiti su una rete anziché eseguire tutto localmente. È qui che può essere utile disporre di PC meno recenti che potrebbero essere simili ai computer client che possono essere utilizzati per eseguire test su vari browser su una macchina separata dal server previsto. Questo potrebbe non essere sempre in grado, ma è qualcosa da suggerire.

In caso contrario, ecco alcune altre idee da considerare:

1. Mentre sviluppi su macchine personali, stai usando IIS o il server web integrato di Visual Studio per eseguire il tuo codice? Qui ci possono essere delle differenze che vale la pena notare ed è qualcosa da considerare nell'andare da un ambiente all'altro. È qui che può essere importante disporre di standard per gli sviluppatori e assicurarsi che tutti comprendano il motivo per cui le cose stanno così.

2. Aggiungi ulteriori informazioni di debug che possono essere utili in ambienti di sviluppo e testing disattivati in produzione poiché potrebbero danneggiare le prestazioni. Questo potrebbe essere il punto in cui è possibile registrare eccezioni con informazioni aggiuntive o aggiungere messaggi informativi sullo stato del server poiché è possibile che Riciclaggio di App_pool o altre impostazioni di IIS possano essere l'innesco di bug che non sarebbero facilmente rilevati dagli sviluppatori che si riavviano spesso il proprio App_pool per riflettere le modifiche al codice. In un certo senso, si desidera disporre di alcuni contatori delle prestazioni nel codice che registrano i valori a intervalli regolari che possono aiutare a diagnosticare i problemi in quanto possono verificarsi problemi di carico pesante che potrebbero danneggiare un'app diversa da quella che gli sviluppatori potrebbero inizialmente testare all'interno del loro codice .

3. registra le differenze negli ambienti. Più server? I firewall? Bilancio del carico? Versioni di software? Garantire che le patch siano aggiornate su tutti i server? Anche se questo è un compito semplice a un livello, mantenere un documento che mostri le differenze potrebbe essere piuttosto utile come se si sviluppasse su IIS 7.5 e si distribuisse su IIS 5.0, quindi potrebbero esserci alcune differenze che potrebbero essere un problema.

4. Considera quali tipi di test hai sui tuoi ambienti. Ci sono test di carico? Ci sono test di penetrazione? Questo può essere qualcosa da esplorare, ma a seconda dei problemi riscontrati potrebbe essere o non essere facile giustificare i costi per alcuni degli strumenti di fascia più alta.