Agentes de programação em paralelo com Lakebase | Claude Code + GitHub Actions

Autoria: Databricks · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Parallel Coding Agents with Lakebase | Claude Code + GitHub Actions · Canal: Databricks · 05:41 · Assistir no YouTube

Tópicos: Agentes de IA, Claude Code, Dados, bancos de dados e embeddings, Engenharia de software com IA, Ferramentas de desenvolvimento com IA

Resumo

O vídeo apresenta um fluxo de CI para agentes de programação que trabalham em paralelo, combinando Git worktrees, Lakebase e GitHub Actions. Cada agente recebe uma branch de banco de dados isolada para desenvolver, executar migrações e testar sem afetar outros agentes ou a produção. Ao abrir um pull request, o CI cria um ambiente de preview com outra branch de banco, aplica as migrações e valida a funcionalidade. As alterações de schema são registradas como migrações portáveis, em vez de mesclar as branches de banco.

Pontos-chave

Agentes em paralelo precisam de ambientes de banco isolados para evitar interferência entre tarefas.
O fluxo usa Git worktrees para que cada agente tenha seus próprios arquivos e sua própria branch Git.
Um hook do Claude Code cria automaticamente uma branch Lakebase para cada nova sessão em uma worktree.
As branches Lakebase usam copy-on-write e podem reduzir o uso de compute a zero quando não estão em uso.
Cada branch de banco permite que o agente execute migrações, teste mudanças e experimente de forma independente.
Ao abrir um pull request, GitHub Actions cria uma branch Lakebase dedicada ao preview e à validação.
As alterações no schema são capturadas como migrações com uma ferramenta como Drizzle; as branches de banco não são mescladas de volta à principal.
O fluxo valida o preview com testes manuais e smoke tests automatizados antes de aplicar as migrações à produção.

Capítulos

Início	Capítulo	Resumo
00:00	Branches de banco para agentes em paralelo	O vídeo apresenta o problema de vários agentes compartilharem um banco e explica como branches isoladas permitem experimentação segura.
01:32	Worktrees e bancos isolados por agente	Claude Code usa Git worktrees e um hook para criar uma branch Lakebase dedicada a cada agente.
03:05	Pull requests e ambientes de preview	O vídeo mostra as branches de banco dos agentes e explica como GitHub Actions cria um banco isolado para validar cada pull request.
04:39	Migrações portáveis e validação final	As alterações de schema são registradas como migrações, e o preview passa por testes antes que as mudanças cheguem à produção.

Citações

Se todos os seus agentes compartilham o mesmo banco de desenvolvimento, como garantir que não interfiram uns com os outros? — 00:00

Cada agente recebe sua própria branch isolada de banco de dados. — 01:01

A branch é temporária, mas a migração é portável. — 04:39

Se podemos criar branches para o código, também deveríamos poder criar branches para bancos de dados. — 05:41

Conceitos e entidades

Lakebase (ferramenta): Banco de dados usado para criar branches isoladas para desenvolvimento, preview e validação.
Claude Code (ferramenta): Ferramenta de programação com agentes usada na demonstração para iniciar sessões em paralelo e executar um hook.
Git worktrees (conceito): Recurso do Git que oferece diretórios de trabalho separados para tarefas e branches diferentes no mesmo repo.
GitHub Actions (ferramenta): Plataforma de automação que inicia o fluxo de CI quando um pull request é criado.
Liquibase (ferramenta): Nome mencionado na transcrição ao apresentar o suporte a branching de banco de dados.
Drizzle (ferramenta): Ferramenta citada para registrar alterações de schema como migrações portáveis.
Codex (ferramenta): Agente de programação citado como alternativa que pode usar o mesmo padrão de trabalho.
Cursor (ferramenta): Ferramenta de programação citada como alternativa para o fluxo demonstrado.

Tradução completa (pt-BR)

00:00 Executar agents de programação em paralelo está se tornando o padrão. As ferramentas evoluíram rapidamente, com recursos como skills, MCP, hooks, subagents e muito mais. Mas há uma parte importante da stack que costuma ser esquecida nos workflows: o banco de dados. Se todos os seus agents compartilham o mesmo banco de dados de desenvolvimento, como garantir que eles não interfiram uns com os outros? Como permitir que cada agent execute testes, aplique alterações no schema e faça experimentos com segurança? Neste vídeo, vou mostrar como

00:30 combinar agents de programação em paralelo, árvores de trabalho do Git, Liquibase e GitHub Actions para criar um workflow de CI de ponta a ponta para agents. O Lakebase Postgres é uma ótima opção para esse tipo de desenvolvimento, porque oferece suporte a ramificações de banco de dados. Você pode pensar nisso de forma semelhante ao Git. O Git permite criar ramificações para o código, e o Lakebase permite criar ramificações para o banco de dados. O Lakebase usa ramificações com cópia na gravação, o que basicamente significa que uma ramificação só usa armazenamento adicional quando começa a

01:01 divergir da ramificação principal. E, quando uma ramificação não está sendo usada, seus recursos computacionais podem ser reduzidos a zero, o que ajuda a manter os ambientes temporários com um custo eficiente. Cada agent recebe sua própria ramificação isolada do banco de dados, para poder executar migrações, testar alterações e fazer experimentos sem afetar nada mais. E, quando o trabalho termina, podemos simplesmente encerrar a ramificação. Isso é especialmente útil para agents de programação, porque eles precisam de espaço para experimentar, tentar abordagens diferentes,

01:32 e, às vezes, cometer erros. Se algo der errado, eles podem simplesmente voltar a um ponto anterior sem afetar mais ninguém. Nesta demonstração, vou usar o Claude Code, mas a mesma abordagem funciona com outros agents de programação, como Codex ou Cursor. Agents de programação podem usar árvores de trabalho do Git para trabalhar em paralelo. Uma árvore de trabalho do Git fornece a um desenvolvedor ou agent um conjunto separado de arquivos de trabalho para o mesmo repositório, geralmente com sua própria ramificação do Git. Isso torna as árvores de trabalho especialmente

02:02 úteis para agents, porque vários agents podem trabalhar em tarefas diferentes no mesmo repositório sem interferir uns com os outros. Usando a integração de árvores de trabalho do Claude Code, vou executar vários agents em funcionalidades diferentes. Cada agent terá sua própria pasta e sua própria ramificação do Git. Também configurei um hook do Claude Code para que, sempre que eu iniciar uma nova sessão com uma árvore de trabalho, ele crie automaticamente uma ramificação dedicada do Lakebase a partir da ramificação principal do banco de dados.

02:33 Assim, cada agent pode desenvolver e testar sua funcionalidade no próprio banco de dados, sem mexer no ambiente de mais ninguém nem em produção. Agora, vou iniciar quatro sessões separadas do Claude Code, cada uma trabalhando em uma funcionalidade diferente. Juntas, elas vão aprimorar um aplicativo simples de lista de tarefas, adicionando recursos como prioridades, datas de vencimento e algumas outras funcionalidades. Enquanto os agents trabalham, vamos dar uma olhada na interface do Lakebase. Aqui, podemos explorar o banco de dados e todas as suas

03:05 ramificações, inclusive aquelas em que os agents estão trabalhando no momento. Dá para ver que foram criadas quatro ramificações, uma para cada agent. Vamos abrir uma delas. Se verificarmos as diferenças no schema, veremos que o agent adicionou uma nova coluna ao banco de dados para a funcionalidade em que está trabalhando. Portanto, essa alteração no banco de dados está completamente isolada na ramificação daquele agent. Agora, vamos voltar aos agents e ver como estão indo. Parece que alguns deles já

03:37 terminaram. Os agents receberam instruções para abrir pull requests assim que concluírem o trabalho. Então, vamos ao GitHub conferir. Aqui, temos alguns pull requests que foram abertos automaticamente pelo agent. Assim que um pull request é criado, o GitHub Actions inicia outro workflow de automação. Nesse momento, a ramificação do banco de dados do agent já cumpriu sua função durante o desenvolvimento. Para o pull request, a CI cria uma nova ramificação do Lakebase específica para

04:08 pré-visualização e validação. Em seguida, o workflow faz o deploy de uma versão de pré-visualização do aplicativo e a conecta a essa ramificação dedicada do banco de dados. Também dá para ver uma etapa de migração no workflow. Se a funcionalidade incluir alterações no schema do banco de dados, a migração será executada na ramificação isolada do Lakebase e aplicará essas alterações, como criar uma nova coluna ou uma nova tabela. Uma diferença importante aqui é que

04:39 as ramificações do Lakebase não são mescladas de volta à ramificação principal como acontece com as ramificações do Git. Em vez disso, registramos as alterações no schema como migrações usando uma ferramenta como Drizzle. Assim, a ramificação é temporária, mas a migração é portátil. Para cada pull request, isso nos proporciona um banco de dados dedicado para revisão e garantia da qualidade antes que qualquer coisa chegue à produção. Neste exemplo, podemos testar manualmente o aplicativo de pré-visualização e também executar testes automatizados de fumaça nele.

05:11 E esse é o workflow completo. Começamos com vários agents de programação trabalhando em paralelo, cada um com sua própria ramificação isolada do banco de dados. Depois, para cada pull request, criamos um ambiente novo de pré-visualização com sua própria ramificação do banco de dados, aplicamos as migrações e testamos a funcionalidade de forma isolada. E, depois que tudo foi validado, essas mesmas migrações foram aplicadas com segurança em produção. O exemplo usa Claude Code e GitHub Actions, mas o mesmo padrão pode funcionar com outros agents de programação e

05:41 sistemas de CI. A ideia é bem simples. Se podemos criar ramificações do código, também devemos poder criar ramificações dos bancos de dados. Assim, os agents podem trabalhar em paralelo com segurança. Você encontra o repositório de exemplo e o workflow completo de CI na descrição.

Transcrição original

[00:00] Running coding agents in parallel is becoming the norm. The tooling has evolved quickly with things like skills, MCP, hooks, sub-agents, and more. But, there is one important part of the stack that often gets overlooked in their workflows, the database. If all your agents share the same development database, how do you make sure they don’t interfere with each other? How do you let each agent run tests, apply schema changes, and experiment safely? In this video, I’ll show you how to

[00:30] combine parallel coding agents, Git work trees, Liquibase, and GitHub Actions to build an end-to-end agent CI workflow. Liquibase Postgres is a great fit for this kind of development because it supports database branching. You can think about it in similar way to Git. Git lets you create branches for your code, and Liquibase lets you create branches for your database. Liquibase uses copy-on-write branching, which basically means a branch only uses additional storage as it starts to

[01:01] diverge from its parent. And when a branch isn’t being used, its compute can scale down to zero, which helps keep temporary environments cost-efficient. Each agent gets its own isolated database branch, so it can run migrations, test changes, and experiment without affecting anything else. And once the work is done, we can simply retire the branch. This is especially useful for coding agents because they need room to experiment, try different approaches,

[01:32] and sometimes make mistakes. If something goes wrong, they can simply roll back to an earlier point without affecting anyone else. In this demo, I’m going to use Cloud Code, but the same approach works with other coding agents like Codex or Cursor. Coding agents can use Git work trees to work in parallel. A Git work tree gives a developer or an agent a separate set of working files for the same repository, usually with its own Git branch. That makes work trees especially

[02:02] useful for agents because multiple agents can work on different tasks in the same repository without interfering with one another. Using Cloud Code’s work tree integration, I’m going to run multiple agents on different features. Each agent will have its own folder and its own Git branch. I also set up a Cloud Code hook so that whenever I launch a new session with a work tree, it automatically creates a dedicated Lake Base branch from the main database branch.

[02:33] So, each agent can build and test its feature against its own database without touching anyone else’s environment or production. Now, I’m going to launch four separate Cloud Code sessions with each one working on a different feature. Together, they’ll improve a simple to-do app by adding things like priorities, due dates, and a few other features. While the agents are working, let’s take a look at the Lake Base interface. Here, we can explore the database and all its

[03:05] branches, including the ones the agents are currently working on. You can see that four branches have been created, one for each agent. Let’s open one of them. If we check the schema diff, we can see that the agent added a new column to the database for the feature it’s working on. So, this database change is completely isolated to that agent’s branch. Now, let’s go back to the agents and see how they’re doing. It looks like a few of them have

[03:37] finished. The agents are instructed to open pull requests once their work is done. So, let’s jump over to GitHub and take a look. Here, we have a couple of pull requests that were opened automatically by the agent. As soon as a pull request is created, GitHub Actions start another automation workflow. At this point, the agent’s database branch has done its job during development. For the pull request, CI creates a new Lake Base branch specifically for

[04:08] preview and validation. The workflow then deploys a preview version of the application and connects it to that dedicated database branch. You can also see a migration step in the workflow. If the feature includes database schema changes, the migration runs against the isolated Lake Base branch and applies those changes, such as creating a new column or creating a new table. One important difference here is that

[04:39] Lake Base branches don’t get merged back into main like Git branches do. Instead, we capture the schema changes as migrations using a tool like Drizzle. So, the branch is temporary, but the migration is portable. For every pull request, this gives us a dedicated database for review and QA before anything reaches production. In this example, we can manually test the preview application and we also run automated smoke tests against it.

[05:11] And that’s the complete workflow. We started with multiple coding agents working in parallel, each with its own isolated database branch. Then, for every pull request, we created a fresh preview environment with its own database branch, applied the migrations, and tested the feature in isolation. And once everything was validated, those same migrations were safely applied to production. The example here uses Cloud Code and GitHub Actions, but the same pattern can work with other coding agents and CI

[05:41] systems. The idea is pretty simple. If we can branch code, we should be able to branch databases too. So, agents can work safely in parallel. You can find the example repository and the full CI workflow in the description.