Actualmente existen proyectos donde, por ejemplo, al querer agregar una columna a una tabla o agregar un índice de búsqueda, se aplican scripts manuales y puede haber o no un registro de ello. En estos casos pueden surgir algunas dudas con respecto al estado de la base de datos, por ejemplo, cómo sé si un script ya fue ejecutado, en qué ambientes se aplicó (dev, qa, prod), etc. Para estos casos, podemos utilizar la herramienta Flyway.

Flyway es un sistema robusto open-source de migración de base de datos fácil y sencilla de usar. Se puede utilizar desde línea de comandos, desde su API Java, o desde Maven y Graddle. Además, ofrece Plugins para herramientas como Spring Boot y otras. Soporta un gran número de bases de datos, y toda su funcionalidad está basada en 6 comandos básicos: Migrate, Clean, Info, Validate, Undo y Baseline and Repair.

En este artículo sólo vamos a ver el uso del comando Migrate basada en SQL y para usar en Spring Boot. Para Flyway, cualquier cambio en la base de datos es una migración, por lo tanto, nos va a ayudar a seguir una trazabilidad de qué scripts ya se han ejecutado, cuándo y quién lo hizo. 

A tener en cuenta:

1. Agregamos la dependencia en maven para usar base de datos MySQL:
   

   <dependency>
      <groupId>org.flywaydb</groupId>
      <artifactId>flyway-mysql</artifactId>
   </dependency>       
   

2. Los scripts se deben colocar en la carpeta que se le ha indicado como “source”, (por defecto es classpath:db/migration).
3. Para saber en qué estado está la base de datos, Flyway se basa en una tabla de metadatos llamada flyway_schema_history que se crea automáticamente.
4. Para que Flyway pueda procesar los scripts es muy importante nombrarlos adecuadamente con V{número}__{nombre}.sql, por ejemplo: V1.0__create_tables.sql
5. Las migraciones están ordenadas basadas en su número de versión, y ese es el orden en el cual serán aplicadas. Si encuentra una migración cuyo número de versión es menor o igual al que está indicado como actual en la tabla flyway_schema_history, simplemente la ignora y las restantes son las migraciones pendientes: disponibles, pero no aplicadas. 

 

Ejemplo de la carpeta por defecto para guardar los scripts:

 

Cuando levantamos por primera vez la aplicación, por defecto se realiza la validación de los scripts de migración y posteriormente se procede a la migración de forma automática. Veamos un ejemplo del log que deja la aplicación al migrar con éxito, en este caso hemos versionado tres scripts donde se crean tres tablas. 

 

 

Tras migrar los tres scripts a la base de datos, Flyway ha creado la tabla flyway_schema_history con meta-información de los scripts ya migrados y guarda su checksum⁽¹⁾ para que no pueda ser modificado. Ejemplo:

 

 

Cada vez que levantamos la aplicación, Flyway hará una de estas dos cosas:

• Si no existe la tabla, la creará y migrará todo lo que encuentre en la carpeta que le indicamos en la configuración spring.flyway.locations, que por defecto dijimos que es classpath:db/migration.
• En caso de existir la tabla, comprobará la versión de scripts aplicados con respecto a los que migramos desde la aplicación y validará que el checksum coincida. Si la base de datos está desactualizada, procederá a migrar lo que le falte.

 

Posibles errores con Flyway:

Cuando intentamos desplegar nuestro proyecto podemos encontrarnos con algunos errores, por ejemplo:

• Wrong migration name format: Esto nos indica que el nombre que hemos indicado es incorrecto, ten en cuenta que tiene que ser V{número}__{nombre}.sql.
• Flyway migration failed: Este es sin duda uno de los errores más comunes que nos podemos encontrar cuando hacemos uso de Flyway. Dicho error se refiere a cuando un archivo anterior ha sido modificado, entonces el checksum que Flyway genera detectará el cambio y dará error, para evitar este error debemos evitar cambiar archivos antiguos y generar nuevos ante cualquier cambio.

 

Conclusión:

Hemos visto un pequeño resumen de la utilización de esta herramienta para gestionar y automatizar la migración sobre la base de datos, pero Flyway es muy potente y tiene más funcionalidades.

Además, Flyway permite diferentes formas tanto de configuración como de uso y todo dependerá de nuestro caso personal enfocado a nuestro proyecto. Es por ello que Flyway es de las opciones más elegidas cuando hablamos de migraciones de bases de datos, ya que es fácil de usar, ofrece diferentes enfoques y tiene detrás una documentación amplia.

 

⁽¹⁾Checksum: Una suma de verificación o checksum, también conocida como suma de chequeo, es una función matemática de redundancia cuyo principal objetivo es el de detectar cambios malintencionados o accidentales en una transmisión de datos con el fin de proteger la integridad de la información. Por medio de los algoritmos de verificación se puede asegurar que no existan diferencias entre los valores que se obtienen al principio y al final de una transmisión de datos.

 

Foto de benjamin lehman en Unsplash