Presentamos Consort: desarrollo guiado por pruebas en una base de datos ramificada

Durante 25 años creé software basándome en las prácticas con las que crecí: TDD de Kent Beck, la refactorización de Martin Fowler, el Clean Code de Uncle Bob, la entrega continua de Jez Humble y Dave Farley, y el diseño evolutivo de bases de datos de Pramod Sadalage y Scott Ambler.

Con las prácticas modernas de desarrollo de software, el código se puede ramificar, los entornos se contenedorizan y la infraestructura se convierte en código. Pero una parte del stack nunca siguió el ritmo: la base de datos. Permanecía allí como un monolito rígido, y por eso aceptábamos muchos parches, como usar mocks en lugar de la base de datos real, un entorno de staging compartido y cambios de esquema ejecutados como una ceremonia minuciosa.

Llevo un tiempo hablando con equipos de desarrollo de software sobre Lakebase Postgres y cómo cambia lo que solíamos hacer. Quizás me hayas oído decir: Ramifica tu base de datos como ramificas tu código. Pero ¿qué significa eso en la práctica y cómo se aplica?

Qué cambia con la ramificación de bases de datos

Las pruebas de integración vuelven al ciclo interno de desarrollo

Probar contra una base de datos real solía ser un problema del ciclo externo. Levantar una base de datos, poblarla con esquemas y datos, controlar las versiones del esquema y hacerlo para cada prueba unitaria era demasiado costoso, así que no lo hacía. Nadie lo hacía. En su lugar, escribíamos pruebas unitarias contra objetos mock, no porque los mocks fueran buenos, sino porque tener una base de datos real en el ciclo interno era inalcanzable. Y sabemos que los mocks se desvían con el tiempo; se desfasan de cómo se comporta realmente la base de datos y, cuanto más los mantienes, menos comportamiento real verifican.

La ramificación de copia en escritura (copy-on-write) elimina la razón de ser de los mocks. Puedes crear una rama aislada de la base de datos real en un tiempo prácticamente constante, sin importar el tamaño de los datos. La primera prueba que escribo, al estilo TDD, se ejecuta en una rama activa con datos reales, no en una simulación. Puedo ejecutar pruebas destructivas, romperlo todo, arruinar mi esquema y nunca afectar el trabajo del resto del equipo. Es mi rama. Cuando termino, la descarto.

El código y el esquema se envían como uno solo

Como ahora el esquema viaja en forma de migraciones con versión (Alembic, Flyway o Knex, según el stack), el cambio de esquema y el código del que depende se mueven juntos como una sola unidad. Fusionas el esquema (not los datos) y el código se alinea con él. Dos ingenieros a los que les mostré esto, de diferentes equipos, coincidieron en la misma frase para describirlo: CD de datos.

El fallo de producción de las 2 a. m. se detecta antes de que ocurra

Cuando algo falla en producción, suele ser a las 2 a. m., y te encuentras haciendo ingeniería inversa para descubrir qué cambió. La ramificación cambia por completo estos tiempos. En cada pull request, y de nuevo al fusionar, creas una rama de base de datos nueva a partir del entorno de destino, ejecutas las migraciones y toda la suite de pruebas contra ella, y encuentras la regresión o el conflicto antes de que se despliegue. El cambio de esquema está en el pull request como una migración, por lo que tu DBA lo revisa allí como propietario del código, no como un ticket en una cola de espera posterior.

Promocionar un cambio de esquema solía ser una ceremonia de alto riesgo. Ahora creas una rama de producción, aplicas el cambio, lo pruebas de forma aislada y lo promocionas. Hacer lo mismo en una configuración estándar de Postgres en la nube requiere un montón de scripts de DevOps frágiles y desperdicia un tiempo humano valioso.

Nada de esto es una función de base de datos que simplemente activas. Es un cambio en cuándo se realizan las pruebas difíciles, desplazándolas por completo a la izquierda, en el ciclo donde realmente estás escribiendo el código.

Un marco de desarrollo agéntico con ramificación de bases de datos

Ahora que la infraestructura para la ramificación está aquí, lo que faltaba en la conversación era algo que la pusiera a trabajar en un ciclo de desarrollo real. Por eso creé Consort.

Consort es un marco de desarrollo agéntico de código abierto que utiliza la ramificación de Lakebase como base de su compilación guiada por pruebas. Si conoces Scrum, la idea está en el nombre. Cada rol del equipo (product owner, autor de especificaciones, revisor de arquitectura, DBA, estratega de pruebas y una pareja de navegador/conductor) se convierte en un agente. Actúan juntos, dirigidos por un director, y finalmente se desempeñan como un conjunto (consort).

El trabajo se divide en dos carriles: un carril de diseño centrado en las especificaciones, donde la intención se acuerda y se congela, y un carril de compilación que ejecuta el ciclo completo de rojo/verde/refactorización contra una rama activa de la base de datos real. Algunos componentes hacen que todo funcione de manera cohesionada cuando es un agente el que escribe el código.

• El agente tiene un límite real con el que interactuar. Dale a un agente algo concreto y resolverá el problema, porque puede notar cuándo el código no funciona. Dale una prueba hermética y con mocks, y con gusto te entregará algo que parece que funciona pero que falla en el momento en que lo ejecutas contra una base de datos real. Una rama activa de datos reales es ese límite concreto; el agente no puede hacer suposiciones sobre una base de datos que realmente está allí.
• El conductor no puede cambiar las reglas del juego. El rol que escribe el código no puede modificar una prueba para que pase. La única excepción es una sustitución genuina, es decir, una historia posterior que retire legítimamente una prueba antigua. El estado verde significa que la prueba se ejecutó y pasó contra la rama de la base de datos real, no porque el agente haya dicho que lo hizo.
• El director es código, no un agente. El rol que un equipo llama scrum master se convierte en una máquina de estados determinista. Enruta el trabajo, gestiona los puntos de aprobación humana y lo redirige al rol responsable cuando hay un conflicto, de modo que el proceso que impulsa el ciclo no pueda saltarse ningún paso ni perder el hilo.
• No pierde de vista el objetivo. La queja que más escucho sobre otros marcos es que, después de unos días, el agente pierde de vista el objetivo, te frustras y tienes que reiniciar. Consort guarda los artefactos de cada función en una estructura de directorios dedicada de la cual leen los agentes como un contrato entre roles. Es el mismo traspaso que realiza un equipo real: cada especialista revisa el trabajo, añade sus observaciones y lo pasa al siguiente.

Como estrategia de optimización (para que tus agentes no pasen el inicio de cada turno volviendo a escanear todo), Consort proporciona a cada agente un paquete de contexto delimitado, las pruebas exactas que debe pasar, los requisitos de diseño y dónde se encuentran esas pruebas, en lugar de dejarlo suelto por todo el código base. El acceso sin delimitar es la razón por la que los agentes se desvían y pasan una eternidad dando vueltas al código intentando averiguar qué hacer y dónde va, hasta que olvidan lo que significa DRY.

El arquitecto revisa la especificación antes de escribir cualquier código e incorpora el diseño que te interesa, incluidos los requisitos transversales, la división en capas y patrones como DRY, SRP y SOLID. Ese diseño previo es la razón por la que no terminas con todo en un solo archivo. Y cuando quieres explorar, Consort ejecuta experimentos paralelos para una historia, cada uno en su propia rama de base de datos y árbol de trabajo (worktree), totalmente aislados, para que puedas probar más de un enfoque y quedarte con el mejor experimento. Cuando les he mostrado esto a otros ingenieros, suelen reconocerlo de inmediato como lo que ellos mismos habían estado intentando crear.

Puedes observar todo el proceso y guiar la dirección. Un complemento de VS Code muestra tus ramas emparejadas de Git y Lakebase en todos los niveles, con los cambios de código y esquema en una única vista de diferencias (diff). Un panel de observabilidad muestra cada turno en vivo: cada rol, su prompt y los artefactos que produce para que los consuma el siguiente rol. Y en cada punto de control, tú mismo inspeccionas el software en funcionamiento, ejecutándose en su propia rama, antes de aprobar su avance.

Qué es (y qué no es) Consort

Consort es de código abierto y cuenta con el respaldo de la comunidad. Es un proyecto que puedes adoptar, ejecutar y recomendar, con su propio ciclo de vida. No es una función integrada de la plataforma con un SLA.

No tienes que reestructurar tu stack para usarlo. Lakebase es Postgres, por lo que tu aplicación terminada se ejecuta en él sin necesidad de un flujo de trabajo de ramificación; la ramificación emparejada de Git y Lakebase es algo que haces durante el desarrollo.

Durante 25 años, la base de datos fue la única parte de nuestro stack que no se podía ramificar. Ahora sí se puede. Eso es lo que cambia, y por eso creé Consort.

Pruébalo tú mismo

Solo necesitas Lakebase. Consíguelo en la Edición Gratuita.

El resto del stack es abierto (Java, Python o Node), se ejecuta en Claude y cuenta con un complemento complementario para VS Code.

Cuando estés listo, son solo tres comandos:

/consort:start te guía en la creación de un proyecto. Comienza con el ejemplo StockFlow. Se inicia con tres archivos y, a partir de ahí, puedes ver cómo crece hasta convertirse en un código base completo.

Una (r)evolución en la construcción de software

Si este trabajo te inspira y quieres mejorarlo, estoy buscando más colaboradores y propietarios de código (codeowners). Si deseas unirte o simplemente ver cómo funciona el sistema por dentro, hay un artículo en arXiv: https://arxiv.org/abs/2609.09671 o visita el repositorio: https://github.com/databricks-solutions/consort

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