¿Hay un lugar adecuado para una base de datos provisional?

Question

Hemos estado almacenando nuestra base de datos provisional en el servidor de base de datos de producción con la mentalidad de que tiene sentido ser lo más idéntico posible a la producción.

Últimamente, algunos comentarios me han hecho cuestionar esa idea. Como existe la remota posibilidad de que haga algo por error en la producción, puede ser lógico no poner ambos en el mismo servidor.

¿Debería mi base de datos de ensayo vivir realmente en el mismo servidor que mi base de datos de desarrollo y no el mismo servidor que la producción?

Answer 1

En mi libro, un entorno de ensayo debe ser independiente porque le permite ensayar los procedimientos de despliegue para una nueva versión. Si está en la misma casilla o en la misma máquina virtual, no obtendrá la experiencia "completa" de las actualizaciones de la biblioteca y demás.

Personalmente, me gustan las máquinas virtuales porque puedo llevar la producción al escenario y luego actualizarla. Esto significa que mi actualización es muy realista, porque se están reproduciendo todos los datos del caso de borde, bibliotecas y demás. Esto es algo bueno ... No puedo contar la cantidad de veces durante los 9 años de historia de nuestro producto principal que no se incluyó un módulo de biblioteca o alguna secuencia de comandos de actualización para la base de datos que no se detectó entornos de desarrollo y prueba.

En cuanto a tocar el entorno de producción ... Yo diría que nunca haga esto si hay una alternativa. Actualice una biblioteca compartida en etapas que también afecte la producción y sentirá el dolor. Actualice el código y haga que su servidor web se ponga nervioso y que haya reducido (al menos parte de) su entorno en vivo.

Si tiene que simularlo, le recomiendo que comparta con los entornos de desarrollo y se dé cuenta de que la actualización de la producción provoca un tiempo de inactividad inesperado durante la actualización a medida que valida que todo funcione. Tuvimos que hacer eso durante los primeros años por razones presupuestarias y puede funcionar siempre y cuando no solo actualices la producción y te alejes.

En resumen

• producción es sacrosanta: no comparta cualquier aspecto de no producción si puede evitarlo.
• Las máquinas virtuales son su amigo: le permiten clonar entornos de trabajo y actualizarlos con un riesgo casi nulo (simplemente copie el archivo VM sobre cualquier intento fallido de actualización).
• La etapa debe estar aislada del desarrollo para evitar el exceso de confianza con la rutina de actualización.

Answer 2

Lo ideal es que desee tener un entorno de ensayo independiente que refleje su entorno en vivo, pero en realidad no existe en él. Sin embargo, $$$ no siempre permite esto, por lo que no siempre se sigue el ideal.

Esto incluye (pero no puede limitarse a) lo siguiente:

• servidores Web
• servidores de bases de datos
• Los servidores de aplicaciones

y cualquier cosa en esas máquinas (física o virtual) deberían estar aislados en sus respectivos entornos, por lo que no debería ver el código de ensayo en un servidor de producción, y de manera similar, no debería ver una base de datos provisional en una base de datos de producción. ver. Deberían estar separados.

Además, si usa una gran cantidad de ancho de banda internamente, puede aislar las redes para evitar que el uso del ancho de banda del entorno de prueba sature el ancho de banda del entorno de producción.

Answer 3

Cualquiera que sea la solución que elija al final, diría: ¡mantenga su servidor de producción solo para producción y producción!

Si pone un poco de producción en él, existe el riesgo de errores, por supuesto, como usted dijo ... Pero también existe el riesgo de errores: ¿y si su aplicación se vuelve loca, y utiliza todo el CPU del servidor, por ejemplo? Tu producción puede sufrir de eso.
Y eso es sólo un ejemplo, por supuesto ;-)

En mi opinión, la mejor solución sería tener otro servidor para su puesta en escena, con una configuración que es lo más cerca posible (un verdadero "clonar" sería el mejor) en la configuración de producción.

Teniendo en cuenta que esto puede costar un poco para una máquina utilizada por pocos probadores, a menudo no es posible :-(Una alternativa que he visto es utilizar una máquina virtual (alojada en su servidor de desarrollo - no la de producción): actúa como una máquina "real", en la que puede hacer lo que quiera, sin impacto eiter prod ni dev.

Y, si es necesario, puede usar varias máquinas virtuales, si es necesario para estar más cerca de su configuración de producción

Answer 4

Si no tiene hardware específico para Desarrollo, Puesta en escena y Producción, entonces tiene su base de datos de ensayo en Desarrollo SQL Sirve r es una solución común.I

es mucho más seguro que tener su base de datos de etapas en el servidor de producción, tratar de hacer algo con la base de datos de etapas y desmontar el servidor SQL de producción.

Answer 5

Tener una base de datos provisional en el servidor de producción es arriesgado. sin embargo, con etapas de depuración/prueba lo suficientemente intensas, el riesgo real para la producción es mínimo. Esto es especialmente cierto si la carga de puesta en escena es mínima.

Answer 6

Su DB de transferencia nunca debe estar en el mismo servidor que la producción. Diría que está bien tenerlo en el mismo servidor que tu servidor de desarrollo.

son una serie de cosas que podrían salir mal,

La manipulación de datos sobre la equivocada DB

hacer algo que podría en realidad

derribar el servidor. Es posible que necesite

para reiniciar su servidor de bases de datos durante el desarrollo y las pruebas de .

Como regla, no creo que los desarrolladores deban tener acceso al entorno en vivo. Solo las operaciones deben tener acceso.

Answer 7

Como han dicho otros, evitar las entidades que no son de producción en su entorno de producción debe evitarse como la peste. Hay demasiadas posibilidades para que los desarrolladores agreguen o modifiquen erróneamente algo de lo que depende su entorno de producción. Nuestro servidor de producción se modifica solo durante la implementación. Hacemos un seguimiento de cada archivo que se ha modificado y tenemos un mecanismo para revertir los cambios con el mínimo esfuerzo.

Mantenga la puesta en escena en su entorno de desarrollo si no puede obtener hardware dedicado.