Quanto dovrebbero essere simili gli ambienti di PreProd e Prod?

Di recente ho partecipato a un progetto e durante l'uscita abbiamo realizzato che non funzionava in produzione. Funziona in tutti gli altri ambienti, ma poiché abbiamo un team di rilascio separato e non possiamo impostare noi stessi i server e gli ambienti, non abbiamo visibilità della configurazione su di essi.

Sospettiamo che Prod abbia alcune autorizzazioni utente nel suo account o impostazioni IIS che sono diverse, quindi ora ci stiamo lavorando.

Quindi penso che tutta questa faccenda sia stata un'esperienza di apprendimento per me e non voglio che la stessa cosa si ripeta di nuovo. Vorrei chiedere, quanto dovrebbero essere diversi questi ambienti? Ho sempre pensato che PreProd dovrebbe essere una copia identica all'ambiente Prod usando una copia dello stesso database, usando una copia dello stesso account utente, dovrebbe essere installata sugli stessi server ecc.

Ma quanto lontano dovrei prenderlo? Se il sito Web è rivolto verso l'esterno, PreProd deve essere rivolto verso l'esterno? Cosa succede se il sito Web ha componenti che non richiedono un account utente o una password per navigare? Va ancora bene esporlo al mondo esterno?

Dovresti certamente testare su un ambiente identico ai tuoi server di produzione, per quanto possibile. In caso contrario, non testerai ciò che i tuoi clienti useranno. Se non altro è necessario un tale ambiente per testare eventuali segnalazioni di bug.

Ovviamente ci saranno cose che non vorrai identiche: vengono in mente collegamenti ai sistemi di pagamento, ma questi dovrebbero essere derisi come se fossero la cosa reale . Ci sono anche cose che non puoi replicare: la scala del sistema.

Potresti voler testare tramite un URL esterno: di nuovo stai testando ciò che vedranno i tuoi utenti. Anche il test tramite un URL esterno utilizzerà la rete in modo diverso rispetto all'uso interno del sistema. Le autorizzazioni (ad esempio) svolgeranno un ruolo come la larghezza di banda disponibile, i firewall, ecc. Tutti gli utenti dovranno affrontare ma salterai se accedi direttamente al sistema.

Non vedo alcun problema con i componenti che non richiedono un account e una password. Se non ha bisogno di una password, non è vitale / sensibile, se è sensibile, perché non ha una password?

Penso che la migliore pratica per questo sia l'approccio Blue Green Deployment, coniato da Jez Humble e David Farley nel loro libro Continuous Delivery e descritto da Martin Fowler nel suo post sul blog Blue Green Deployment .

La premessa è molto semplice. Dal post di Martin Fowler:

L'approccio di distribuzione blu-verde ... [assicura] di avere due ambienti di produzione, il più identici possibile. In qualsiasi momento uno di questi, diciamo blu per l'esempio, è live. Mentre prepari una nuova versione del tuo software, esegui la fase finale del test in un ambiente verde. Una volta che il software funziona in ambiente verde, si commuta il router in modo che tutte le richieste in arrivo vadano nell'ambiente verde: quello blu ora è inattivo.

La distribuzione blu-verde offre anche un modo rapido per il rollback: se qualcosa va storto, il router torna al tuo ambiente blu.

Questo approccio risolverebbe il tuo problema di non avere identici ambienti di pre-produzione e produzione, oltre a ottimizzare la tua strategia di implementazione.

Il nostro ambiente di pre-produzione finale è semplicemente uno dei server attivi estratti dal bilanciamento del carico. Distribuiamo la nostra build di pre-produzione (che è sostanzialmente identica alla build live a parte le stringhe di connessione al database e un paio di altre modifiche di configurazione) e lo testiamo. Se ciò va bene, distribuiamo il codice live e, infine, se ciò si rivela corretto, restituiamo il server al bilanciamento del carico e distribuiamo la build di produzione sui server rimanenti uno a uno.

Dovrebbero essere il più simili possibile, in modo da poter identificare i problemi in qualsiasi punto all'interno del sistema, con la possibile eccezione di un'incapacità di ridimensionamento. Se possibile, l'unica differenza tra l'ambiente di produzione e l'ambiente di pre-produzione / messa in scena / test sarebbe la dimensione - mi aspetto che un ambiente di produzione sia composto da molte più macchine in un ambiente su larga scala. Dovresti anche rispecchiare le dediche delle macchine che hai, come server di database, server web e così via.

Tuttavia, una replica esatta potrebbe non essere possibile nell'ambito del budget corrente. Più è vicino, più saranno efficaci i test e meno problemi si insinueranno durante una spinta alla produzione.

Prendo una posizione diversa rispetto a ChrisF se questo ambiente dovesse essere rivolto al pubblico. Dico che non dovrebbe essere. Opterei per l'esecuzione su una copia dei database effettivi, o almeno una copia di un sottoinsieme dei database live effettivi e di un ambiente rivolto verso l'interno. In questo modo, puoi testare dati reali e realistici e non preoccuparti delle falle di sicurezza che portano a una perdita. Naturalmente, è possibile disinfettare i dati, ma ciò potrebbe rimuovere alcuni "dati sporchi" dall'ambiente che potrebbero portare alla scoperta di un difetto in un sistema attivo.

Ovunque abbia lavorato banche, telecomunicazioni e così via, il pre-prod era una copia diretta della produzione, tranne per il fatto che il database sarebbe vecchio di una settimana circa. Si è trattato di un processo enorme per mantenere i dati tra i pre-prodotti, ma è stato considerato essenziale per le aziende per cui ho lavorato per i quali è stato implementato il pre-prodotto.

Nella sezione bancaria dell'Unione africana, il governo multa le banche per inadempienza del servizio, ad esempio gli sportelli automatici dei siti Web e così via sono inattivi ogni minuto. Non è raro sentir parlare di un team di sviluppo / test licenziato per un incidente. Il pre-prod non è per ogni azienda o processo di sviluppo, ma essenziale per alcuni.