Presentazione di Consort: sviluppo guidato dai test su un database con branching

Per 25 anni ho sviluppato software basandomi sulle pratiche con cui sono cresciuto: il TDD di Kent Beck, il Refactoring di Martin Fowler, il Clean Code di Uncle Bob, la Continuous Delivery di Jez Humble e Dave Farley, e l'Evolutionary Database Design di Pramod Sadalage e Scott Ambler.

Con le moderne pratiche di sviluppo software, il codice può essere suddiviso in branch, gli ambienti sono containerizzati e l'infrastruttura diventa codice. Ma una parte dello stack non si è mai adeguata: il database. È rimasto lì come un monolite rigido, e per questo abbiamo accettato molti compromessi, come l'uso di mock al posto del database reale, un ambiente di staging condiviso e modifiche dello schema eseguite come una delicata cerimonia.

Da un po' di tempo parlo con i team di sviluppo software di Lakebase Postgres e di come questo cambi il nostro modo di lavorare. Forse mi avrete già sentito dire: Create branch del vostro database proprio come fate per il codice. Ma cosa significa in pratica e come si applica?

Cosa cambia con il branching del database

I test di integrazione tornano all'inner loop

In passato, i test su un database reale erano una questione legata all'outer loop. Configurare un database, popolarlo con schema e dati, gestire le versioni dello schema ed eseguire tutto questo per ogni unit test era troppo costoso, quindi non lo facevo. Nessuno lo faceva. Scrivevamo invece unit test basati su oggetti mock, non perché i mock fossero validi, ma perché un database reale nell'inner loop era fuori portata. E sappiamo che i mock divergono nel tempo; perdono il sincronismo con il comportamento effettivo del database e più li si mantiene, meno verificano il comportamento reale.

Il branching copy-on-write elimina la necessità di usare i mock. È possibile creare un branch isolato del database reale in un tempo praticamente costante, indipendentemente dalle dimensioni dei dati. Il primo test che scrivo, in stile TDD, viene eseguito su un branch attivo con dati reali, non su una simulazione. Posso eseguire test distruttivi, distruggere tutto, incasinare lo schema e non toccare mai il lavoro del resto del team. È il mio branch. Quando ho finito, lo elimino.

Codice e schema vengono distribuiti insieme

Poiché lo schema ora viaggia sotto forma di migrazioni con versione (Alembic, Flyway o Knex, a seconda dello stack), la modifica dello schema e il codice da cui dipende si muovono insieme come un'unica unità. Si esegue il merge dello schema (not dei dati) e il codice si allinea di conseguenza. Due ingegneri a cui l'ho mostrato, in team diversi, hanno usato la stessa espressione per definirlo: Data CD.

Il blocco della produzione alle 2 di notte viene intercettato prima che accada

Quando qualcosa si rompe in produzione, di solito succede alle 2 del mattino, e ci si ritrova a fare reverse engineering per capire cosa sia cambiato. Il branching ribalta questa tempistica. Ad ogni pull request, e di nuovo al merge, si crea un nuovo branch del database dall'ambiente di destinazione, si eseguono le migrazioni e l'intera suite di test su di esso, individuando la regressione o il conflitto prima del deployment. La modifica dello schema si trova nella pull request come migrazione, quindi il DBA la esamina direttamente lì come code owner, anziché come ticket in una coda a valle.

In passato, promuovere una modifica dello schema era una procedura ad alto rischio. Ora si crea un branch di produzione, si applica la modifica, la si testa in isolamento e la si promuove. Fare lo stesso su una configurazione Postgres cloud standard richiede una serie di fragili script DevOps e fa perdere tempo prezioso.

Niente di tutto questo è una funzionalità del database da attivare. Si tratta di uno spostamento del momento in cui avvengono i test più complessi, completamente a sinistra (shift left), nel ciclo in cui si scrive effettivamente il codice.

Un framework di sviluppo agentico con branching del database

Ora che l'infrastruttura per il branching è disponibile, ciò che mancava nel dibattito era qualcosa che la mettesse all'opera in un ciclo di sviluppo reale. Ecco perché ho creato Consort.

Consort è un framework di sviluppo agentico open source che utilizza il branching di Lakebase come base per la sua build guidata dai test. Se conoscete Scrum, l'idea è racchiusa nel nome. Ogni ruolo del team (product owner, autore delle specifiche, architect reviewer, DBA, stratega dei test e una coppia navigator/driver) diventa un agente. Collaborano insieme, guidati da un conduttore, e alla fine si esibiscono come un consort (un ensemble).

Il lavoro si sviluppa su due binari: un binario di progettazione spec-first, in cui l'intento viene concordato e congelato, e un binario di build che esegue l'intero ciclo red/green/refactor su un branch attivo del database reale. Alcuni componenti permettono di mantenere la coesione quando è un agente a scrivere il codice.

• L'agente ha un limite reale con cui confrontarsi. Se date a un agente qualcosa di concreto, risolverà il problema, perché è in grado di capire quando il codice non funziona. Se gli fornite un test ermetico e basato su mock, vi consegnerà tranquillamente qualcosa che sembra superare il test, per poi bloccarsi nel momento in cui lo eseguite su un database reale. Un branch attivo di dati reali rappresenta il limite concreto: l'agente non può fare supposizioni di fronte a un database realmente esistente.
• Il driver non può spostare i traguardi. Chi ricopre il ruolo di scrivere il codice non può modificare un test per farlo passare. L'unica eccezione è una reale sostituzione, ovvero una storia successiva che manda legittimamente in pensione un vecchio test. "Green" significa che il test è stato eseguito e superato sul branch reale del database, non perché l'agente ha detto che lo è stato.
• Il conduttore è codice, non un agente. Il ruolo che un team chiama scrum master diventa una macchina a stati deterministica. Instrada il lavoro, gestisce i passaggi di approvazione umana e reindirizza al ruolo responsabile in caso di conflitti, in modo che il processo che guida il ciclo non possa saltare un passaggio o perdere il filo.
• Non perde di vista l'obiettivo. La lamentela che sento più spesso riguardo ad altri framework è che dopo pochi giorni l'agente perde di vista l'obiettivo, ci si frustra e si ricomincia da capo. Consort conserva gli artefatti di ciascuna funzionalità in una struttura di directory dedicata da cui gli agenti leggono, come un contratto tra i ruoli. È lo stesso passaggio di consegne che avviene in un team reale: ogni specialista esamina il lavoro, aggiunge le proprie considerazioni e lo passa al successivo.

Come strategia di ottimizzazione (per evitare che gli agenti passino l'inizio di ogni turno a fare nuovamente la scansione di tutto), Consort fornisce a ciascun agente un pacchetto di contesto mirato, i test esatti da superare, i requisiti di progettazione e la posizione di tali test, invece di lasciarlo libero sull'intera codebase. L'accesso non limitato è il motivo per cui gli agenti deviano dall'obiettivo e passano un'eternità a barcamenarsi nel codice cercando di capire cosa fare e dove inserirlo, fino a dimenticare persino cosa significhi DRY.

L'architect esamina le specifiche prima che venga scritto qualsiasi codice e definisce il design desiderato, inclusi i requisiti cross-funzionali, la stratificazione e pattern come DRY, SRP e SOLID. Questa progettazione preventiva è il motivo per cui non ci si ritrova con tutto in un unico file. E quando si desidera esplorare, Consort esegue esperimenti paralleli per una storia, ciascuno sul proprio branch del database e worktree, in modo completamente isolato, consentendo di provare più di un approccio e mantenere l'esperimento migliore. Quando ho mostrato questo sistema ad altri ingegneri, tendono a riconoscerlo immediatamente come la soluzione che stavano cercando di creare da soli.

È possibile monitorare tutto questo e orientarne la direzione. Un plugin per VS Code mostra i branch Git e Lakebase associati nei vari livelli, con le modifiche al codice e allo schema in un'unica vista diff. Una dashboard di osservabilità mostra ogni turno in tempo reale: ogni ruolo, il relativo prompt e gli artefatti prodotti per il ruolo successivo. E a ogni passaggio, potete ispezionare voi stessi il software funzionante, eseguito sul proprio branch, prima di approvarne il passaggio alla fase successiva.

Cosa è (e cosa non è) Consort

Consort è open source e supportato dalla community. È un progetto che potete adottare, eseguire e consigliare, con un proprio ciclo di vita. Non si tratta di una funzionalità di piattaforma integrata con un SLA.

Non è necessario riorganizzare lo stack per utilizzarlo. Lakebase è Postgres, quindi l'applicazione finale viene eseguita su di esso senza richiedere alcun flusso di lavoro di branching; il branching associato di Git e Lakebase è un'attività che si svolge durante lo sviluppo.

Per 25 anni il database è stato l'unica parte del nostro stack che non poteva essere suddivisa in branch. Ora è possibile. Questo è ciò che cambia, ed è per questo che ho creato Consort.

Provatelo voi stessi

Vi serve solo Lakebase. Ottenetelo con la Free Edition.

Il resto dello stack è aperto (Java, Python o Node), funziona su Claude e dispone di un plugin complementare per VS Code.

Quando siete pronti, bastano tre comandi:

/consort:start vi guida all'interno di un progetto. Iniziate con l'esempio StockFlow. Viene avviato con tre file, e da lì potrete vederlo crescere fino a diventare una codebase completa.

Una (r)evoluzione nella creazione di software

Se questo lavoro vi ispira e volete migliorarlo, sono alla ricerca di altri collaboratori e codeowner. Se desiderate partecipare o semplicemente vedere come funziona all'interno, è disponibile un articolo su arXiv: https://arxiv.org/abs/2609.09671 oppure visitate la repository: https://github.com/databricks-solutions/consort

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale