Come testare le funzionalità dipendenti dall'ambiente?

Usa un flag di debug. Se il flag è attivo, mostra le tracce dello stack con i messaggi di errore. Se è OFF, mostra solo i messaggi di errore piuttosto carini.

Praticamente tutte le strutture web comuni funzionano già in questo modo ...

Questa non è probabilmente la risposta che vuoi sentire, ma per garantire che un prodotto funzioni in ogni ambiente, devi disporre di tutti i possibili ambienti disponibili per i test. Non farti prendere dal tentare di creare un prodotto sviluppato in un ambiente per un ambiente radicalmente diverso.

Chiaramente non puoi sperare di avere l'ambiente di produzione esatto, sebbene tutto il resto sia un compromesso e una decisione calcolata riguardo al fatto che una determinata differenza produrrà dei bug se non adeguatamente testata. È necessario modificare l'indirizzo per il database dall'ambiente di test all'ambiente di produzione? Questo è un cambiamento accettabile. È necessario utilizzare l'utente di test nell'ambiente di test? Anche questo è un cambiamento accettabile. Test di un prodotto realizzato in ambiente Linux solo per la distribuzione in un ambiente Windows con Cygwin installato. NON accettabile! Dovresti testare il tuo prodotto sia su Linux che su una macchina Windows con Cygwin installato per assicurarti che non ci saranno problemi.

Nel tuo caso, dovresti avere due ambienti per entrambi i casi, e per tutte le funzionalità che hanno in comune, un terzo ambiente idealmente in modo che tu possa verificare che i cambiamenti in entrambi funzionino insieme. Anche se questo potrebbe non essere possibile, ma il mio consiglio per te è chiedersi se è il tuo collo sulla linea. Se lo è, non correre rischi. Insistere affinché ogni ambiente in cui il cliente possa utilizzare il proprio prodotto sia presente internamente per i test.

Perché non c'è nessun altro posto buono da testare della stadiazione?

Per me sembra un modo di pensare all'indietro; ovviamente le cose devono prima essere testate nell'ambiente di sviluppo e da qui devono provenire le modifiche. Forse il tuo problema è che l'ambiente di sviluppo non è all'altezza?

Prima di tutto non spingere il codice fuori dal tuo ambiente locale per far testare qualcun altro fino a quando non viene eseguito, verifica la tua soluzione fino a quando non sei sicuro che stai offrendo qualcosa di privo di bug. Troppo spesso ho visto le modifiche semplicemente trasferite in modo casuale negli ambienti di staging, e anche i file più orribili modificati direttamente sui server, a scopo di test e di rottura di build in generale, che è sia folle che aggravante per tutti i soggetti coinvolti.

Se parli di test del QA, cosa impedisce di utilizzare un ambiente locale? Le persone addette al controllo qualità possono creare una scatola Vagrant per gestire l'ambiente? Altrimenti, hai qualche soluzione di provisioning automatizzata per creare un ambiente separato per il lancio?

In realtà non è un momento di catch-22, ma potresti non avere una soluzione tecnica che permetta di testarla facilmente in questo momento. Ti prometto che è possibile risolvere il problema. Dare consigli più o migliori è tuttavia incredibilmente difficile senza una migliore comprensione di ciò che il problema è in realtà.

UPDATE: non puoi semplicemente aggiungere o utilizzare un flag di debug già presente nell'applicazione? Questa è, a dir poco, una soluzione molto comune al problema.

Alcuni team possiedono un ambiente QA separato. Pertanto, gli ingegneri del controllo qualità sono in grado di testare il tuo prodotto dal punto di vista del cliente. E la messa in scena viene utilizzata a scopo di sviluppo dai tecnici del software.

Questa soluzione costa di più in termini di hosting / infrastruttura ma risparmia molto tempo sia per gli sviluppatori che per il team di controllo qualità.