Type something to search...
Gestión de Migraciones de Base de Datos con Flyway en Spring Boot"

Gestión de Migraciones de Base de Datos con Flyway en Spring Boot"

Introducción

El desarrollo de aplicaciones modernas no solo implica escribir código de negocio, sino también gestionar la evolución de la base de datos. A medida que un proyecto crece, mantener la coherencia del esquema entre desarrolladores, ramas y entornos puede volverse complejo.

Aquí es donde Flyway entra en juego: una herramienta de migración de base de datos ligera y poderosa que permite controlar versiones de esquemas de forma segura, repetible y automatizada.

¿Qué es Flyway?

Flyway es una herramienta de migración de base de datos que permite aplicar scripts de manera controlada y automática. Utiliza una convención de nombres para identificar versiones y aplica cambios incrementales cada vez que la aplicación se inicia.

Problemas que resuelve:

  • Desincronización entre esquemas de desarrollo, prueba y producción.
  • Cambios accidentales o no versionados.
  • Dificultad para aplicar migraciones en equipo o CI/CD.
  • Fragilidad de los esquemas generados automáticamente por JPA.

Comparación breve con alternativas:

HerramientaLenguajeComunidadSQL puroMigraciones Java
FlywayJavaMuy activa✅ Sí✅ Opcional
LiquibaseJavaActiva✅ Sí✅ Más flexible

¿Cuándo usar Flyway?

Escenarios ideales:

  • Proyectos con evolución frecuente del esquema.
  • Equipos distribuidos o con múltiples entornos (dev, test, prod).
  • Necesidad de auditoría o trazabilidad de cambios en el esquema.

Ventajas sobre auto-DDL de JPA (spring.jpa.hibernate.ddl-auto):

  • Evita sobrescritura accidental de datos.
  • Versionado explícito de cambios.
  • Mayor control y trazabilidad de la evolución del esquema.

Implementación en Spring Boot

Requisitos previos:

Agrega las siguientes dependencias en tu archivo pom.xml:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
    </dependency>
    <dependency>
        <groupId>org.flywaydb</groupId>
        <artifactId>flyway-core</artifactId>
    </dependency>
</dependencies>

Para Gradle: implementation 'org.flywaydb:flyway-core'

Configuración básica (application.properties):

spring.datasource.url=jdbc:h2:mem:testdb
spring.datasource.username=sa
spring.datasource.password=
spring.datasource.driver-class-name=org.h2.Driver

spring.jpa.hibernate.ddl-auto=none

spring.flyway.enabled=true
spring.flyway.locations=classpath:db/migration

Ejemplo Práctico: Proyecto de Gestión de Usuarios

Supongamos una aplicación con una tabla users. Vamos a construir el esquema paso a paso usando Flyway.

Estructura del proyecto:

src/
 └── main/
     └── resources/
         └── db/
             └── migration/
                 ├── V1__Create_user_table.sql
                 └── V2__Add_user_role_column.sql

Primera Iteración – Crear tabla users

Archivo: V1__Create_user_table.sql

CREATE TABLE users (
    id BIGINT PRIMARY KEY,
    username VARCHAR(50) NOT NULL,
    email VARCHAR(100) UNIQUE
);

✅ Al iniciar la aplicación, Flyway detecta este archivo y lo ejecuta. Marca la versión como aplicada en su propia tabla de control (flyway_schema_history).

Segunda Iteración – Agregar columna role

Archivo: V2__Add_user_role_column.sql

ALTER TABLE users ADD COLUMN role VARCHAR(20) DEFAULT 'USER';

✅ Flyway identifica que esta versión aún no ha sido aplicada, la ejecuta y actualiza su historial. No vuelve a aplicar la versión 1.

Visualización del Estado de la Base de Datos Tras las Migraciones

Después de ejecutar las dos migraciones (V1 y V2), Flyway deja una huella en la base de datos que te permite auditar el estado de los cambios.

Tablas creadas tras las migraciones:

1. Tabla de usuarios (users):

SELECT * FROM users;

Estructura:

ColumnaTipoRestricciones
idBIGINTPRIMARY KEY
usernameVARCHAR(50)NOT NULL
emailVARCHAR(100)UNIQUE
roleVARCHAR(20)DEFAULT ‘USER’

2. Tabla de control de Flyway (flyway_schema_history):

SELECT * FROM flyway_schema_history;

Ejemplo de contenido:

installed_rankversiondescriptiontypescriptsuccess
11Create user tableSQLV1__Create_user_table.sqltrue
22Add user role columnSQLV2__Add_user_role_column.sqltrue

Migraciones Java-based

Aunque Flyway trabaja perfectamente con scripts SQL, en algunos casos puede ser útil definir migraciones programáticamente en Java. Esto es útil cuando:

  • Necesitas lógica condicional o control de flujo.
  • Quieres reutilizar servicios de Spring.
  • Trabajas con bases de datos no relacionales o lógicas avanzadas.

Cómo crear una migración Java:

  1. Implementa la clase extendiendo BaseJavaMigration.
  2. Ubícala en el paquete db.migration o configura la ubicación.
  3. Nómbrala con el patrón V{n}__Descripción.

Ejemplo: Crear tabla de auditoría

package db.migration;

import org.flywaydb.core.api.migration.BaseJavaMigration;
import org.flywaydb.core.api.migration.Context;

import java.sql.Statement;

public class V3__Create_audit_table extends BaseJavaMigration {
    @Override
    public void migrate(Context context) throws Exception {
        try (Statement stmt = context.getConnection().createStatement()) {
            stmt.execute("""
                CREATE TABLE audit (
                    id BIGINT PRIMARY KEY AUTO_INCREMENT,
                    action VARCHAR(100),
                    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
                );
            """);
        }
    }
}

Configuración adicional si se cambia la ubicación:

spring.flyway.locations=classpath:db/migration
spring.flyway.java-migrations-location=com.ejemplo.migraciones

Tabla Resumen

ConceptoDescripción
MigracionesArchivos SQL con prefijo V{n}__ que modifican el esquema.
Integración con SpringEjecuta automáticamente migraciones al iniciar la app.
Ubicación por defectoclasspath:db/migration
Uso recomendadoProyectos con cambios frecuentes en el esquema y colaboración en equipo.

Conclusión

Flyway no solo gestiona migraciones de manera declarativa (con SQL), sino que también ofrece una vía programática potente para casos avanzados. Su integración con Spring Boot hace que los cambios de esquema sean seguros, trazables y consistentes.

Recomendaciones Finales:

  • Nunca modifiques un script ya aplicado.
  • Usa migraciones Java cuando lo SQL no sea suficiente.
  • Verifica la tabla flyway_schema_history para diagnosticar errores o validar versiones.

Referencias

Related Posts

¿SQL o NoSQL? Descubre la Base de Datos Ideal para tu Proyecto

¿SQL o NoSQL? Descubre la Base de Datos Ideal para tu Proyecto

Introducción Elegir la base de datos adecuada para un proyecto es una decisión crítica que afecta la escalabilidad, el rendimiento y la facilidad de mantenimiento de una aplicación. ¿Necesitas una

Leer más
Explorando las Bases de Datos NoSQL: Introducción a MongoDB

Explorando las Bases de Datos NoSQL: Introducción a MongoDB

📚 Introducción En un mundo donde el volumen y la variedad de los datos crecen exponencialmente, las bases de datos NoSQL se han convertido en una alternativa esencial frente a las tradicionales

Leer más
Guía Rápida de Comandos y Cláusulas SQL

Guía Rápida de Comandos y Cláusulas SQL

SQL (Structured Query Language) es el lenguaje estándar para gestionar y manipular bases de datos relacionales. A continuación, encontrarás una guía rápida con los comandos y cláusulas más utilizados,

Leer más
Optimizando el Acceso a Datos: La Importancia de las Proyecciones JPA en Spring Boot

Optimizando el Acceso a Datos: La Importancia de las Proyecciones JPA en Spring Boot

El Costo Oculto de Traer Demasiada Información En el desarrollo de aplicaciones que interactúan con bases de datos, una tarea fundamental es la recuperación de datos. Al usar Object-Relational Map

Leer más
Relaciones en Bases de Datos NoSQL: ¿Embeber o Referenciar? Una Guía Técnica para la Toma de Decisiones

Relaciones en Bases de Datos NoSQL: ¿Embeber o Referenciar? Una Guía Técnica para la Toma de Decisiones

El auge de las bases de datos NoSQL ha redefinido la manera en que abordamos el modelado de datos, ofreciendo flexibilidad y escalabilidad que a menudo superan las limitaciones de los modelos relacion

Leer más
Tablas Normalizadas vs. JSON/JSONB en PostgreSQL

Tablas Normalizadas vs. JSON/JSONB en PostgreSQL

En el diseño de bases de datos, la normalización ha sido durante mucho tiempo sinónimo de integridad, eficiencia y orden. Sin embargo, los tiempos cambian, y con ellos, las necesidades de los sistemas

Leer más
Descubre el Poder del SemVer: Optimiza el Versionado de tu Software y Mantén un CHANGELOG Excepcional

Descubre el Poder del SemVer: Optimiza el Versionado de tu Software y Mantén un CHANGELOG Excepcional

El Versionado Semántico (SemVer) es una herramienta fundamental para comunicar de forma precisa los cambios en el software, facilitando el mantenimiento y la colaboración. Complementarlo con un **

Leer más