Buoni processi per il debug dell'ambiente di produzione? Copia dei dati su Dev?

Question

Ci stavo pensando un po '. L'idea è che qualcosa vada storto in PROD. I dati acquisiti fanno sì che l'app Web si comporti in modo diverso rispetto ad altri ambienti. Quindi, anche i dati in altri ambienti non sono sincronizzati con prod (come previsto). Tuttavia, un bug arriva e per qualche ragione accade solo in PROD, probabilmente a causa delle differenze nei dati.

Mi chiedo quale sia una buona pratica per rimediare a questo tipo di problemi? Altri test, di sicuro. Ma oltre a questo? Uno potrebbe creare nuovi dati in dev, ma il punto è che alcuni dati, o una combinazione di azioni, fanno sì che un punto dati sia sbagliato. Forse quando si utilizza un'altra origine dati per arrivare al punto dati "effettivo", che è diverso dal punto dati "atteso". Si scusa che questa non è una grande descrizione e cerca di essere sia un esempio che una definizione di un bug di produzione generale.

So che questa non è una domanda molto precisa. Speriamo che ci siano dei riferimenti che danno buoni suggerimenti.

Answer 1

Questa è una domanda molto interessante. Un approccio che ho usato prima è di effettuare deliberatamente i miei test finali in produzione (TIP).

Prima di infilzi mia effigie con più aghi a punta, mi sento fuori per un minuto, mentre io parlo di distribuzione continua :-)

L'idea è quella di implementare una nuova build in produzione e quindi utilizzare il routing personalizzato per dirigere traffico tra la vecchia e la nuova produzione. In linea di principio, questo è abbastanza semplice: si avvia instradando la vecchia build ai clienti attuali e la nuova build solo al proprio team di ingegneri. I tuoi clienti non vedono alcun cambiamento. Ma il tuo team può iniziare a testare la tua nuova build, comprese cose disordinate come il disaster recovery e lo stress test. Spero che scoprirai il tipo di bug di cui parli nella tua domanda.

Se c'è un problema, è sufficiente eseguire il rollback della nuova build. Se i tuoi test non riscontrano alcun problema, esegui il roll out per indicare il 5% della base clienti. Quindi il 10% e il 20% e così via.

Mentre semplice in linea di principio, ci sono alcuni problemi che è necessario pianificare fin dall'inizio. Il primo è rappresentato da schemi di dati e dati, che devono funzionare correttamente sia su vecchie che su nuove build. Finché i servizi utilizzati dalla tua web app sono progettati per gestire almeno un rollback dopo la distribuzione di una nuova build e la tua nuova build comprende sia i vecchi che i nuovi dati, allora dovresti essere a posto.

Il secondo problema sono le modifiche API/interfaccia. Anziché modificare o eliminare metodi o parametri, è necessario creare una nuova API/interfaccia che reindirizzi principalmente alla vecchia API/interfaccia, ad eccezione del codice nuovo/modificato.

Altri problemi, tra cui modifiche incompatibili alla configurazione e impostazioni tra le build. Questi problemi non sono fatali, ma è necessario prima pianificare e testare. E la grande ricompensa è che puoi tranquillamente eseguire test finali del tuo codice in produzione senza intaccare i tuoi clienti.

Alcuni link test in produzione:

• There's no place like production
• The future of software testing
• Production is a mixed blessing
• TIP - malpractice?
• TIP really happens
• Why TIP isn't as stupid as it sounds