Test account e prodotti in un sistema di produzione

Question

Vale la pena progettare un sistema che preveda che account e prodotti di test siano presenti e attivi nella produzione o che non vi siano contaminazioni dei database di produzione con entità di test, anche se il tuo personale di spedizione sa di non spedire alcuna scatola indirizzata a " ; Test cliente " ;?

Ho implementato protocolli di messaggistica che hanno un test = " True " nella specifica e si chiedeva se uno schema moderno dovrebbe includere metadati per etichettare ordini, conti, transazioni, ecc. come entità di test che vengono elaborate proprio come qualsiasi altra entità - ma poco prima del punto in cui vengono spesi soldi. Vale a dire: falsifica l'addebito di una carta di credito immaginaria e simula la spedizione di un pacco.

Non ci si aspetta che questo sostituisca un database di test, sviluppo e QA completamente separato, ma anche con quelli, abbiamo sempre avuto il noto SKU di prova e Test cliente nel sistema di produzione. Innocuo?

Answer 1

Avere account di prova in produzione è qualcosa che di solito non vedo perché apre una potenziale falla nella sicurezza. Uno dovrebbe cercare di duplicare il più possibile l'ambiente di produzione nei test, ma ci sono ovviamente casi in cui ciò non è possibile. Un costoso esempio di produzione di solo hardware. Direi che come pratica generale dovrebbe essere scoraggiato, ma come per tutte le cose se puoi fornire una ragione che ha senso per te, allora potresti trascurare una regola dura e veloce.

Answer 2

Immagino che la polizia delle migliori pratiche dichiarerebbe il mantra "mai e poi mai testato in prod" e forse anche inserire "gli sviluppatori non dovrebbero avere accesso a prod".

Tuttavia, lavoro su un sistema basato su mainframe in cui ci sono enormi differenze tra produzione e test / qa / qc; più è grande il sistema, più è probabile una situazione del genere. Inoltre, più gruppi sono coinvolti nell'applicazione, più è probabile che sia.

Ho bisogno di più di due mani per contare quante volte abbiamo potuto solo duplicare un problema nell'ambiente di produzione. L'opzione diventa quindi la creazione di tabelle / utenti / dati di test o l'utilizzo di dati dei clienti in tempo reale.

A volte creiamo anche record di test nelle tabelle di produzione, poiché ad alcuni utenti / clienti piace avere qualcosa che possono cercare / recuperare che è sempre lì.

Quindi il mio consiglio è che è OK mettere in produzione account / prodotti di prova se questo aiuterà a risolvere i problemi dopo il via libera.

Answer 3

Se il tuo database è stato creato da script in modo automatizzato, questo diventa una non-domanda.

Nel mio ambiente utilizziamo il controllo automatico della velocità per build continue. Gli script SQL per la generazione del database vengono controllati in CVS con tutto il resto e il database viene ricostruito da tali script su base giornaliera.

I nostri dati di test sono una seconda serie di script sql, che vengono eseguiti per il database di test e non per il database di produzione.

Dati i nostri dati di test sull'ambiente non toccano mai il database di produzione.

Questa soluzione funziona davvero alla grande per noi.

Answer 4

Non metterei i dati di test in un sistema di produzione né vorrei avere accesso a questo sistema come sviluppatore.

Sto lavorando in un settore con informazioni mediche e finanziarie molto sensibili e avere tali informazioni renderebbe impossibile distinguere i dati produttivi dai dati dal sistema di test.

IMHO la migliore pratica è separare completamente questi due mondi e investire nella creazione di una procedura per preparare un ambiente di test completo.

Answer 5

Nei nostri sistemi ERP (accessibili solo internamente) disponiamo di dati di test in modo che quando spostiamo le modifiche da ambienti di test a ambienti di produzione, possiamo testare l'intero processo. Considero tali dati come un male necessario, poiché sottili differenze di configurazione tra i sistemi possono causare risultati catastrofici, quindi una volta che un cambiamento è in produzione, testiamo completamente prima di "rilasciare". agli utenti.

Come ho già detto, queste sono solo app interne, quindi i rischi per la sicurezza sono leggermente diminuiti - questa è una preoccupazione molto valida.

Answer 6

Mai e poi mai testare in prod, anche se è qui che vengono generate tutte le entrate / vengono raccolte le statistiche / accade la magia ...?

Avere sempre un piano di test di produzione. Ci saranno problemi che si verificano su prod o, se sei sfortunato, solo succede su prod. Se non hai nulla in atto, la prima volta che devi testare il pungolo (che di solito sono casi di stress elevato) sarai nel torrente senza pagaia.

Non è innocuo avere dati di test su prod, devi fare attenzione.