¿Es malo desarrollar datos de producción?

10

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> Etapa> Producción , principalmente porque tengo un nuevo empleado con habilidades mínimas y prefiero no tenerlo trabajar directamente con 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 mala práctica?

site-deployment development

— plntxt
fuente

Simplemente podría duplicar los datos que tiene en su servidor de producción en el servidor de desarrollo.

— HoLyVieR

1

mmmm ... ¿cómo puedo votar esta pregunta sin parecer que respalda tu manera de hacer las cosas directamente con los datos de producción? : S

— vmarquez

2

@vmarquez ¿Una pregunta sobre una mala práctica es necesariamente una mala pregunta?

— plntxt

No, no es. Estaba a punto de votar porque tenía la sensación de que este tipo de preguntas son una excelente forma de educar sobre las mejores prácticas, y luego, de alguna manera, se me ocurrió la idea de que la votación podría tomarse como una aprobación tácita en la mala práctica, provocando exactamente el efecto contrario. Ahora creo que votar puede ser engañoso ... al menos en algunos casos.

— vmarquez

1

La gente vota sobre las cosas por todo tipo de razones diferentes. No tomo un voto ya que "esta persona obtuvo algo de esta pregunta".

— artlung

17

Si durante el desarrollo está ejecutando comandos SQL que incluyen INSERTo UPDATEen tablas de bases de datos existentes, corre un riesgo en la medida en que esas tablas de bases de datos son 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 para 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 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.

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

— artlung
fuente

+1 en el proceso de sincronización. Hacemos eso a pedido aquí para nuestro desarrollo. También tenemos un control de calidad, que es un área sincronizada con mayor frecuencia para la revisión final de los cambios antes de que lleguen a producción. Pero a veces hacemos consultas contra los datos de producción, solo porque el problema está relacionado con los datos y es muy difícil de replicar.

— Milner

+1 y la sincronización pueden ser complicadas. En muchos casos, querrá hacer cosas como parte de Prod-> Test push como eliminar direcciones de correo electrónico y nombres, etc. para evitar enviar accidentalmente un correo electrónico a "Dear Rich Bastard"

— JasonBirch

11

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

El desarrollo ralentiza su caja de producción y crea vulnerabilidades. ¿Qué sucede si dejas la computadora desbloqueada y te alejas?
Si comete un error, las personas que visitan su sitio pueden verlo.
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 .
¡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 puede dar sin querer a las personas tiempos de espera 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.

— Ben Hoffman
fuente

7

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

— Echo dice reinstalar a Mónica
fuente

3

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

— MrChrister
fuente

3

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.

— devmake
fuente