patrones de migración de datos de producción en entrega continua

Question

¿Qué son los patrones de migración de la base de datos relacional (y el esquema) en la producción en entrega continua?

En muchos desarrollos tradicionales, el DBA organiza una secuencia de comandos de migración grande de los muchos scripts más pequeños creados en el ciclo de publicación actual. Pero en CD el desarrollador puede querer impulsar el cambio ahora a la producción, no esperar a compilarlos con otros scripts.

Lo sé en rails-migration pero a mí me parece más razonable usar scripts sql sin formato.

También he visto herramientas como flyway para gestionar las migraciones, pero no he leído a muchas personas que las usan en producción. Es por eso que me pregunto cuáles son las prácticas comunes aquí.

Answer 1

Flyway funciona muy bien para la entrega/implementación continua. Muchos clientes lo usan en todos los entornos, incluida la producción.

Lo más importante para las migraciones en cascada a través de entornos de base de datos es tener un proceso de 3 pasos:

Paso 1

código de la aplicación Antiguo trabaja en conjunto con el viejo DB.

Paso 2

nuevo código de la aplicación se despliegan, y migra DB en el arranque. Esta migración debe ser compatible con versiones anteriores, de modo que el código de la aplicación anterior aún funcione con la nueva base de datos. Esto es esencial porque:

• a continuación, puede hacer las actualizaciones sucesivas, la actualización de un nodo a la vez hasta que todos los nodos tienen el nuevo código de la aplicación
• reversión inmediatamente al código de la aplicación de edad si el nuevo se rompe

Este paso puede implicar vistas de compatibilidad y activadores para hacer el trabajo.

Paso 3

Después de que los cambios han sido probados para trabajar, la próxima versión del código de aplicación se pone desplegado junto con las migraciones DB necesarias para descartar cualquier remanente obsoleto (de la etapa 1) y la compatibilidad (del paso 2) estructuras.

Answer 2

Implemente los cambios en su base de datos como archivos sql únicos (sin formato), luego use sqlpatch para compilar un script de migración.

Normalmente tengo un único repositorio git para la base de datos solo y un entorno de cd adjunto. Normalmente tengo una base de datos de producción y de desarrollo que se migran automáticamente cuando presiono las ramas correspondientes.

Esta configuración hace que sea muy fácil configurar otra base de datos para una rama de características y experimentar con ella. Sqlpatch se encarga de todas las dependencias en los archivos sql separados para que pueda fusionar fácilmente una rama de características en otra rama.