Probar cuentas y productos en un sistema de producción.

Question

¿Vale la pena diseñar un sistema para esperar que las cuentas y los productos de prueba estén presentes y activos en producción, o no debería haber contaminación de las bases de datos de producción con entidades de prueba, incluso si su equipo de envío sabe que no debe enviar ninguna caja dirigida al "Cliente de prueba"? ?

Implementé protocolos de mensajería que tienen un atributo test="True" en la especificación y me pregunté si un esquema moderno debería incluir metadatos para etiquetar pedidos, cuentas, transacciones, etc.como entidades de prueba que se procesan como cualquier otra entidad, pero justo antes del punto en el que se gasta el dinero.Es decir:finge cargar una tarjeta de crédito imaginaria y finge el envío de un paquete.

No se espera que esto sea un sustituto de una base de datos de prueba, desarrollo y control de calidad completamente separada, pero incluso con eso, siempre hemos tenido el conocido SKU de prueba y el Cliente de prueba en el sistema de producción.¿Inofensivo?

Answer 1

Tener cuentas de prueba en producción es algo que normalmente no veo con buenos ojos porque abre un potencial agujero de seguridad.Uno debería esforzarse por duplicar la mayor cantidad posible del entorno de producción durante las pruebas, pero obviamente hay casos en los que eso no es posible.El costoso hardware de producción es un buen ejemplo.Yo diría que, como práctica general, debería desaconsejarse, pero como ocurre con todas las cosas, si puede proporcionar una razón que tenga sentido para usted, entonces podría pasar por alto una regla estricta y rápida.

Answer 2

Me imagino que la Policía de Mejores Prácticas diría el mantra "nunca probar en producción" y tal vez incluso agregaría "los desarrolladores no deberían tener acceso a la producción".

Sin embargo, trabajo en un sistema basado en mainframe donde existen enormes diferencias entre producción y prueba/qa/qc;cuanto más grande es el sistema, más probable es que se produzca esa situación.Además, cuantos más grupos tengan interés en la aplicación, más probable será que esto suceda.

Necesito más de dos manos para contar cuántas veces solo pudimos duplicar un problema en el entorno de producción.La opción entonces es crear tablas/usuarios/datos de prueba o utilizar datos de clientes en vivo.

A veces también creamos registros de prueba en tablas de producción, ya que a algunos usuarios/clientes les gusta tener algo que puedan buscar/recuperar y que siempre esté ahí.

Entonces, mi consejo es que está bien poner cuentas/productos de prueba en producción si eso ayuda a solucionar problemas después de la puesta en marcha.

Answer 3

Si su base de datos se crea a partir de scripts de forma automatizada, entonces esto deja de ser una pregunta.

En mi entorno utilizamos el control de crucero para construcciones continuas.Los scripts SQL para generar la base de datos se registran en CVS con todo lo demás, y la base de datos se reconstruye a partir de esos scripts diariamente.

Nuestros datos de prueba son un segundo conjunto de scripts SQL, que se ejecutan para la base de datos de prueba y no para la base de datos de producción.

Dado nuestro entorno, los datos de prueba nunca tocan la base de datos de producción.

Esta solución realmente funciona muy bien para nosotros.

Answer 4

No pondría ningún dato de prueba en un sistema de producción ni querría tener acceso a este sistema como desarrollador.

Estoy trabajando en una industria con información médica y financiera muy confidencial y tener dicha información haría imposible distinguir los datos productivos de los que salen del sistema de pruebas.

En mi humilde opinión, la mejor práctica es separar completamente estos dos mundos e invertir en establecer un procedimiento para preparar un entorno de prueba integral.

Answer 5

En nuestros sistemas ERP (solo accesibles internamente) tenemos datos de prueba para que cuando trasladamos cambios de los entornos de prueba a los de producción podamos probar todo el proceso.Veo esos datos como un mal necesario, ya que diferencias sutiles de configuración entre sistemas pueden causar resultados catastróficos, por lo que una vez que un cambio está en producción, lo probamos completamente antes de "lanzarlo" a los usuarios.

Sin embargo, como dije, estas son aplicaciones internas únicamente, por lo que los riesgos de seguridad se reducen un poco; esa es una preocupación muy válida.

Answer 6

¿Nunca realizar pruebas en producción, a pesar de que es allí donde se generan todos los ingresos/se recopilan las estadísticas/ocurre la magia...?

Tenga siempre un plan de pruebas de producción.Habrá problemas que ocurrirán con el producto o, si no tienes suerte, solo sucede en prod.Si no tiene nada en su lugar, la primera vez que necesite probar con la picana (que generalmente son casos de alto estrés), se quedará sin remo.

No es inofensivo tener datos de prueba en el producto, hay que tener cuidado.