development and database production staging

database - development testing and production environments



Buenas prácticas de base de datos de ensayo (2)

Como alguien que desarrolla una tool software que ayuda en cada paso del proceso de implementación, puedo decir que la mejor práctica cuando se trata de entornos de prueba es reflejar exactamente su entorno de producción. Esto incluye un esquema de base de datos idéntico (los datos no son relevantes, la copia de seguridad / actualización ocasionalmente está bien), la misma versión del sistema operativo, paquetes de servicio actualizados, configuración del servidor web, etc.

En un mundo ideal, las pruebas funcionales o de aceptación del usuario no tienen que realizarse en el almacenamiento provisional, ya que el propósito de un entorno de ensayo es solo probar su implementación en producción. Sin embargo, en el mundo práctico, a veces es aceptable que su entorno de prueba sea también su entorno funcional o de prueba de UA.

Cada vez que cambie una configuración o modifique la configuración en su servidor de producción, deberá cambiar la configuración en el servidor de prueba, esto asegurará que, si puede implementar su aplicación en la puesta en escena, se implementará sin problemas en la producción.

Estoy a punto de desplegar en producción un sitio bastante complejo y por primera vez necesito un entorno de prueba donde pueda probar cosas en un entorno más realista, especialmente con respecto a algunos servicios externos que no se pueden ejecutar localmente.

Mi plan general es desarrollar y probar primero localmente, empujar cambios simples (pequeñas correcciones de errores, HTML / CSS, JS, etc.) directamente a la producción, y para cambios más grandes, empujar primero al subdominio de pruebas para realizar pruebas exhaustivas y luego a producción.

No creo que deba mantener las bases de datos de ensayo y producción sincronizadas (la actualización manual ocasional sería suficiente), pero me pregunto si existen buenas prácticas generales con respecto al mantenimiento de un entorno de almacenamiento en relación con un entorno de producción. Especialmente cuando se trata de bases de datos.

Cualquier pensamiento / consejo / experiencia general sería apreciado.

ACTUALIZAR:

Gracias por los comentarios, recibo la esencia. Supongo que vale la pena tomarse un tiempo para pensar en esto. Aceptada la respuesta popular.


Pasar por alto la puesta en escena y hacer cambios en la producción es una receta para el desastre y la desuso. Mientras haces esos cambios, la definición de menor comienza a cambiar. En segundo lugar, a medida que salen los dos entornos (es decir, la puesta en escena ya no coincide con la producción), las cosas se rompen y se pierde confianza en el entorno de la puesta en escena. Para aprovechar al máximo un servidor de pruebas, debe realizar implementaciones automatizadas, realizar pruebas completas y, luego, implementarlas (automatizadas) en producción (sin importar cuán pequeño sea el cambio). También debes asegurarte de que el entorno completo sea lo más similar posible y seguir así. Esto obviamente incluye el DB. Normalmente, configuro una sincronización diaria o por hora (dependiendo de la frecuencia con la que estoy creando el sitio o la aplicación) para mantener la base de datos, y con frecuencia lo ejecuto como parte del proceso de compilación.