database - proceso - Situación de la base de datos en etapas
staging area git (5)
Supongamos que hay 3 bases de datos para
- Producción
- Puesta en escena
- Dev
Por lo que yo sé, la base de datos de etapas debe estar sincronizada con la base de datos de producción.
Cuando estamos desarrollando, podemos hacer lo que queramos con la base de datos Dev y cambiar el esquema. Ahora viene el problema Chicken & Egg.
Para probar en etapas, el esquema de base de datos de etapas debe modificarse 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 resolver este problema?
"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.
En ocasiones, las personas cambian los datos de producción a etapas para ayudar a evaluar, pero eso puede ser peligroso, dependiendo de su industria.
La estadificación es "pura".
La producción se construye a partir de la puesta en escena al poner 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 planeamos 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.
Corremos con el # 2 como producción hasta que llegue el momento del próximo cambio.
La organización por etapas tiene que estar sincronizada con la producción, solo hasta el punto en que está implementando nuevos cambios.
Eso o crear un cuarto entorno llamado Test 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?
Necesita escribir todos los cambios en la base de datos de desarrollo como scripts de migración 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 tener una forma 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.
- Bases de datos de producción volcada
- Rellenar base de datos de escenario con volcado de producción
- Ejecuta migraciones en el escenario
- Comprobar migración trabajada (pruebas unitarias, verificaciones manuales)
Una vez que todo funciona ...
- Dump prod base de datos con el comando mysqldump (como puede haber cambiado) manteniendo la copia de seguridad en el servidor
- Ejecuta migraciones en prod
- La migración de prueba ha funcionado en prod
- Beber cerveza (mientras mira los registros de errores)
Si puede permitirse agregar un entorno de prueba, es posible que desee considerarlo.
De lo contrario, básicamente necesitas hacer tus pruebas en tu entorno de desarrollo. hasta un punto en el que tenga la 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 . Debería usar algo como esto siempre antes de presionar los cambios de esquema.
Usamos nuestra base de datos de etapas 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.