Why should we have separate development, testing, and production environments?

Hai diverse attività in corso contemporaneamente:

• sviluppo - in cui gli sviluppatori commettono codice, commettono errori, sperimentano, ecc.
• testing - dove i test vengono eseguiti, manualmente o automaticamente, e a causa della complessità, possono consumare molte risorse.
• produzione - dove viene creato un valore per i clienti e / o l'azienda

Vuoi che tutto questo avvenga nello stesso ambiente? Vuoi che il business si fermi perché un nuovo test ha spinto i tuoi server a scambiarsi su hard-drive e consuma ogni core del processore? Vuoi che i tuoi test si fermino perché uno sviluppatore ha fatto un bombardamento a forcella contorto di un esperimento di ridimensionamento? Volete il codice che pensavate funzionasse a causa dello spago e del nastro adesivo di uno sviluppatore nei test da eseguire in produzione? Vuoi sviluppatori che lavorano con dati di produzione potenzialmente sensibili (so che questa non è una preoccupazione in tutte le aziende, ma è in molti di essi)?

Che cosa impedisce che si verifichino questi problemi?

Ambienti separati.

Quindi di cosa hai bisogno?

Hai bisogno di ambienti separati.

Per metterlo formalmente

Sono necessari ambienti separati per i seguenti motivi:

• per ridurre i rischi di blocco dello sviluppo aziendale e software.
• per ridurre i rischi legati alla messa in produzione del codice che ha superato i test a causa del rigging ad hoc degli sviluppatori.
• per ridurre i rischi che i dati di produzione finiscano nelle mani sbagliate (molto importante quando le organizzazioni gestiscono dati sensibili, come numeri identificativi e informazioni finanziarie e sanitarie) o si confondono con i dati dei test o vengono distrutti.

Per il tuo contesto, una nuova piattaforma tecnologica

Forse non si tratta ancora di una vera produzione (dal momento che è una piattaforma relativamente nuova), ma otterrete i vostri ambienti separati quando l'azienda inizierà a fare affidamento su di essa e saranno abbastanza saggi da prevedere il rischio o realizzarlo imparando nel modo più duro.

I've heard that best practice is to have separate development, testing and production environments but why is this the case?

Non è chiaro in questi giorni.

Molti luoghi non eseguono più test manuali, quindi non avere i dati di test per sé. Molti altri posti sono di dimensioni tali da non poter riprodurre il loro ambiente di produzione a causa dei costi. E soprattutto con la crescita esplosiva dei microservizi, diventa difficile mantenere in rapida sincronia gli ambienti in-sinc per garantire che i test in un ambiente di QA riproducano le cose in modo accurato per catturare i bug che si presenterebbero nella produzione.

Why should we have separate development, testing, and production environments?

• Se avere i dati dei test visti dagli utenti sarebbe pessimo.
• Se avere i dati del tuo prodotto visti dagli sviluppatori / tester sarebbe pessimo.
• Se non ti puoi fidare dei tuoi sviluppatori di non rompere male le cose, e non puoi correggere rapidamente la situazione.
• Se hai attivato la CI in modo tale che la promozione del codice sia semplice e veloce.

In sostanza, se il costo di avere gli ambienti è inferiore al costo di non con gli ambienti .

La ragione principale (e più evidente) è che non si vuole mai mescolare dati di test e produzione. Questo può generare incredibilmente confusione molto rapidamente sia per gli utenti del sistema che per gli sviluppatori. Quando si somministra la garanzia della qualità e i test unitari (cosa che si dovrebbe fare), è necessario assicurarsi che si trovino in un ambiente totalmente separato. Se qualcosa esplode nel tuo ambiente di sviluppo o in QA, influenzerebbe negativamente la produzione e quindi gli utenti dal vivo e i loro dati importanti! Assolutamente non vuoi che questo abbia effetto sulla produzione!

Questo si estende ai normali servizi che dovresti usare nel tuo lavoro quotidiano come il controllo della versione. Non è possibile utilizzare correttamente il controllo della versione se il codice che si sta controllando si trova in un ambiente live! I tuoi utenti diventeranno pazzi: cosa succede se devi annullare o eseguire il rollback? E se commettessi un drastico errore, quindici commetti in profondità? Come gestirai la ramificazione?

Per lo meno, dovresti separare il tuo ambiente in diverse istanze virtuali, ma devi davvero fare esattamente ciò che hai detto e avere istanze completamente separate per ogni ambiente; idealmente sviluppo, QA, stadiazione e produzione.

Tutto questo alla fine equivale a un enorme danno non solo per la tua applicazione frontale (e quindi per la tua reputazione con i tuoi utenti), ma anche per l'efficienza della tua squadra.

Avere solo una sola istanza Oracle disponibile non equivale a "nessuna separazione tra gli ambienti di sviluppo, di test e di sviluppo"!

Hai scritto in un commento

We currently use different schemas for different projects

Ok, quindi dedicando alcuni progetti solo per lo sviluppo e altri per i test, puoi separare i tuoi ambienti in una certa misura, utilizzando schemi diversi. Immagino che tu l'abbia già fatto, poiché questo è l'unico approccio ragionevole che conosco quando non è prevista la separazione delle istanze. Non riesco a immaginare che il tuo manager sia così pazzo da volere che tu mischi dati di sviluppo, dati di test e dati del cliente in uno schema in maniere arbitrarie. Molto probabilmente vuole solo risparmiare denaro non acquistando un secondo server o investire denaro nella licenza per una seconda istanza.

Pertanto, la domanda reale che devi porre è:

Abbiamo bisogno di utilizzare diverse istanze e / o server per separare ambienti di sviluppo, testing e produzione, oppure la separazione degli schemi è sufficiente?

Questo rende la risposta non così chiara come nelle altre risposte qui. Schemi diversi consentono diritti di accesso diversi, quindi è possibile ottenere almeno un certo isolamento in una certa misura all'interno di un'istanza Oracle. Tuttavia, i tuoi sviluppatori avranno probabilmente bisogno di alcuni diritti amministrativi all'interno del "loro" schema, quindi sarà più difficile accertarsi che non abbiano accesso ai dati di produzione se usi solo un'istanza.

Inoltre, un'istanza / un server significheranno anche risorse condivise tra dev, test e produzione: amministrazione condivisa degli utenti / schema, spazio su disco condiviso, CPU condivise, larghezza di banda della rete condivisa. Combina questo con la "legge sulle astrazioni leaky" , e sarà chiaro che l'utilizzo di una sola istanza avrà un certo rischio di effetti collaterali indesiderati tra ambiente di sviluppo, test e produzione.

Alla fine, devi decidere da solo: puoi lavorare efficacemente con gli svantaggi dell'approccio? La tua applicazione non è così intensa in termini di risorse ei tuoi dati di produzione non sono così "segreti" che è tollerabile avere un livello ridotto di separazione tra dev, test e produzione rispetto al livello che otterresti da "tre istanze / tre server" approccio? Se non puoi lavorare efficacemente in questo modo, o non senza un alto rischio di interferire nella produzione in un modo in cui inizi a perdere clienti, hai tutti gli argomenti necessari per convincere il tuo manager ad acquistare almeno un secondo server.

Sono necessari più tipi di ambiente e forse anche più server in ogni ambiente.

Gli sviluppatori possono aggiornare il codice in fase di sviluppo. Il codice potrebbe anche non funzionare - forse l'applicazione non inizierà nemmeno.

Ciò non influisce sul QA che sta testando l'ultima build stabile nel proprio ambiente.

Poiché sia lo sviluppo che il controllo qualità stanno aggiornando i loro ambienti, la produzione è sull'ultima versione di build di sei mesi fa e non è influenzata dalle modifiche in altri ambienti.

Queste modifiche che vengono implementate in vari ambienti possono essere codice o dati. Forse il QA deve testare uno script di database progettato per correggere alcuni dati non validi durante la produzione. Forse lo script peggiora il problema - ripristina un backup del database e riprova. Se ciò accadesse in produzione, potresti avere un problema finanziario molto serio.

Cosa succede se hai più versioni? Forse stai sviluppando la versione 2.0, ma hai ancora bisogno di correzioni di bug sul ramo di manutenzione 1.0. Ora hai bisogno di più ambienti di sviluppo e controllo qualità per assicurarti di poter sempre sviluppare e testare entrambe le diramazioni quando viene scoperto un bug critico e deve essere corretto ieri.

Hai già notato i problemi che non hanno causa di ambienti separati. Proprio lì hai la ragione fondamentale per gli ambienti separati: eliminare i problemi causati dai conflitti che inevitabilmente si presentano quando si cerca di eseguire operazioni di sviluppo, test e produzione in un singolo ambiente. Lo stesso ragionamento si applica al dare agli sviluppatori sandbox individuali per lavorare, mantiene gli errori di uno sviluppatore o anche solo le modifiche incompatibili da paralizzare l'intero team di sviluppo.

Questo è anche il miglior argomento che puoi fare al management per cambiare il singolo ambiente: indicare i problemi che un singolo ambiente sta già causando, mostrare la linea di tendenza e argomentare che prima o poi se le cose continueranno così come stanno andando essere un problema che costerà molto di più per ripulire (sia nello sforzo diretto che nella perdita della fiducia dei clienti nella capacità dell'azienda di fornire servizi) rispetto alla riconfigurazione di cose per ambienti separati.

Ci sono molte forze e dinamiche opposte. C'è il costo di avere molti server e il costo di averne uno solo. Penso che questa domanda possa telare oltre il semplice database? Potrei essere frainteso, ma si riferisce a un malinteso sistemico che è là fuori per i costi tangibili vs astratti

In genere i costi ovvi sono facili da capire.

I costi astratti sono più difficili da quantificare e quindi più difficili da comprendere. Impegno tecnico, costo degli errori, costo dello stress, onere per gli sviluppatori, effetti del cambiamento, test di regressione, impatto dei tempi di fermo e così via sono più difficili da spiegare.

ambienti diversi Gli ambienti sono generalmente separati per dati e / o scopo. Ogni ambiente ha una funzione diversa. Il tasso di cambiamento su un sistema, vale a dire. quanto spesso verrà aggiornato, quali tipi di modifiche ed effetti del cambiamento saranno presi in considerazione.

Usiamo diversi ambienti per banalizzare il cambiamento.

Utilizziamo ambienti diversi, quindi offriamo robustezza e certezza dell'ambiente che non è cambiato.

Usiamo gli ambienti per considerare gli effetti di un cambiamento.

Utilizziamo ambienti per ridurre i costi legati al cambiamento.

costa molto testare e stabilizzare un sistema Si creano ambienti per proteggere l'investimento effettuato sull'ambiente stabile.

Non sei mai una squadra troppo piccola per aderire a schemi di processo pragmatici, a basso costo, diligenti e comprovati.

Utilizzare un unico ambiente per tutto è come memorizzare tutte le tue foto su un disco rigido, puoi farlo, ma te ne pentirai.

alcune persone hanno bisogno di prove Sono stato in molte situazioni a trattare con clienti o altri che non apprezzano i costi di garantire robustezza e seguendo le migliori pratiche. Ti suggerirei di mettere insieme alcuni esempi di casi reali in cui i costi sono chiaramente definiti.