Saltar al contenido principal

Migraciones con Flyway

Cuando varias personas (o varios entornos: tu máquina, CI, producción) comparten una base de datos, necesitas una forma reproducible de crear y evolucionar su esquema. Flyway resuelve esto con migraciones: archivos SQL versionados que se aplican en orden, una sola vez cada uno.

Convención de nombres​

Flyway busca migraciones en src/main/resources/db/migration/ con el patrón V<versión>__<descripción>.sql (dos guiones bajos entre versión y descripción):

src/main/resources/db/migration/
└── V1__create_tasks_table.sql

La primera migración​

CREATE TABLE tasks (
    id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    titulo VARCHAR(255) NOT NULL,
    descripcion VARCHAR(1000),
    completada BOOLEAN NOT NULL DEFAULT FALSE
);

SQL estándar: crea la tabla tasks con las mismas columnas que la entidad Task (ver Spring Data JPA) va a mapear.

Cuándo se ejecutan​

Flyway se ejecuta automáticamente al arrancar la aplicación (spring.flyway.enabled: true, activado por defecto en cuanto añades la dependencia). Comprueba qué migraciones ya se aplicaron (las registra en una tabla propia, flyway_schema_history) y aplica solo las nuevas, en orden por número de versión.

Por qué esto importa más que "simplemente crear la tabla a mano"​

  • El esquema queda versionado junto al código, en git — puedes ver exactamente cómo evolucionó.
  • Cualquier persona que clone el repo y arranque la aplicación obtiene el mismo esquema, sin pasos manuales.
  • Los tests de este ejemplo ejecutan esta misma migración contra una base de datos H2 en memoria (ver Probar la app con datos reales) — así que cada vez que corres ./mvnw test, también estás comprobando que la migración es válida.

Cuando en el futuro necesites cambiar el esquema (añadir una columna, por ejemplo), no modificas V1__create_tasks_table.sql — añades V2__<algo>.sql con el cambio. Las migraciones ya aplicadas no se tocan nunca.