Flyway: Por qué tu base de datos necesita control de versiones

El problema sin Flyway

Un dev agrega una columna manualmente en su BD local. Otro hace pull del código y ejecuta la app... error. La columna no existe en su entorno. ¿Familiar?

¿Qué es Flyway?

Flyway gestiona cambios en el schema de BD como commits de Git: versionados, ordenados y reproducibles.

V1__init_schema.sql        → Primera versión
V2__add_user_roles.sql     → Tabla de roles
V3__add_audit_fields.sql   → created_at, updated_at

Configuración en Spring Boot

spring.flyway.enabled=true
spring.flyway.locations=classpath:db/migration
spring.flyway.schemas=ecos  # schema dedicado

-- V1__init_schema.sql
CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    password_hash VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

Buenas prácticas que sigo

Migraciones son inmutables — Flyway verifica checksums. Si modificas un archivo ya ejecutado, Flyway falla a propósito. Es una feature, no un bug.

Nombres descriptivos — V3__add_email_verification_token_to_users.sql es infinitamente mejor que V3__update.sql.

Schema dedicado por servicio — En ECOS usé schema ecos aislado. Crítico en entornos con múltiples servicios compartiendo la misma instancia de BD.

Conclusión

Cuando un nuevo dev entra al equipo, solo necesita clonar el repo y ejecutar la app. Flyway crea toda la estructura automáticamente. Sin scripts manuales, sin inconsistencias. Tu BD merece el mismo rigor que tu código.