Worktrees de Git aíslan los archivos de tus agentes. El patrón Lakebase de Databricks aísla sus bases de datos

Ejecute tres agentes de código en paralelo y no colisionarán en Git. Cada uno tiene su propio worktree, su propia rama, sus propios archivos. Colisionarán en la base de datos. La migración de un agente renombra una columna de la que dependen las pruebas de otro agente, los fixtures de un tercer agente sobrescriben las filas que ambos usaban, y los fallos parecen errores en un código que en realidad está bien.

Una publicación de Databricks del 8 de octubre describe una salida. Escrita por Thibaut Gourdel, es un flujo de trabajo de referencia, no el lanzamiento de un producto, construido sobre Lakebase, el Postgres gestionado de Databricks, y su ramificación copy-on-write. Databricks dice que Lakebase puede ramificar “una base de datos completa en menos de un segundo, independientemente de su tamaño”. Las ramas comparten los datos de la matriz y consumen almacenamiento adicional solo a medida que divergen, y las ramas inactivas pueden escalar a cero, por lo que no generan costo de cómputo mientras no se usan.

El flujo de trabajo

El patrón da una rama de base de datos a cada unidad de trabajo en paralelo, en dos niveles.

Por agente. Cuando un agente de código recibe un worktree de Git, un hook post-checkout de Claude Code crea una rama de base de datos correspondiente. El agente desarrolla contra su propia copia, escribe sus cambios de esquema como migraciones, y cuando el pull request está abierto, el worktree y su rama de base de datos se pueden retirar.

Por pull request. En CI, GitHub Actions crea una rama como pr-123 como hija de producción, ejecuta las migraciones (Drizzle en el ejemplo), despliega una app de vista previa en Databricks Apps y publica un diff de esquema en el pull request. La rama se elimina cuando el pull request se cierra o se fusiona.

1. El agente recibe un worktree
2. El hook crea su rama de base de datos
3. El agente escribe código y una migración
4. CI crea una rama desde producción y ejecuta la migración
5. Se revisan el diff de esquema y la vista previa
6. La fusión aplica la migración a producción

• Por agente: El agente recibe un worktree · El hook crea su rama de base de datos · El agente escribe código y una migración
• Por pull request: CI crea una rama desde producción y ejecuta la migración · Se revisan el diff de esquema y la vista previa

Espacio de trabajo del agenteValidación en CI

Por qué la regla de las migraciones es lo más importante

La frase más importante de la publicación es una limitación: “Las ramas de Lakebase no se fusionan de vuelta a la rama principal”. Los cambios de esquema se rastrean en el código junto con la aplicación y se promueven a través de migraciones.

Eso convierte una restricción en un control. Haga lo que haga un agente en su rama de base de datos, lo único que llega a producción es un archivo de migración en un pull request, revisado como cualquier otro cambio. Es el principio que describimos en agentes como autores de cambios en producción: el cambio de un agente cuenta solo cuando pasa por el proceso de cambio, como un artefacto que una persona puede leer y rechazar.

Dónde el patrón necesita reglas

Qué datos ve el agente. La rama del PR en el ejemplo parte de producción, que es lo que hace realista la prueba de migraciones. Pero un agente que trabaja en una rama de producción está trabajando con datos de producción. La publicación señala que ramificar desde una base de datos sembrada “también es común” para evitar exponer datos sensibles, y que las ramas derivadas de producción pueden usar el enmascaramiento de Unity Catalog. Nosotros haríamos la opción segura la predeterminada: ramas de agente desde datos sembrados o enmascarados, y ramas de producción solo dentro de CI, bajo una identidad que ejecuta migraciones sin entregar filas al agente.

Qué credenciales llegan a cada rama. El aislamiento en los datos significa poco si cada agente tiene credenciales para cada rama. La identidad de base de datos de cada agente debería llegar solo a su propia rama, el mismo principio que se aplica a su rol en la nube.

Limpieza. Cientos de ramas de corta vida son baratas solo si realmente se eliminan. El ciclo de vida de las ramas pertenece a la automatización, no a la memoria de un desarrollador, y alguien debería revisar periódicamente las ramas que sobrevivieron a su worktree.

Estado. La publicación no indica el estado de lanzamiento de las funciones de ramificación que utiliza, ni ningún límite. Verifíquelos antes de planificar un despliegue gradual.

Los agentes en paralelo exponen cada recurso mutable compartido que tiene un equipo: primero las bases de datos, luego las colas, las cachés, los feature flags y las cuentas de prueba externas. Los worktrees resolvieron el más fácil. La ramificación de bases de datos es una respuesta sólida para el siguiente, y la disciplina que impone, migraciones como el único camino a producción, vale la pena adoptarla incluso donde las herramientas sean diferentes.