Quanto dovrebbero essere simili gli ambienti di Pre Prod e Prod?

Dovresti certamente testare su un ambiente identico ai tuoi dischi di produzione, per quanto possibile. Se non lo fai, non stai testando ciò che i tuoi clienti useranno. Se non altro hai bisogno di un tale ambiente per testare eventuali segnalazioni di bug.

Ovviamente ci saranno cose che non vorrai identiche - i link ai sistemi di pagamento ti vengono in mente, ma questi dovrebbero essere presi in giro 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 un modo diverso rispetto all'uso interno del sistema. Le autorizzazioni (ad esempio) avranno un ruolo come la larghezza di banda, i firewall, ecc. Disponibili. Tutti gli utenti dovranno affrontare, ma salterai se accederai direttamente al sistema.

Non vedo alcun problema con componenti che non richiedono un account e una password. Se non ha bisogno di una password, allora non è vitale / sensibile, se è sensibile allora 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 in il loro libro Consegna continua e descritto da Martin Fowler nel suo post sul blog Distribuzione verde blu .

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

The blue-green deployment approach ... [ensures] you have two production environments, as identical as possible. At any time one of them, let's say blue for the example, is live. As you prepare a new release of your software you do your final stage of testing in the green environment. Once the software is working in the green environment, you switch the router so that all incoming requests go to the green environment - the blue one is now idle.

Blue-green deployment also gives you a rapid way to rollback - if anything goes wrong you switch the router back to your blue environment.

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 live prelevati dal servizio di bilanciamento del carico. Distribuiamo la nostra build di preproduzione (che è fondamentalmente identica alla build dal vivo a parte le stringhe di connessione al database e un paio di altre modifiche alla configurazione) e lo testiamo. Se ciò va bene, distribuiamo il codice live e, infine, se ciò si dimostra soddisfacente, restituiamo il server al servizio di bilanciamento del carico e distribuiamo la produzione di produzione ai server rimanenti uno per uno.

Dovrebbero essere il più possibile simili, in modo da poter identificare i problemi in qualsiasi punto del sistema, con la possibile eccezione di un'incapacità di scalare. Se possibile, l'unica differenza tra l'ambiente di produzione e l'ambiente di pre-produzione / staging / testing sarebbe la dimensione - mi aspetto che un ambiente di produzione consista di 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 con il budget corrente. Più è vicino, più saranno efficaci i test e meno probabili problemi si insinueranno durante la fase di push alla produzione.

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

Ovunque ho lavorato per le banche, le telecomunicazioni e il pre-prod. ecc. era una copia diretta della produzione, eccetto che il database sarebbe stato di una settimana o giù di lì. È stato un processo massiccio il mantenimento dei dati attraverso i pre-prod, ma è stato considerato essenziale per le aziende per le quali ho lavorato e che ha implementato il pre-prod.

Nella sezione bancaria dell'UA, il governo multata le banche per il fallimento del servizio, ad es. Gli sportelli automatici del sito Web e così via sono giù, ogni minuto. Non è raro sentire parlare di un team di sviluppo / test per un incidente. Il pre-prodotto non è per ogni azienda o processo di sviluppo, ma è essenziale per alcuni.