BLOG

Viernes, 24 Noviembre 2017 08:40

Control de cambios en las bases de datos

Adolfo Quesquen sentado trabajando con dos monitores

Para el artículo de hoy presentamos a Adolfo Quesquén, DBA Senior en Trans Solutions Systems. Veremos un tema vital para el desarrollo de software. Los cambios en una base de datos pueden ser tediosos y complicados, pero existen algunas herramientas para facilitar y agilizar este proceso. 

En desarrollo de software, el control de cambios en una base de datos es una tarea importante. Lamentablemente, en varios casos controlar los cambios en proyectos medianos o grandes puede ser una tarea laboriosa, manual y repetitiva.

Automatizar este proceso es trascendental para agilizar los procesos y evitar los errores humanos manuales.  En una entrega continua es imprescindible contar con un proceso automático para acelerar el desarrollo.

Llevar los cambios de bases de datos a los distintos ambientes (pruebas, preproducción o producción) es diferente a cómo se entrega el código de una aplicación. En una aplicación, el código se reemplaza totalmente; en cambio, las bases de datos deben conservarlo. La complejidad aumenta si tienes múltiples equipos, proyectos o aplicaciones, que tocan la misma base de datos.

Cuando las bases de datos de algún ambiente (desarrollo, testeo, preproducción, producción, etc.) son copiadas de un entorno a otro, se pueden presentar algunos problemas. Por ejemplo, que se pierda fácilmente el control de los cambios que se han ejecutado en la base de datos.

Si el control de cambios es manual, no se puede tener un proceso de integración continua.

Las herramientas que encontramos para “el control de cambios a bases de datos” las podemos agrupar en dos grupos:

  • Comparar y sincronizar. Cada promoción de cambio compara la base de datos con una foto local que mantiene. Esto es muy complejo, un cambio pequeño implica comparar todo. Está especializada para cada base de datos.
  • Usando scripts de migración. Lleva el control de scripts ejecutados, conectada a un control de versiones. Se crean scripts por cada objeto que existe en la base de datos.

Las dos formas mencionadas anteriormente tienen sus pros y contras. En mi opinión, “Usando scripts de migración” es la mejor opción. Este proceso es más automatizable y menos propenso a errores al momento de ejecutar los scripts.

Ahora, analizaremos a más detalle esta opción. Para llevar el control de cambios a una base de datos hay dos puntos importantes:

1. Llevar el control de los cambios que se han aplicado a una base de datos.

Una forma antigua de controlar los cambios realizados era etiquetar a un grupo de cambios con una versión, para luego, registrarla en una tabla. El problema con esto es que, en caso se necesite realizar algún tipo de cambio al grupo etiquetado, este ya sería diferente. Esta forma generalmente era manual y sujeta a errores humanos.

Actualmente existen utilitarios que llevan el control de los scripts. En general, la forma de llevar el control es contar con una tabla donde se registren los scripts ejecutados en forma cronológica en cada base de datos. El utilitario es el responsable de verificar, ejecutar y registrar.

Dentro de este punto también se debe considerar que los cambios a bases de datos pueden ser modificados. Si los cambios fueron ya ejecutados en un entorno, estos se agrupan en:

A. Script de cambios que no pueden ser modificados una vez ejecutados en algún entorno.

  • Cambios son incrementales.
  • Cambios en estructura de bases de datos.
  • Cambios a tablas

B. Script de cambios que pueden ser modificados sin importar que ya fue ejecutado en algún entorno.

  • No son incrementales, el cambio es total.
  • Cambios al código de bases de datos. En este grupo se encuentran los procedimientos almacenados, funciones.
  • Cambios en vistas.

C. Script de cambios que pueden ser modificados, pero debe contemplar el escenario si el cambio ya fue ejecutado, en algunos casos la mejor opción es crear el cambio incremental al script:

  • Cambios de datos en las tablas. Adición, modificaciones o eliminación en registros de las tablas.
2. Orden de ejecución de los cambios a las bases de datos.

Este es otro punto importante. La forma más sencilla que casi todos los utilitarios utilizan es: ejecutar los scripts de los nombres de los archivos en orden alfabético. Pero existen diferentes órdenes de ejecución, como vemos a continuación: ejecutar los folders en orden alfabético, customizar el orden de ejecución o finalmente se puede utilizar el orden predeterminado.

En una versión, el orden de ejecución de los cambios a las bases de datos puede ser relevante o no.

No es tan relevante, si los cambios se orientan a:

  • Procedimientos almacenado
  • Funciones
  • Vistas

Sí es relevante mantener el mismo orden de ejecución de los scripts en cada uno de los diferentes entornos para:

  • Cambios a tablas
  • Cambios a datos en tablas

Herramientas

 

- Herramienta sencilla y fácil de usar.

- Puede ser utilizada en una amplia lista de bases de datos.

- Para ambientes sencillos es una buena herramienta.

- Para desarrollos complejos le falta funcionalidades.

 

 

- Es una herramienta muy completa y a la vez compleja.

- Puede ser utilizada en una amplia lista de bases de datos.

- Se adapta muy bien para ambientes complejos.

- La principal desventaja es: la forma de realizar los cambios a bases de datos es utilizando una sintaxis desarrollado por ellos. Existe una curva de aprendizaje para utilizarla al inicio. Al usar esta nueva forma de realizar los cambios a bases de datos, la herramienta puede inferir las instrucciones de rollback en casi todos los casos. Los cambios de bases de datos también pueden realizarse utilizando instrucciones SQL. Al hacerlo de esta forma la herramienta no puede inferir las instrucciones de rollback.

 

 

- Es una herramienta relativamente fácil de usar

- Puede ser utilizada en una amplia lista de bases de datos.

- Se adapta muy bien para ambientes complejos.

 

 

Otras herramientas similares

https://dbup.github.io/

https://github.com/jdaigle/Horton

 

Bibliografía

http://enterprisecraftsmanship.com/2015/08/18/state-vs-migration-driven-database-delivery/

http://workingwithdevs.com/delivering-databases-migrations-vs-state/

http://www.h-online.com/developer/features/Continuous-database-migration-with-Liquibase-and-Flyway-1860080.html

https://cimat.repositorioinstitucional.mx/jspui/bitstream/1008/415/1/ZACTE19.pdf

https://www.red-gate.com/simple-talk/sql/t-sql-programming/when-database-source-control-goes-bad/

http://databaserefactoring.com/