Lakebase y SDLC agéntico: bases de datos ramificadas para agentes de programación

La IA ha cambiado la forma en que se construye el software. A medida que los agentes de código asumen una parte cada vez mayor del trabajo de desarrollo, los desarrolladores se están orientando cada vez más a orquestarlos. Ejecutar varios agentes en paralelo se está convirtiendo en la norma, y las herramientas han evolucionado a la par, desde habilidades y hooks hasta MCP, subagentes, todo diseñado para que los agentes sean más seguros y eficaces.

Sin embargo, un componente crítico en el flujo de trabajo de desarrollo aún suele pasarse por alto: la base de datos.

Cada agente concurrente necesita escribir código, aplicar cambios de esquema y ejecutar pruebas en una base de datos. En entornos compartidos, como una única base de datos de desarrollo o staging típica de las configuraciones tradicionales, esto plantea serios desafíos. Los agentes pueden entrar en conflicto con los cambios de esquema, interferir entre sí o recurrir a mocks que no reflejan los datos del mundo real. Estos ya eran puntos de dolor para los desarrolladores, pero los agentes de código los exacerban. Los agentes se mueven más rápido, operan en paralelo y necesitan un entorno seguro para evitar poner en riesgo los datos de producción o exponer información confidencial.

La arquitectura de Lakebase Postgres resuelve esto mediante el ramificado de bases de datos. Del mismo modo que Git le permite crear ramas de código, Lakebase le permite crear ramas de una base de datos completa en menos de un segundo, independientemente de su tamaño. Utiliza copy-on-write, por lo que las ramas comparten los datos de la rama principal y solo consumen almacenamiento adicional a medida que divergen. Además, pueden escalar a cero (scale-to-zero), lo que significa que las ramas inactivas no generan costos de cómputo. Esto es importante al ejecutar varios agentes al mismo tiempo. Cada rama está completamente aislada, lo que permite a un agente aplicar migraciones, ejecutar pruebas y retirar la rama cuando haya terminado.

En este artículo, le mostraré cómo se ve esto en la práctica con un flujo de trabajo completo para un bucle de desarrollo de Lakebase basado en agentes de código. Hay un repositorio de ejemplo disponible aquí con ejemplos de flujos de trabajo de GitHub Actions para lograr lo que se describe en las siguientes secciones.

¿Prefiere verlo en acción? Vea el video demostrativo a continuación.

Antes de comenzar, una nota sobre los entornos con Databricks. Una configuración común al usar Lakebase Postgres es usar un workspace de Databricks por entorno, como dev, staging y prod. La mayoría de los equipos querrán aprovechar los workspaces por diversos motivos, como la seguridad y el cumplimiento, aunque también es posible usar un solo workspace. Del mismo modo, la creación de ramas a partir de una base de datos inicializada con datos en lugar de la base de datos de producción también es habitual para evitar exponer datos confidenciales como PII. En este artículo, utilizaremos un solo workspace por simplicidad, pero los mismos conceptos clave se aplican a configuraciones con múltiples workspaces y se pueden implementar con la misma facilidad.

Bases de datos seguras y aisladas para agentes de código en paralelo

El principal impacto negativo en las bases de datos tradicionales proviene del trabajo simultáneo de múltiples agentes de código. Al desarrollar nuevas funciones o corregir problemas, cada agente a menudo necesita leer el esquema de la base de datos, aplicar cambios, poblar datos y ejecutar pruebas. Sin aislamiento, estos agentes pueden interferir entre sí o corromper una base de datos compartida. El ramificado de la base de datos brinda a cada agente un entorno aislado para trabajar de forma independiente sin afectar a otros agentes que se ejecutan al mismo tiempo.

Una forma práctica de evitar conflictos de código a nivel local es aprovechar los worktrees de Git. Un worktree le da a cada agente su propio directorio con su propia rama activada, por lo que no hay conflictos a nivel de archivos entre ellos. Los worktrees de Git resuelven el aislamiento del código para los agentes en paralelo. El ramificado de Lakebase resuelve la otra mitad: el aislamiento de la base de datos. Al agregar un hook post-checkout al repositorio, cada nuevo worktree obtiene automáticamente su propia rama de base de datos. Una vez finalizado el desarrollo, el agente abrirá un PR. El comportamiento del agente se puede guiar a través de archivos de instrucciones del repositorio como AGENTS.md o CLAUDE.md.

Aquí hay un ejemplo de flujo de trabajo que utiliza Claude Code, worktrees y el ramificado de Lakebase para un desarrollo seguro con IA:

• El agente ejecuta claude -worktree feature-123
• Git crea un worktree para la rama feature-123
• Un hook de post-checkout se activa automáticamente y crea una rama de base de datos
• El agente ahora tiene su propio directorio de código y su propia base de datos totalmente aislada

Cuando el agente termine, creará un PR. Este comportamiento se proporciona en el archivo de instrucciones del repositorio. Una vez que se crea el PR, se pueden retirar tanto el worktree como la rama de la base de datos. Una diferencia importante con Git es que las ramas de Lakebase no se fusionan de nuevo con la rama principal. Debido a que el elemento primario y el secundario pueden cambiar de forma independiente, reconciliar sus datos puede volverse impráctico rápidamente. En su lugar, los cambios de esquema se registran en el código junto con la lógica de la aplicación y luego se promocionan a la rama principal mediante migraciones utilizando herramientas como Drizzle, Flyway, Liquibase o Alembic.

En nuestro ejemplo, utilizamos Drizzle. Cuando se necesita un cambio de esquema, el agente agrega la migración correspondiente a la base de código. La automatización del despliegue aplica esa migración al desplegar la aplicación de vista previa y nuevamente cuando el cambio se fusiona en la rama principal.

Bases de datos efímeras para cada Pull Request

Una vez que se abre un Pull Request (PR), queremos validar y probar automáticamente el código en una base de datos real antes de que llegue a producción.

Utilizando herramientas de integración continua, en este caso GitHub Actions, se crea una rama efímera de Lakebase para cada PR como hija de la rama de producción. Esa rama se convierte en el entorno de base de datos para el PR. Las pruebas automatizadas se pueden ejecutar en ella, se puede desplegar una aplicación de vista previa y los revisores pueden validar el cambio en una base de datos real.

Dado que la rama parte de producción, la migración del esquema también se puede aplicar y probar antes de que el cambio llegue a producción.

Una vez aprobado y fusionado el PR, se promocionan el código de la función y las instrucciones de migración, y se elimina la rama temporal de Lakebase.

Un flujo de trabajo común de GitHub Actions tiene este aspecto:

• Se abre un PR hacia main
• La CI llama a la CLI de Lakebase para crear una rama como pr-123
• La herramienta de migración (Drizzle, Alembic, etc.) se ejecuta en la nueva rama de base de datos dedicada
• Se despliega una aplicación de vista previa, orientada a la cadena de conexión de la rama
• Se genera una diferencia de esquema (schema diff) y se publica como un comentario en el PR que muestra exactamente qué tablas, columnas o índices cambiaron
• El revisor valida tanto el código como los cambios en la base de datos
• Cuando se cierra o se fusiona el PR, la CI elimina la rama

En el ejemplo del repositorio, desplegamos la aplicación con Databricks Apps, pero el concepto se aplica a cualquier otra plataforma de alojamiento como Vercel, Netlify, Cloudflare y más.

Reproducción de errores, migraciones y pruebas con ramas de bases de datos

Más allá de las tareas de desarrollo, la creación de ramas de base de datos puede admitir varios otros flujos de trabajo útiles. Estos no están implementados en el repositorio de ejemplo, pero pueden ser adiciones valiosas para un flujo de trabajo de desarrollo de Lakebase. Por ejemplo, con la creación de ramas de base de datos, puede crear una rama aislada a partir de producción en un momento determinado, normalmente justo antes de que apareciera un error, e investigar el problema con datos reales, reproducir el error de forma segura y retirar la rama una vez validada la solución.

La creación de ramas también puede hacer que las migraciones de esquema sean más seguras. Antes de desplegar un cambio en producción, puede crear automáticamente una rama de base de datos, aplicar la migración, ejecutar pruebas y verificar que la aplicación continúe comportándose según lo previsto. Una vez validada la migración, el mismo cambio se puede promover a producción.

Estos flujos de trabajo son muy potentes porque permiten a los desarrolladores trabajar con datos similares a los de producción o derivados de producción, por ejemplo mediante el enmascaramiento de Unity Catalog, sin poner en riesgo la base de datos en vivo. Cada rama está aislada y es efímera, lo que la convierte en un entorno seguro para la depuración, las pruebas y la validación.

Conclusión

Juntos, estos patrones forman el bucle de desarrollo de Lakebase: una rama por agente, una rama por PR y ramas aisladas para la validación en producción.

Para el SDLC agéntico, la creación de ramas de base de datos ofrece una base segura y flexible para los equipos de desarrollo que trabajan con agentes de código. Pruebe a crear ramas usted mismo.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original