Gerador de migration Flyway a partir de tabela

Flyway migrations: versionamento de banco SQL-first

O Flyway é a ferramenta de migration baseada em Java criada por Axel Fontaine em 2010 e adquirida pela Redgate em 2019. É distribuída em uma edição open-source Apache 2.0 e em camadas comerciais (Teams, Enterprise) que adicionam recursos como migrations de undo e estado centralizado. A filosofia toda cabe em uma frase: uma pasta de arquivos SQL puros, nomeados por versão, executados uma vez e rastreados para sempre.

Apesar das raízes Java, o CLI é um binário autocontido para macOS, Linux e Windows, com integrações para Maven, Gradle, Spring Boot, Docker, GitHub Actions, Jenkins e Bamboo. Suporta mais de 30 bancos, incluindo PostgreSQL, MySQL, Oracle, SQL Server, Snowflake, Redshift e MongoDB Atlas (via JDBC).

Convenção de nomes e tipos de migration

Os nomes de arquivo carregam significado semântico. O Flyway os reconhece automaticamente:

• Versionadas — V1__create_users.sql, V2__add_email_index.sql. Rodam exatamente uma vez, na ordem.
• Undo (comercial) — U2__add_email_index.sql define o rollback para V2.
• Repetíveis — R__update_user_view.sql. Reexecutadas sempre que o checksum do arquivo muda; úteis para views, stored procedures e seed.

Versões seguem semver (V1.0.0__) ou timestamp (V20260529123456__). Escolha uma convenção e mantenha — misturar gera surpresas de ordenação.

Workflow e a tabela de histórico

O Flyway grava cada migration aplicada na flyway_schema_history junto com um checksum. Os comandos principais:

• flyway migrate — aplica migrations versionadas + repetíveis pendentes.
• flyway info — mostra aplicadas vs pendentes vs falhas.
• flyway validate — recalcula checksums e detecta adulteração.
• flyway baseline — marca um banco existente populado em uma versão inicial.
• flyway repair — conserta a tabela de histórico após uma falha ou intervenção manual.

Editar uma migration já commitada após executá-la causa um checksum mismatch no próximo migrate — o Flyway se recusa a continuar. É proposital: garante que o mesmo conjunto de arquivos produz o mesmo banco em qualquer lugar.

CI/CD, Spring Boot e multi-ambiente

O Spring Boot integra automaticamente via spring-boot-starter-flyway: coloque os arquivos SQL em src/main/resources/db/migration e o framework executa no startup. No CI, rode flyway migrate após o deploy em staging e produção, parametrizando a URL JDBC por ambiente. Callbacks (beforeMigrate, afterMigrate) permitem hooks Java ou SQL em torno da execução.

Flyway vs Liquibase vs Knex

• Flyway: SQL-first, simples, centrado no JVM. Melhor quando o time já escreve SQL específico do dialeto.
• Liquibase: changesets em XML/YAML/JSON abstraídos do dialeto — mais portável, mais verboso.
• Knex: amarrado a JavaScript, encaixa naturalmente em stacks Node.js mas não é a melhor escolha para um time Java ou poliglota.

FAQ

Posso editar uma migration depois de aplicada? Não — o checksum bate diferente e o Flyway se recusa a rodar. Adicione um novo arquivo versionado com a correção.

Como fazer rollback? A versão open-source não tem rollback. Escreva uma migration corretiva forward-only ou compre a edição comercial para arquivos U (undo).

Flyway é melhor para times Java? Sim — plugins Maven/Gradle, autoconfig do Spring Boot e drivers JDBC tornam a integração trivial. Em Node funciona, mas parece estranho.

Posso misturar linguagens? As migrations em si são SQL (ou callbacks Java). O CLI é agnóstico, então um app Python ou Node pode chamar via shell.

E se uma migration falhar no meio? A transação é revertida (em bancos que suportam DDL transacional). Rode flyway repair para limpar a tabela de histórico, corrija o SQL e execute migrate novamente.