estadificación situación de base de datos

Question

Supongamos que hay 3 bases de datos para

• Producción
• Staging
• Dev

Por lo que yo sé, Puesta en la base de datos deben estar en sintonía con la base de datos de producción Pero,

Cuando estamos desarrollando, podemos hacer lo que queramos con wi th Dev base de datos y esquema de cambio. Ahora aquí viene el Chicken & Egg problem.

Para probar en etapas, El esquema de base de datos de etapas debe cambiarse de acuerdo con los cambios realizados en la base de datos Dev. Pero la base de datos de etapas debe estar sincronizada con Producción.

¿Cómo pueden solucionar este problema?

Answer 1

La organización por etapas debe sincronizarse con la producción, solo hasta el punto en el que está implementando cambios nuevos.

Eso o crea un cuarto entorno llamado Prueba donde se validan las nuevas actualizaciones. Llamamos a nuestro UAT/Test, y generalmente es una segunda base de datos en el servidor de Staging.

La metodología exacta dependerá de cómo se mantienen las cosas sincronizadas. ¿Estás realmente usando la replicación? ¿O solo una copia de seguridad/restauración de Prod to Stage?

Answer 2

"La base de datos de etapas debe estar sincronizada con la producción" No es cierto.

El Esquema de producción ("diseño") está sincronizado con el Esquema de etapas. La puesta en escena es lo primero, la producción sigue.

A veces las personas cambian los datos de producción a etapas para ayudar a probar, pero eso puede ser peligroso, dependiendo de la industria.

La clasificación es "pura".

La producción se construye a partir de la puesta en escena poniendo datos reales en el esquema de etapas puro.

Lo que algunas personas hacen es tener dos bases de datos.

Hoy # 1 es producción, # 2 es puesta en escena.

Mañana tenemos la intención de hacer un cambio en el esquema. Actualizamos el # 2 al nuevo diseño. Luego movemos los datos de # 1 a # 2.

Luego, cuando terminemos de mover los datos, cambiamos el software de la aplicación para usar el # 2 como producción.

Funcionamos con el n. ° 2 como producción hasta que llegue la hora del próximo cambio.

Answer 3

Usamos nuestra base de datos provisional solo para probar nuestro mecanismo de implementación. Coincide con la producción.

Creamos nuestros cambios en el desarrollo y los implementamos periódicamente en el control de calidad. Una vez que estamos listos para comenzar la producción, agregamos todos los cambios en un paquete de lanzamiento.Ese paquete de lanzamiento se prueba por primera vez en etapas, y luego, si no hay problemas de despliegue, se envía a producción.

Answer 4

Si puede permitirse agregar un entorno de prueba, es posible que desee considerarlo.

De lo contrario, básicamente tiene que hacer sus pruebas en su entorno de desarrollo. hasta un punto en el que tenga suficiente confianza con el lanzamiento como para hacer que el esquema cambie en su entorno de transición. Realice copias de seguridad frecuentes y tenga un buen procedimiento de reversión, de modo que si algo sale mal cuando inserta los cambios de esquema en etapas, siempre puede retroceder.

Además, una buena herramienta para comparar el esquema de la base de datos es SqlCompare. Debe usar algo como esto siempre antes de presionar los cambios de esquema.

Answer 5

Debe escribir todos los cambios en la base de datos de desarrollo como scripts de migración de SQL que se ejecutan en un orden determinado. No cambie la estructura de la base de datos a menos que esté en una secuencia de comandos. No actualice, inserte ni elimine ninguna fila a menos que esté en una secuencia de comandos.

Lo ideal es que tenga una manera de rastrear qué secuencias de comandos se han ejecutado contra cualquier versión de la base de datos que encuentre.

Luego puede actualizar el escenario de la siguiente manera.

• la producción de base de datos de volcado de la base de datos
• etapa Rellenar con la producción de volcado
• migraciones funcionará como etapa
• Comprobar la migración trabajó (pruebas unitarias, controles manuales)

Una vez que todo funciona ...

• Dump prod database with mysql volcado de comandos (ya que puede haber cambiado) mantener copia de seguridad en el servidor
• migraciones se ejecutan en prod
• migración de prueba ha trabajado en prod
• cerveza bebida (mientras ve los registros de errores)