Lavoro in un piccolo team di programmazione a supporto di un'organizzazione più grande. Quest'anno il nostro manager ha deciso che utilizzeremo le tecnologie Oracle Apex per gestire la maggior parte dei dati della nostra azienda.

Questo sarebbe ok, tranne che abbiamo un solo server Apex. Il nostro manager ha decretato che tutto accade in quell'unica istanza. Il nostro team sta sviluppando app, mentre il nostro gestore le demo e i nostri clienti interni le usano, il che per ovvie ragioni sta già causando problemi!

Posso solo aspettarmi che questo peggiori man mano che diventiamo investiti maggiormente in Apex, le app diventano più complesse e il numero di utenti aumenta. Ho sentito che la migliore pratica è avere ambienti di sviluppo, test e produzione separati, ma perché è così?

La domanda: perché dovremmo avere ambienti di sviluppo, test e produzione separati?

Perché dovremmo avere ambienti di sviluppo, test e produzione separati?

Sono in corso diverse attività contemporaneamente:

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

Vuoi che tutto ciò avvenga nello stesso ambiente? Vuoi che l'azienda si fermi perché un nuovo test ha spinto i tuoi server a scambiarsi su hard disk e stanno consumando tutti i core del processore? Vuoi che i tuoi test si fermino perché uno sviluppatore ha realizzato una bomba a forcella contorta da un esperimento di ridimensionamento? Vuoi che il codice che ritieni abbia funzionato a causa dello spago e del nastro isolante di uno sviluppatore nei test per essere eseguito in produzione? Vuoi che gli sviluppatori lavorino con dati di produzione potenzialmente sensibili (so che questo non è un problema in tutte le aziende, ma è in molti di loro)?

Cosa impedisce che si verifichino questi problemi?

Ambienti separati.

Di cosa hai bisogno?

Hai bisogno di ambienti separati.

Per dirla in modo formale

Sono necessari ambienti separati per i seguenti motivi:

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

Per il tuo contesto, una nuova piattaforma tecnologica

Forse questa non è ancora veramente produzione (poiché è una piattaforma relativamente nuova), ma otterrai i tuoi ambienti separati quando l'azienda inizia a fare affidamento su di essa e sono abbastanza saggi da prevedere il rischio o realizzarlo imparando il duro modo.

Ho sentito che la migliore pratica è avere ambienti di sviluppo, test e produzione separati, ma perché è così?

Non è così chiaro in questi giorni.

Molti posti non eseguono più test manuali, quindi non dispongono di dati di test di per sé. Molti altri posti hanno dimensioni tali che non possono riprodurre il loro ambiente di produzione a causa dei costi. E soprattutto con la crescita esplosiva dei microservizi, diventa difficile mantenere gli ambienti in rapido mutamento abbastanza sincronizzati da garantire che i test in un ambiente di controllo qualità riproducano accuratamente le cose per rilevare i bug che si presenterebbero in produzione.

Perché dovremmo avere ambienti di sviluppo, test e produzione separati?

• Se i tuoi dati di test fossero visti dagli utenti sarebbe molto male.
• Se vedere i tuoi dati prod su dev / tester fosse molto male.
• Se non puoi fidarti dei tuoi sviluppatori per non rompere male le cose e non puoi risolvere rapidamente quella situazione.
• Se disponi di CI automatizzati 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 avere gli ambienti .

Il motivo principale (e più evidente) è che non vuoi mai mescolare i dati di test e produzione. Questo può diventare incredibilmente confuso molto rapidamente sia per gli utenti del sistema che per gli sviluppatori. Quando si amministrano l'assicurazione 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 nel QA, ciò influenzerebbe negativamente la produzione e quindi gli utenti live e i loro dati importanti! Non vuoi assolutamente 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 versione se il codice che stai controllando si trova in un ambiente live! I tuoi utenti diventeranno pazzi: cosa succede se è necessario ripristinare o ripristinare? E se commettessi un errore drastico quindici commetti in profondità? Come gestirai la ramificazione?

Come minimo, dovresti separare il tuo ambiente in diverse istanze virtuali, ma devi davvero fare esattamente quello che hai detto e avere istanze completamente separate per ogni ambiente; idealmente sviluppo, QA, messa in scena e produzione.

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

La disponibilità di una sola istanza Oracle non significa lo stesso "nessuna separazione tra ambienti di sviluppo, test e produzione"!

Hai scritto in un commento

Attualmente utilizziamo schemi diversi per progetti diversi

Ok, quindi dedicando alcuni progetti solo per lo sviluppo e altri per i test, puoi separare i tuoi ambienti in una certa misura, usando schemi diversi. Immagino tu l'abbia già fatto, dato che questo è l'unico approccio sensato che conosco quando non è pianificata la separazione delle istanze. Non riesco a immaginare che il tuo manager sia così folle da voler mescolare dati di sviluppo, dati di test e dati dei clienti in un unico schema in modi arbitrari. Probabilmente vuole solo risparmiare denaro non acquistando un secondo server o investendo denaro nella licenza per una seconda istanza.

Pertanto, la vera domanda che devi porre è:

Dobbiamo usare istanze e / o server diversi per separare ambienti di sviluppo, test e produzione o è sufficiente la separazione degli schemi?

Ciò 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 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 assicurarsi che non avranno accesso ai dati di produzione se usi solo un'istanza.

Inoltre, un'istanza / un server significherà anche risorse condivise tra sviluppo, test e produzione - amministrazione utente / schema condivisa, spazio su disco condiviso, CPU condivise, larghezza di banda di rete condivisa. Combina questo con la "legge delle astrazioni che perdono" , e sarà chiaro che l'uso di una sola istanza avrà un certo rischio di ottenere effetti collaterali indesiderati tra ambiente di sviluppo, test e prod.

Alla fine, devi decidere da solo: puoi lavorare efficacemente con gli svantaggi dell'approccio? La tua applicazione non è così ad alta intensità di risorse e i tuoi dati di produzione non sono così "segreti" da tollerare un livello di separazione tra sviluppo, test e produzione ridotto rispetto al livello che otterresti da un "tre istanze / tre server"? approccio? Se non riesci a lavorare in modo efficace in questo modo, o meno senza un alto rischio di interferire con la produzione in modo da iniziare a perdere clienti, hai tutti gli argomenti di cui hai bisogno per convincere il tuo manager ad acquistare almeno un secondo server.

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

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

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

Poiché sia ​​lo sviluppo che il QA stanno aggiornando i loro ambienti, la produzione è stata sviluppata l'ultima versione di sei mesi fa e non è influenzata dai cambiamenti in altri ambienti.

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

Cosa succede se si dispone di più versioni? Forse stai sviluppando la versione 2.0, ma hai ancora bisogno di rilasci di bug nel ramo di manutenzione 1.0. Ora hai bisogno di più ambienti di sviluppo e QA per assicurarti di poter sempre sviluppare e testare entrambi i rami quando viene scoperto un bug critico e deve essere risolto ieri.

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

Questo è anche l'argomento migliore che puoi fare alla direzione per allontanarti dal 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 continuano come sono, ci sarà un problema che costerà molto di più per la pulizia (sia nello sforzo diretto che nella perdita della fiducia dei clienti nella capacità della vostra azienda di fornire servizi) rispetto al costo della riconfigurazione di cose per ambienti separati.

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

In genere i costi ovvi sono facili da capire.

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

ambienti diversi sono generalmente separati per dati e / o scopi. Ogni ambiente ha una funzione diversa. Il tasso di cambiamento su un sistema, ad es. con quale frequenza verrà aggiornato, che tipo di modifiche ed effetti del cambiamento sono tutti considerati.

Usiamo ambienti diversi per banalizzare il cambiamento.

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

Utilizziamo gli ambienti per considerare gli effetti di un cambiamento.

Utilizziamo gli ambienti per ridurre i costi legati al cambiamento.

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

Non sei mai una squadra troppo piccola per aderire a modelli di processo pragmatici, economici, diligenti e comprovati.

Utilizzare un ambiente per ogni cosa è come archiviare tutte le tue foto su un solo disco rigido, puoi farlo, ma te ne pentirai.

alcune persone hanno bisogno della prova che mi sono trovato in molte situazioni a che fare con clienti o altri che non apprezzano i costi per garantire la robustezza e seguire le migliori pratiche. Vorrei suggerire di mettere insieme alcuni esempi di casi reali in cui i costi sono chiaramente definiti.