it-swarm-es.com

¿Es malo desarrollar contra datos de producción?

Siempre he escuchado que es una mala práctica desarrollar datos de producción y actualmente estoy en el proceso de pasar a un modelo Dev> Stage> Production , principalmente porque tengo un nuevo empleado con habilidades mínimas y Prefiero no tenerlo trabajando directamente con los datos de producción todavía.

Pero durante mucho tiempo he trabajado directamente con datos de producción con dolores de cabeza mínimos, excepto por algunos errores que se arrastran aquí o allá, cosas como problemas de ortografía, texto alternativo incorrecto, enlaces que apuntan a la ubicación incorrecta. Esto parece deberse a la falta de revisión por parte de mi parte, no a trabajar con datos en vivo.

Entonces, ¿por qué desarrollar en el sitio en vivo es una práctica tan mala?

10
plntxt

Si durante el desarrollo está ejecutando comandos SQL que incluyen INSERT o UPDATE en las tablas de bases de datos existentes, corre el riesgo de que esas tablas de bases de datos sean de misión crítica.

Algunos lugares sincronizan los datos de producción en la base de datos de desarrollo en algún intervalo, por ejemplo, una vez a la semana o a solicitud del desarrollador para que tenga datos nuevos con los que desarrollar.

Pero si sus datos de producción no están en riesgo por lo que está haciendo, por ejemplo, si simplemente estaba desarrollando una vista de algunos datos, generalmente no es un gran problema. Ahora, si está ejecutando informes que realizan escaneos de tablas, entonces tiene el potencial de bloquear una tabla, y sus usuarios existentes se verán afectados.

Me referiría a mi Administrador de la base de datos en casos como este, si no hay un DBA "oficial", me equivocaría por precaución. Es lo suficientemente simple como para crear una base de datos de desarrollo, incluso para mí. En un equipo es vital. De lo contrario, si insiste en tener solo una base de datos, puede anteponer sus tablas de base de datos de desarrollo con DEV_ y sentirse un poco mejor. Sí, eso requiere algunos cambios de código, pero en el desarrollo, agregar algunas variables durante el desarrollo $debug = true, etc., generalmente vale la pena el esfuerzo.

Muchas formas de abordar esto. Depende mucho de tu situación.

17
artlung

NO desea desarrollar datos de producción en su servidor de producción. Hay un par de grandes razones.

  1. El desarrollo ralentiza su caja de producción y crea vulnerabilidades. ¿Qué sucede si dejas la computadora desbloqueada y te alejas?
  2. Si comete un error, las personas que visitan su sitio pueden verlo.
  3. Si realiza algún tipo de actualización de datos dentro de una Transacción en su base de datos y no la confirma de inmediato o si la transacción tarda un tiempo en finalizar, bloqueará todas las tablas involucradas y podría provocar un tiempo de espera .
  4. ¡Algunos sistemas de bases de datos, específicamente SQL Server, harán bloqueos de tabla a veces solo en sentencias SELECT! Lo que significa que, sin querer, puede dar tiempo de espera a las personas o páginas de error en su sitio.

Nunca haría trabajo de desarrollo en una caja viva si fuera posible. Su mejor opción es hacer una copia de seguridad de la base de datos y las páginas y trabajar con la copia y luego enviar sus actualizaciones. Una herramienta que me ha ayudado muchísimo es SyncToy de Msft.

11
Ben Hoffman

Bueno, realmente puedes desordenar los datos. Imagina dejar una cláusula where. Incluso si tiene copias de seguridad por hora, sería difícil solucionarlo.

7
Echo

Si tiene datos de producción disponibles, es razonable usarlos para las pruebas, pero use una base de datos de prueba separada con una copia de esos datos. De lo contrario, muchas cosas funcionarán para sus pocos registros de prueba "blabla", pero no para un escenario real.

Y para desarrollar datos de producción en vivo, recuerde las leyes de Murphy "Cualquier cosa que pueda salir mal saldrá mal", y es muy fácil cometer un pequeño error con grandes consecuencias negativas.

3
devmake

Si no conduce sin cinturón de seguridad, no desarrolle datos de producción. Solo un problema de seguridad.

3
MrChrister