Gli argomenti per l'ambiente di sviluppo sono gli stessi della produzione

È uno dei principi fondanti della consegna continua che i test di integrazione e i test manuali devono essere eseguiti in una "produzione" -come "ambiente" per avere la certezza di un rilascio stabile. Maggiore è la produzione, ad esempio gli ambienti di test e di gestione temporanea, maggiore è la sicurezza che si può avere, fino al punto di rilascio di fire-and-forget di punta del giorno.

Detto questo, il tuo ambiente di sviluppo non deve essere uguale a quello di produzione, e sicuramente non dovrebbe avere dati di produzione - perdite di privacy, aggiornamenti ad hoc , tutti i tipi di problemi lì. L'integrazione avviene dopo il tuo codice lascia l'ambiente di sviluppo (nello specifico, nel tuo ambiente CI, supponendo che tu ne abbia uno), e la maggior parte dei team non esegue test di integrazione localmente, quindi il mirroring della produzione in dev non sarà Ciò è utile dal momento che il codice e le unit test in genere eliminano qualsiasi dipendenza ambientale (presumendo che li abbia progettati correttamente).

Tuttavia, è utile utilizzare gli stessi script di distribuzione per local / dev e test / staging / prod, poiché aggiunge un altro livello di testing alla distribuzione stessa e consente di perfezionare il processo. Ma non ha bisogno di essere lo stesso. Ad esempio, non è economicamente conveniente acquistare una licenza Oracle per ogni singola unità di sviluppo, quindi non contare su una coerenza perfetta.

Non mi aspetto che questa risposta sarà molto pubblicizzata o molto popolare perché so che le persone amano sviluppare sulla loro piattaforma di scelta , ma qui va ...

Una volta ho visto uno sviluppatore trascorrere 12 ore nel tentativo di replicare una singola installazione di dipendenze sul suo Macbook Pro. Se stai facendo lo sviluppo aziendale avrai molte dipendenze. Spesso con dipendenze inter-os una persona diversa dall'autore originale ri-impacchetta il contenuto e lo rilascia con una base di codice leggermente modificata.

Sarei molto diffidente nei confronti degli sviluppatori che cercano di sviluppare a lungo termine in un ambiente che non è produzione. Non solo il tempo impiegato per gestire il proprio ambiente potrebbe essere ampiamente sprecato quando esistono già processi automatizzati per configurare l'ambiente di produzione che sta rischiando di aggiungere funzionalità e aggiungere dipendenze inconsapevolmente che potrebbero non funzionare del tutto.

Nella mia organizzazione arriviamo al punto di avere test di unità di massa da sapere ogni volta che un pacchetto python cambia versione. A volte capita involontariamente e quando lo vogliamo vogliamo sapere. Un buon esempio di questo è PyMssql e questo bug - > link

Infine, non posso capire che affermano di essere "agili" team di sviluppo che richiedono a tutti di impegnare continuamente il proprio codice. "Se non è in Controllo versione, non esiste!" - e poi si girano e hanno un atteggiamento completamente rilassato riguardo agli ambienti, ai moduli, alla versione, in fase di sviluppo. Che dire di "se non è sviluppato all'interno degli ambienti di produzione non esiste" ??

Più precisamente l'ambiente di test unitario dovrebbe essere il più simile possibile alla produzione.

In molti casi l'ambiente di sviluppo potrebbe non essere sulla stessa piattaforma in cui verrà eseguita l'applicazione. (Pensa ad Android dove lo sviluppo è fatto su PC / eclipse ma il codice gira sul tuo telefono).

Il motivo principale per non farlo nella vita reale si riduce al costo delle licenze hardware o software. È difficile giustificare un cluster multi-sito e ad alta disponibilità di macchine multiprocessore solo per lo sviluppo.