Lakebase e SDLC Agêntico: Ramificação de bancos de dados para agentes de codificação

A IA mudou a forma como o software é construído. À medida que os agentes de codificação assumem uma parcela crescente do trabalho de desenvolvimento, os desenvolvedores estão migrando cada vez mais para a orquestração deles. Executar vários agentes em paralelo está se tornando o padrão, e as ferramentas evoluíram junto, de skills e hooks a MCPs e subagentes, tudo projetado para tornar os agentes mais seguros e eficazes.

No entanto, uma parte essencial do fluxo de trabalho de desenvolvimento ainda é frequentemente esquecida: o banco de dados.

Cada agente concorrente precisa escrever código, aplicar alterações de esquema e executar testes em um banco de dados. Com ambientes compartilhados, como um único banco de dados de desenvolvimento ou staging típico de configurações tradicionais, isso gera desafios reais. Os agentes podem entrar em conflito ao alterar esquemas, interferir uns nos outros ou recorrer a mocks que não refletem dados do mundo real. Esses já eram pontos de dor para os desenvolvedores, mas são exacerbados pelos agentes de codificação. Os agentes operam com mais rapidez, funcionam em paralelo e precisam de um ambiente seguro para evitar colocar em risco os dados de produção ou expor dados confidenciais.

A arquitetura do Lakebase Postgres resolve isso com a ramificação de banco de dados. Assim como o Git permite criar branches de código, o Lakebase permite criar branches de um banco de dados inteiro em menos de um segundo, independentemente do seu tamanho. Ele usa copy-on-write, portanto os branches compartilham os dados do branch pai, mas consomem armazenamento adicional apenas à medida que divergem. Além disso, eles podem escalar até zero (scale-to-zero), o que significa que branches ociosos não geram custos de computação. Isso é importante ao executar vários agentes ao mesmo tempo. Cada branch é totalmente isolado, permitindo que um agente aplique migrações, execute testes e desative o branch quando terminar.

Neste artigo, mostrarei como isso funciona na prática com um fluxo de trabalho de ponta a ponta para um loop de desenvolvimento do Lakebase estruturado em torno de agentes de codificação. Um repositório de exemplo está disponível aqui com exemplos de fluxos de trabalho do GitHub Actions para realizar o que é descrito nas seções a seguir.

Prefere ver isso em ação? Assista ao vídeo explicativo abaixo.

Antes de começarmos, uma observação sobre ambientes no Databricks. Uma configuração comum ao usar o Lakebase Postgres é usar um workspace do Databricks por ambiente, como dev, staging e prod. A maioria das equipes vai querer aproveitar os workspaces por vários motivos, como segurança e conformidade, embora também seja possível usar um único workspace. Da mesma forma, criar um branch a partir de um banco de dados povoado (seeded) em vez do banco de dados de produção também é comum, para evitar expor dados confidenciais como PII. Neste artigo, usaremos um único workspace para simplificar, mas os mesmos conceitos fundamentais se aplicam a configurações com vários workspaces e podem ser implementados com a mesma facilidade.

Bancos de dados seguros e isolados para agentes de codificação paralelos

A principal disrupção nos bancos de dados tradicionais vem do trabalho concorrente de vários agentes de codificação. Ao desenvolver novos recursos ou corrigir problemas, cada agente geralmente precisa ler o esquema do banco de dados, aplicar alterações, povoar dados e executar testes. Sem isolamento, esses agentes podem interferir uns com os outros ou corromper um banco de dados compartilhado. A ramificação de banco de dados fornece a cada agente um ambiente isolado para trabalhar de forma independente sem afetar outros agentes em execução ao mesmo tempo.

Uma maneira prática de evitar conflitos de código localmente é aproveitar os worktrees do Git. Um worktree fornece a cada agente seu próprio diretório com seu próprio branch verificado, garantindo que não haja conflitos no nível do arquivo entre eles. Os worktrees do Git resolvem o isolamento de código para agentes paralelos. A ramificação do Lakebase resolve a outra metade: o isolamento do banco de dados. Ao adicionar um hook post-checkout ao repositório, cada novo worktree obtém automaticamente seu próprio branch de banco de dados. Assim que o desenvolvimento estiver concluído, o agente abrirá um PR. O comportamento do agente pode ser guiado por meio de arquivos de instrução do repositório, como AGENTS.md ou CLAUDE.md.

Aqui está um exemplo de fluxo de trabalho usando Claude Code, worktrees e ramificação do Lakebase para um desenvolvimento seguro com IA:

• O agente executa claude -worktree feature-123
• O Git cria um worktree para o branch feature-123
• Um hook post-checkout é disparado automaticamente, criando um branch de banco de dados
• O agente agora tem seu próprio diretório de código e seu próprio banco de dados totalmente isolado

Quando o agente terminar, ele criará um PR. Esse comportamento é fornecido no arquivo de instrução do repositório. Depois que o PR for criado, tanto o worktree quanto o branch do banco de dados poderão ser desativados. Uma diferença importante em relação ao Git é que os branches do Lakebase não são mesclados de volta para o branch principal. Como o pai e o filho podem mudar independentemente, reconciliar seus dados pode se tornar impraticável rapidamente. Em vez disso, as alterações de esquema são rastreadas no código junto com a lógica da aplicação e, em seguida, promovidas para o branch pai por meio de migrações usando ferramentas como Drizzle, Flyway, Liquibase ou Alembic.

Em nosso exemplo, usamos o Drizzle. Quando uma alteração de esquema é necessária, o agente adiciona a migração correspondente à base de código. A automação de implantação aplica essa migração ao implantar a aplicação de pré-visualização e novamente quando a alteração é mesclada no branch principal.

Bancos de dados efêmeros para cada Pull Request

Assim que um Pull Request (PR) é aberto, queremos validar e testar automaticamente o código em um banco de dados real antes que qualquer coisa chegue à produção.

Usando ferramentas de integração contínua, neste caso, o GitHub Actions, um branch efêmero do Lakebase é criado para cada PR, como um filho do branch de produção. Esse branch se torna o ambiente de banco de dados para o PR. Testes automatizados podem ser executados nele, uma aplicação de pré-visualização pode ser implantada e os revisores podem validar a alteração em relação a um banco de dados real.

Como o branch começa a partir da produção, a migração de esquema também pode ser aplicada e testada antes que a alteração chegue à produção.

Assim que o PR for aprovado e mesclado, o código do recurso e as instruções de migração serão promovidos, e o branch temporário do Lakebase será excluído.

Um fluxo de trabalho comum do GitHub Actions se parece com isto:

• Um PR é aberto em relação ao main
• A CI chama a CLI do Lakebase para criar um branch como pr-123
• A ferramenta de migração (Drizzle, Alembic, etc.) é executada no novo branch de banco de dados dedicado
• Um app de pré-visualização é implantado, apontado para a string de conexão do branch
• Um diff de esquema é gerado e postado como um comentário no PR, mostrando exatamente quais tabelas, colunas ou índices mudaram
• O revisor valida tanto o código quanto as alterações do banco de dados
• Quando o PR é fechado ou mesclado, a CI exclui o branch

No exemplo do repositório, implantamos a aplicação com o Databricks Apps, mas o conceito se aplica a qualquer outra plataforma de hospedagem como Vercel, Netlify, Cloudflare e mais.

Reprodução de bugs, migrações e testes com branches de banco de dados

Além das tarefas de desenvolvimento, o branching de banco de dados pode dar suporte a vários outros fluxos de trabalho úteis. Eles não estão implementados no repositório de exemplo, mas podem ser adições valiosas a um fluxo de trabalho de desenvolvimento do Lakebase. Por exemplo, com o branching de banco de dados, você pode criar uma branch isolada da produção em um determinado momento, normalmente logo antes de um bug aparecer, e investigar o problema com dados reais, reproduzir o bug com segurança e descartar a branch assim que a correção for validada.

O branching também pode tornar as migrações de esquema mais seguras. Antes de implantar uma alteração em produção, você pode criar automaticamente uma branch de banco de dados, aplicar a migração, executar testes e verificar se a aplicação continua funcionando como esperado. Uma vez validada a migração, a mesma alteração pode ser promovida para a produção.

Esses fluxos de trabalho são poderosos porque permitem que os desenvolvedores trabalhem com dados semelhantes aos de produção ou derivados dela, usando o mascaramento do Unity Catalog, por exemplo, sem colocar o banco de dados ativo em risco. Cada branch é isolada e efêmera, tornando-se um ambiente seguro para depuração, testes e validação.

Conclusão

Juntos, esses padrões formam o ciclo de desenvolvimento do Lakebase: uma branch por agente, uma branch por PR e branches isoladas para validação em produção.

Para o SDLC Agêntico, o branching de banco de dados oferece uma base segura e flexível para equipes de desenvolvimento que trabalham com agentes de codificação. Experimente usar o branching você mesmo.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original