En ingeniería de software , una migración de esquema (también migración de base de datos , gestión de cambios de base de datos ) se refiere a la gestión de cambios controlados por versión , incrementales y, a veces, reversibles en esquemas de bases de datos relacionales . Se realiza una migración de esquema en una base de datos siempre que es necesario actualizar o revertir el esquema de esa base de datos a una versión más nueva o más antigua.
Las migraciones se realizan mediante programación utilizando una herramienta de migración de esquemas . Cuando se invoca con una versión de esquema deseada especificada, la herramienta automatiza la aplicación sucesiva o la reversión de una secuencia apropiada de cambios de esquema hasta que llega al estado deseado.
La mayoría de las herramientas de migración de esquemas tienen como objetivo minimizar el impacto de los cambios de esquema en los datos existentes en la base de datos. A pesar de esto, la preservación de los datos en general no está garantizada porque los cambios de esquema, como la eliminación de una columna de la base de datos, pueden destruir los datos (es decir, se eliminan todos los valores almacenados en esa columna para todas las filas de esa tabla). En cambio, las herramientas ayudan a preservar el significado de los datos o a reorganizar los datos existentes para satisfacer nuevos requisitos. Dado que el significado de los datos a menudo no se puede codificar, la configuración de las herramientas suele necesitar intervención manual.
La migración de esquemas permite corregir errores y adaptar los datos a medida que cambian los requisitos. Son una parte esencial de la evolución del software, especialmente en entornos ágiles (ver más abajo).
Aplicar una migración de esquema a una base de datos de producción siempre es un riesgo. Las bases de datos de desarrollo y prueba tienden a ser más pequeñas y limpias. Los datos que contienen se comprenden mejor o, si todo lo demás falla, la cantidad de datos es lo suficientemente pequeña como para que un ser humano pueda procesarla. Las bases de datos de producción suelen ser enormes, antiguas y llenas de sorpresas. Las sorpresas pueden venir de muchas fuentes:
Por estos motivos, el proceso de migración necesita un alto nivel de disciplina, pruebas exhaustivas y una estrategia de respaldo sólida.
En estado estable, una versión de una aplicación sólo comprende una versión de un esquema. Entonces, la estrategia más básica es cerrar la aplicación, ejecutar la migración del esquema y luego iniciar la versión más nueva de la aplicación. Si bien es simple, esta estrategia provoca un tiempo de inactividad . Dependiendo de la criticidad del sistema y sus patrones de uso, se pueden tolerar tiempos de inactividad de diversas duraciones, pero en algunos casos es posible que no se tolere ninguno en absoluto. En esos casos, se puede utilizar una de las siguientes estrategias sin tiempo de inactividad.
Estos son los pasos generales de la lectura dual (también llamada doble lectura):
La lectura dual (también llamada lectura doble) es similar a la escritura dual, con los siguientes pasos:
En este enfoque combinado, la aplicación cambia a lectura y escritura duales. Dado que ambas estrategias individuales garantizan que la base de datos pueda permanecer en línea sin interrupciones, el enfoque combinado también logra lo mismo. Esta estrategia permite un control más detallado sobre el reabastecimiento, que se puede dividir en lotes más pequeños, y se pueden usar indicadores de funciones para alternar las rutas de lectura y escritura de manera más libre y separada entre sí. Esto también puede ser útil cuando no se puede garantizar que la escritura dual regular por sí sola ocurra en transacciones consistentes.
Al desarrollar aplicaciones de software respaldadas por una base de datos, los desarrolladores suelen desarrollar el código fuente de la aplicación junto con un esquema de base de datos en evolución. El código generalmente tiene expectativas rígidas sobre qué columnas, tablas y restricciones están presentes en el esquema de la base de datos cada vez que necesita interactuar con una, por lo que solo la versión del esquema de la base de datos contra la cual se desarrolló el código se considera totalmente compatible con esa versión del código fuente. .
En las pruebas de software , si bien los desarrolladores pueden burlarse de la presencia de un sistema de base de datos compatible para las pruebas unitarias , cualquier nivel de prueba superior a este (por ejemplo, pruebas de integración o pruebas del sistema ) es común que los desarrolladores prueben su aplicación con una base de datos de prueba local o remota. esquemáticamente compatible con la versión del código fuente bajo prueba. En aplicaciones avanzadas, la migración en sí puede estar sujeta a pruebas de migración .
Con la tecnología de migración de esquemas, los modelos de datos ya no necesitan diseñarse completamente por adelantado y son más capaces de adaptarse a los requisitos cambiantes del proyecto a lo largo del ciclo de vida del desarrollo de software .
Los equipos de desarrolladores de software suelen utilizar sistemas de control de versiones para gestionar y colaborar en los cambios realizados en las versiones del código fuente. Diferentes desarrolladores pueden desarrollar ramas divergentes, relativamente antiguas o más nuevas, del mismo código fuente para realizar cambios y adiciones durante el desarrollo.
Suponiendo que el software en desarrollo interactúa con una base de datos, cada versión del código fuente puede asociarse con al menos un esquema de base de datos con el que sea compatible.
Según las buenas prácticas de prueba de software , las migraciones de esquemas se pueden realizar en bases de datos de prueba para garantizar que su esquema sea compatible con el código fuente. Para agilizar este proceso, generalmente se invoca una herramienta de migración de esquemas como parte de una compilación de software automatizada como requisito previo de la fase de prueba automatizada .
Se puede decir que las herramientas de migración de esquemas resuelven problemas de control de versiones para esquemas de bases de datos del mismo modo que los sistemas de control de versiones resuelven problemas de control de versiones para el código fuente. En la práctica, muchas herramientas de migración de esquemas en realidad se basan en una representación textual de los cambios de esquema (como archivos que contienen declaraciones SQL), de modo que el historial de versiones de los cambios de esquema se pueda almacenar de manera efectiva junto con el código fuente del programa dentro de VCS. Este enfoque garantiza que la información necesaria para recuperar un esquema de base de datos compatible para una rama de código particular se pueda recuperar del propio árbol fuente. Otro beneficio de este enfoque es el manejo de cambios de esquema conflictivos simultáneos; los desarrolladores pueden simplemente utilizar sus herramientas habituales de resolución de conflictos basadas en texto para reconciliar las diferencias.
Las herramientas de migración de esquemas podrían verse como una facilidad para rastrear el historial de un esquema en evolución (es decir, evolución del esquema ).
Los desarrolladores ya no necesitan eliminar toda la base de datos de prueba para crear una nueva base de datos de prueba desde cero (por ejemplo, utilizando scripts de creación de esquemas desde herramientas de generación de DDL). Además, si la generación de datos de prueba cuesta mucho tiempo, los desarrolladores pueden evitar regenerar datos de prueba para cambios pequeños y no destructivos en el esquema.