Consentire lo sviluppo evolutivo dei database: il branching dei database con Lakebase, la conclusione

La metodologia descritta in Evolutionary Database Design e resa operativa in Refactoring Databases: Evolutionary Database Design è chiara ormai da vent'anni. Le sette pratiche, il catalogo di oltre 70 refactoring codificati, i meccanismi di transizione: tutto documentato, sottoposto a peer review e insegnato.

Quella metodologia è arrivata alla CI/CD nel 2010 con Continuous Delivery (Capitolo 12: Managing Data). Le migrazioni sono diventate artefatti di prim'ordine nella pipeline di distribuzione. La disciplina delle modifiche al database come codice ha raggiunto il più ampio movimento CI/CD. Ciò che la CD non ha risolto è stato l'isolamento per singola pipeline: le pipeline potevano eseguire migrazioni, ma avevano comunque bisogno di un database di destinazione, e tale destinazione era condivisa. La Pratica #4 – Ognuno riceve la propria istanza di database – è rimasta un'aspirazione per la maggior parte dei team, perché database reali a misura di produzione per ogni sviluppatore richiedono tempo, denaro e cicli di DBA. Il livello di compensazione emerso per aggirare questa lacuna (mock object, ambienti di staging condivisi, database sostitutivi in-memory, code di ticket per i DBA) è diventato una metodologia fondamentale per impostazione predefinita, non per scelta progettuale.

Nel 2026, il branching del database copy-on-write arriva in Databricks Lakebase. Creare in un secondo un branch a zero storage iniziale di un database di produzione su scala terabyte è ora un'operazione O(1). Il vincolo che rendeva la Pratica #4 solo un'aspirazione è venuto meno.

Questa serie descrive cosa cambia quando questo vincolo viene rimosso: non la metodologia (che rimane valida), ma le pratiche che emergono per la prima volta, la governance a livello di team che diventa automatica, l'evoluzione del ruolo del DBA e il nuovo substrato che gli agenti condividono con le loro controparti umane.

Ti presentiamo Jen

Jen è la sviluppatrice protagonista di Evolutionary Database Design. In quel saggio ha implementato un refactoring del database – dividendo un campo inventory_code in location_code, batch_number e serial_number – come una normale user story, dimostrando che DBA e sviluppatori possono collaborare, gli schemi possono evolvere a piccoli passi e le migrazioni portano avanti il cambiamento in modo sicuro.

La serie ritrova Jen vent'anni dopo. La metodologia che segue è la stessa del 2003. La novità è il substrato alla base del suo flusso di lavoro: il branching del database copy-on-write, che rende le pratiche di cui ha letto operativamente reali su scala di produzione. Nelle tre parti di questa serie, seguiamo Jen in tre diversi ambiti: la sua giornata (Parte 1), il suo nuovo playbook (Parte 2) e il suo team (Parte 3).

Parte 3: Il team di Jen su larga scala

La Parte 1 ha guidato Jen attraverso una singola funzionalità. La Parte 2 ha definito il playbook di undici pratiche che il suo lavoro segue nel 2026. La Parte 3 applica lo stesso playbook a un team di cinquanta sviluppatori, con agenti che creano branch insieme agli esseri umani, e si chiede: cosa diventa strutturale a questa scala?

Tre elementi diventano portanti.

In primo luogo, la topologia dei livelli, ovvero i branch a lungo termine che rappresentano ciascun ambiente nel percorso di promozione. Con un solo sviluppatore, avevi un feature branch e la produzione. Con cinquanta, hai una gerarchia strutturata con canali stabili e canali effimeri sovrapposti.

In secondo luogo, il modello dei permessi, ovvero il framework che definisce chi può fare cosa e su quale branch. Con un solo sviluppatore, potevi affidarti alle convenzioni. Con cinquanta, e con l'aggiunta degli agenti, il framework deve essere progettato una sola volta e applicato automaticamente.

In terzo luogo, il ruolo del DBA. Con un solo sviluppatore, il DBA era il partner di progettazione di Jen sulla PR. Con cinquanta, il DBA è l'ingegnere di piattaforma che ha progettato il framework all'interno del quale operano Jen e i suoi colleghi.

Questo post analizza ciascuno di questi aspetti, per poi passare agli agenti. Gli agenti con le stesse capacità rappresentano la Pratica #11. Gli agenti sono come sviluppatori junior: producono codice che funziona, test che vengono superati, migrazioni che si applicano e, senza una guida, sistemi non mantenibili. I test sono il modo in cui il team li tiene sotto controllo. Il playbook TDD che segue mostra come il team mette i test al primo posto.

Livelli come branch a lungo termine, non come istanze separate

Nel mondo precedente al branching, un ambiente era un'istanza: una distribuzione Postgres dedicata per lo staging, un'altra per l'UAT, un'altra ancora per i test di performance, ognuna configurata, aggiornata, mascherata e sincronizzata separatamente. Anche il livello di compensazione menzionato nella Parte 2 risiedeva qui. Il disallineamento tra gli ambienti era strutturale.

Su scala di team, il modello a livelli si riduce a branch a lungo termine derivati dallo stesso parent Lakebase.

Un branch può essere una di queste due cose: un livello (tier) (a lungo termine, un parent nella gerarchia di promozione) o una funzionalità (feature) (effimera, discende da un livello e viene eliminata dopo l'uso). Un livello ha un parent. La catena di relazioni parent-of costituisce la gerarchia di promozione.

Nella Fig 1 vediamo una gerarchia semplice, in cui il main rappresenta la produzione e i branch Feature vengono creati all'occorrenza; questa configurazione è generalmente utile per la prototipazione iniziale o per lavori in fase iniziale con un team molto ridotto. I team maturi con più sviluppatori e/o molti ambienti richiedono invece una configurazione come quella mostrata di seguito.

In alcune aziende, vi è la necessità di avere una release candidate (RC); questa release candidate rimane in fase di sviluppo per un certo periodo e, dopo un test superato con successo, viene promossa in produzione. La Fig 3 mostra un layout che consente lo sviluppo di release candidate e la loro successiva promozione in produzione, dopodiché il branch della release candidate può essere rimosso.

I nomi dei branch sono arbitrari, ciò che conta sono le convenzioni su come vengono impostate le relazioni parent-of. È possibile implementare una policy che non consenta transizioni in contrasto con la gerarchia della catena parent per impedire il merge diretto di una feature.

Le definizioni delle policy offrono molti vantaggi per la gestione delle pipeline:

• Un'unica definizione di pipeline, consapevole dei branch. Il pr.yml introdotto nella Parte 2 viene eseguito per ogni PR; il merge.yml viene eseguito per ogni promozione. Lo stesso flusso di lavoro copre feature, livelli e le transizioni tra di essi.
• La promozione è un merge, non una nuova distribuzione. Il passaggio dallo staging alla produzione è un git merge il cui effetto a valle è la promozione di un branch Lakebase. La migrazione viene applicata una sola volta a ciascun livello, convalidata prima nel livello precedente, proprio come avviene per il codice convalidato nelle fasi precedenti.
• Nessun disallineamento tra "l'ambiente di test" e la produzione. Ogni livello discende dallo stesso parent. La differenza di schema (schema diff) tra due livelli qualsiasi è un elemento reale e calcolabile: lo schema è un'unica catena di pagine con marcatori di divergenza, non due installazioni distinte di software di database. Ciò consente ai team di non dover gestire una flotta di server di database da aggiornare e correggere.

Rollback tramite repoint. Una promozione errata viene ripristinata indirizzando l'applicazione allo snapshot del tier precedente alla promozione. Lo snapshot stesso è un altro branch, il che consente ai team di rimediare a deployment difettosi.

Attribuzione dei costi per project_id, branch_id, endpoint_id. Unity Catalog acquisisce i metadati automaticamente. Una query SQL sulle tabelle di audit e fatturazione risponde a chi ha creato quale branch, quando è stato creato il branch e quanto costa mantenerlo attivo.

Anche il gran numero di istanze di database diminuisce drasticamente. Un mondo a sei istanze di ambiente (prod, staging, UAT, QA, perf, demo) si riduce a un unico parent Lakebase con una gerarchia di branch a lungo termine collegati al parent. L'istanza utilizzata per il provisioning, il monitoraggio e l'applicazione di patch è ora un branch logico con la stessa struttura dei dati della produzione, regolato dalle stesse policy della produzione, che si ripristina allo stato di produzione in un secondo quando necessario.

Diverse convenzioni consentono di creare molti tipi diversi di branch come parent; una convenzione comune consiste nel mantenere un branch che contenga lo schema del database e i dati di riferimento, in modo che chiunque possa creare un branch da esso e popolarlo con dati di test o eseguire test automatizzati che creano dati reali, evitando conflitti con lo staging o altri branch

Cosa fare ora: il modello di autorizzazione

Pratica #10 Nel playbook della Parte 2 abbiamo discusso della governance progettata una sola volta ed ereditata per branch. Vediamo come viene implementata.

Il lavoro di progettazione non blocca l'esecuzione a runtime. Si tratta di un design strutturale che le attività comuni possono poi applicare.

Le decisioni da prendere ora, prima che il team cresca o vengano aggiunti agenti:

• Creazione di branch da ciascun tier. Creare un fork dalla produzione richiede un'autorizzazione diversa rispetto a creare un fork dallo staging o da una feature. L'impostazione predefinita dovrebbe essere: le feature creano fork dal tier di ingresso (inferiore), mai dalla produzione. I fork di produzione sono riservati ai flussi di hotfix e ripristino.
• Promozione tra tier. Una promozione da “feature a staging” riguarda la code review. Una promozione da “staging a produzione” riguarda il coordinamento del rilascio. Si tratta di due passaggi separati con revisori distinti, il che garantisce indipendenza ai team di business e di sviluppo.
• Lettura vs. scrittura. L'accesso in lettura ai dati con struttura di produzione su un branch non richiede la stessa autorizzazione dell'accesso in scrittura a quel branch. Molti ruoli di ingegneria hanno bisogno della lettura; pochi hanno bisogno della scrittura.
• Policy di Unity Catalog. Le policy di Unity Catalog come il mascheramento, i filtri di riga e le autorizzazioni a livello di colonna si applicano alla produzione. Tali policy vengono ereditate per impostazione predefinita da ogni branch discendente; le eccezioni specifiche per tier (ad esempio, un tier QA con PII sintetizzati per i test di carico) vengono dichiarate una sola volta.
• Acquisizione dell'audit trail. Ogni creazione di branch, ogni promozione, ogni applicazione di migrazione, ogni pattern di accesso, in un unico punto interrogabile.

Il principio che fa funzionare tutto questo su scala di team è: i ruoli dichiarano, la policy applica. Il platform engineer dichiara la gerarchia dei tier, il modello di autorizzazione, i percorsi di promozione e la postura delle policy di Unity Catalog. La policy rifiuta qualsiasi transizione che contraddica quanto dichiarato. Non esiste alcun caso in cui un essere umano o un agente possa ignorare un limite dichiarato riprovando l'operazione in una forma diversa.

Questo è il lavoro da fare oggi, prima che il team raggiunga i cinquanta sviluppatori e gli agenti creino branch più velocemente di quanto qualsiasi essere umano possa esaminarli. Il framework è l'elemento che tiene unito il team grazie a convenzioni e guardrail condivisi. Tutto il resto opera al suo interno.

Il nuovo ruolo: da DBA a platform engineer

Vent'anni fa, la conclusione del saggio del 2003 Evolutionary Database Design faceva eco a quanto segue:

“L'uso delle tecniche che descriviamo qui potrebbe sembrare un sacco di lavoro, ma in realtà non richiede un numero enorme di persone. In molti progetti abbiamo avuto circa trenta sviluppatori e un team (compresi QA, analisti e management) di quasi cento persone. In un giorno qualsiasi avevamo un centinaio di copie di vari schemi sulle workstation delle persone. Eppure, tutta questa attività richiedeva un solo DBA a tempo pieno, con un paio di sviluppatori che comprendevano il funzionamento del processo e del workflow.”

Questo argomento si proietta nel 2026 con cinque elementi di supporto.

1. Il rapporto regge, con maggiore margine per ciascun DBA. Un DBA a tempo pieno ogni ~100 persone, con gli stessi oltre cento branch simultanei attivi, comporta un costo inferiore per branch perché la creazione di un branch è ora un'operazione sui metadati che richiede un secondo. Il rapporto non è l'aspetto fondamentale. Lo è invece il modo in cui il DBA impiega le sue ore di lavoro.

2. Il lavoro si sposta più in alto nello stack. Le ore che nel 2003 venivano dedicate al provisioning dell'infrastruttura, al provisioning degli schemi, al controllo degli accessi e a occasionali interventi manuali ora si spostano sulla progettazione delle policy di branching, sulle policy di mascheramento, sui workflow di promozione e sull'osservabilità dell'audit trail. Gli artefatti concreti: bot di schema-diff che pubblicano su ogni PR, job pianificati che ripristinano i branch di sviluppo ogni notte, dashboard di osservabilità che tracciano il ciclo di vita dei branch e la conformità al TTL, definizioni di CI che vincolano i merge alla convalida dello schema. Si tratta di un lavoro di progettazione della piattaforma, un'attività di ordine molto più elevato rispetto a prima.

3. Gli agenti entrano in gioco. Qualcosa con cui il saggio del 2003 non doveva fare i conti era la scrittura di codice da parte degli agenti. Neon segnala circa mezzo milione di branch al giorno, di cui oltre l'80% creato da agenti. Un singolo DBA non può gestire un simile volume tramite ticket. L'evoluzione del ruolo in platform architect è l'unica strada percorribile su scala di agenti.

4. I numeri diventano concreti. Un team di sei sviluppatori genera in genere più di 30 ticket operativi per sprint nel vecchio modello (provisioning, revisioni degli schemi, aggiornamenti dei dati, concessioni di accesso). Nel modello nativo per i branch: meno di 5 revisioni di policy ad alto valore per sprint. Il lavoro ripetitivo (toil) del DBA scende da oltre 20 ore alla settimana a meno di 5, e l'MTTR passa da oltre 4 ore a meno di 30 minuti. Questa riduzione del lavoro ripetitivo può aiutare il DBA a collaborare con gli sviluppatori per trovare soluzioni ottimali per le feature in fase di sviluppo.

5. L'audit trail diventa una dashboard strategica. Ciò che prima richiedeva il riferimento incrociato di tre servizi e tre linguaggi di query ora è una singola query SQL sulle tabelle di sistema della piattaforma. Ogni branch, ogni azione, ogni costo, ogni evento di governance in un unico posto. Il DBA non deve creare manualmente questa vista; ci pensa la piattaforma.

Nella prefazione a Refactoring Databases (2006), Martin Fowler auspicava che il libro rappresentasse "solo un primo passo" verso strumenti in grado di automatizzare il refactoring dei database così come gli IDE automatizzano il refactoring del codice. Il branching è il passo successivo. Ciò che Fowler sperava nel 2006, ovvero una gestione disciplinata delle modifiche ai database alla velocità del codice, è ciò che la piattaforma offre oggi. Il DBA progetta la disciplina; la piattaforma la applica.

Il titolo del nuovo ruolo varia (platform engineer, database platform owner, o ancora DBA solo di nome). La sostanza è la stessa: la persona che progetta il framework all'interno del quale operano tutti gli altri.

Agenti con le stesse capacità

Pratica #11 Nella Parte 2 abbiamo descritto l'agente di codifica come professionista con la stessa capacità di branching. Parliamone.

Gli agenti ottengono l'accesso ai branch, non alla produzione. Le stesse regole di workflow che si applicano a Jen si applicano all'agente. I test vengono eseguiti su un database reale in un branch, non su mock che un agente potrebbe modificare o eliminare. Le differenze di schema (schema diff) vengono applicate a ogni PR, indipendentemente da chi ha creato la migrazione. Le policy che proteggono Jen proteggono anche l'agente.

But the policies alone are not enough. Agents, left undirected, are like junior developers.

Uno sviluppatore junior, a cui viene assegnato un ticket per una funzionalità senza ulteriori indicazioni, può produrre codice che compila, test che superano i controlli e uno script di migrazione che si applica senza problemi. Il codice potrebbe però duplicare una logica già presente altrove nella codebase, introducendo ridondanze. La migrazione potrebbe aggiungere una colonna con il nome corretto ma con il tipo errato. Il test potrebbe essere superato solo perché verifica il percorso ideale (happy path). Nessuno di questi errori emerge quando la CI è verde; si presentano sei settimane dopo, quando qualcun altro deve estendere il lavoro.

Gli agenti fanno la stessa cosa, ma molto più velocemente e in volumi più elevati.

Senza una guida esplicita, un agente:

• Reinventerà un pattern già presente nella codebase.
• Creerà una modifica dello schema che sembra corretta ma salta i meccanismi di transizione del refactoring designato (ad esempio, elimina una colonna senza prima spostare i dati, o aggiunge una colonna NOT NULL senza aggiornare le righe esistenti).
• Scriverà test che superano i controlli basandosi sulla struttura dei dati che ha immaginato, e non su quella realmente esistente in produzione.
• Creerà migrazioni che si applicano correttamente ma che producono uno stato incoerente in caso di rollback.
• Stratificherà astrazioni su astrazioni per implementare una piccola modifica.

Il substrato rende attendibile la barra verde (niente mock; un database reale su un branch). Ciò che non fa, tuttavia, è rendere il codice manutenibile.

Il team rende il codice manutenibile attraverso quattro elementi di rinforzo:

• Guardrail: il modello dei permessi. Gli agenti non possono creare branch a partire dalla produzione, non possono effettuare promozioni tra tier e non possono applicare migrazioni a un tier di cui non sono proprietari. Il substrato rifiuta queste operazioni.
• Pattern: i refactoring designati. Il catalogo del 2006 su databaserefactoring.com elenca oltre 70 refactoring con meccanismi di transizione espliciti. Un agente guidato ad "applicare il refactoring Split Column" produce una migrazione diversa rispetto a un agente guidato a "dividere questa colonna".
• Workflow: la macchina a stati del source-control-management (SCM). Gli agenti seguono una sequenza di stati separati da gate bloccanti. Il substrato rifiuta le transizioni che non soddisfano il contratto dichiarato.
• Review: gli esseri umani nel ciclo delle PR. Il diff dello schema è visibile su ogni PR, con il DBA coinvolto nel percorso di revisione. La pratica n. 1 rielaborata nella Parte 2 ha reso asincrono questo processo; su scala di team, con la presenza di agenti, questa revisione asincrona è ciò che individua le anomalie sfuggite ai test.

Il workflow SCM è quello portante. Nel Lakebase App Dev Kit, il source control management copre molto più del semplice branch di codice: copre il branching accoppiato (il branch di codice e il branch Lakebase gestiti come un'unica unità, come introdotto nella Parte 1). Questo branching accoppiato, fornito come funzionalità nel substrato comune del Lakebase App Dev Kit, applica guardrail comuni come i merge che contraddicono la gerarchia, la migrazione che viaggia insieme al branch, i gate di CI e il merge che applica la migrazione al tier padre. Il dev kit fornisce questo workflow SCM sotto forma di macchina a stati eseguibile.

La Fig. 4 sopra descrive i cinque stati durante lo sviluppo: scaffold-complete, feature-claimed, pr-ready, ci-green, merged. Ogni transizione tra stati diversi è guidata da un comando CLI (lakebase-scm-claim-feature-branch, lakebase-scm-prepare-pr, lakebase-scm-wait-ci, lakebase-scm-merge). Ogni comando CLI convalida le precondizioni prima di eseguire il lavoro, esegue la transizione e scrive il nuovo stato in .lakebase/workflow-state.json (una superficie di gate con schema convalidato). Un gate fallito lascia la macchina ripristinabile allo stato precedente. I gate sono bloccanti, non consultivi.

Gli agenti chiamano queste CLI, non possono inventare un percorso parallelo. Il substrato si rifiuta di far avanzare la macchina a stati in caso di errore di precondizione: un feature branch associato al tier errato viene rifiutato; un tentativo di merge prima che la CI sia verde viene respinto; un file di stato incoerente blocca il gate successivo. I contratti di handoff sono di competenza del ruolo di scrum master; il substrato li fa rispettare. Le decisioni strutturali (la gerarchia dei tier, il tier di origine per una funzionalità, il percorso di promozione) appartengono all'architect o allo scrum master, vengono registrate e quindi rispettate dal substrato. Il substrato non inventa mai un tier o un elemento padre; rispetta quanto dichiarato e rifiuta le transizioni che lo contraddicono.

Questo è il framework che scardina il modo in cui i team hanno utilizzato gli agenti finora. L'integrazione ingenua tratta un agente come un ingegnere senior in una finestra di chat: si fornisce il contesto, si chiede l'output e si itera. Questo approccio funziona su scala di un singolo sviluppatore, ma fallisce su scala di team, perché il "contesto" dell'agente non può essere esaminato, governato o riprodotto. Tratta invece l'agente come uno sviluppatore junior: assegnagli un compito circoscritto e documentato all'interno di una macchina a stati eseguibile, convalida il suo output rispetto a uno schema, fai avanzare il gate e ripeti. Il substrato applica le regole; il file di stato del workflow è l'API.

Voci del playbook per le pratiche su scala di team

La Parte 2 ha introdotto le pratiche n. 10 e n. 11 tra le Pratiche emergenti per il 2026

Pratica n. 10: Governance progettata una sola volta, ereditata per branch

Regola. Il modello dei permessi e le policy di Unity Catalog per gestire il controllo degli accessi e l'acquisizione dell'audit trail sono progettati una sola volta sul trunk e vengono ereditati automaticamente da ogni branch discendente.

Perché questa è diventata un'abitudine duratura? Su scala di team, la governance deve essere una funzione del DBA o del platform engineer, non una disciplina che uno sviluppatore deve ricordarsi di applicare. I branch vengono creati e distrutti in pochi secondi; la configurazione manuale della governance per singolo branch vanificherebbe il risparmio di tempo generato dal branching.

Funzionamento:

• Dichiarare la gerarchia dei tier: quali branch a lungo termine esistono, quali sono i loro collegamenti padre, quale approccio di governance adotta ciascun tier.
• Dichiarare i limiti dei permessi: chi può creare branch a partire da ciascun tier, chi può effettuare promozioni tra tier, chi ha permessi di lettura rispetto a quelli di scrittura.
• Dichiarare l'ereditarietà delle policy di Unity Catalog: mascheramento, filtri di riga e quali permessi a livello di colonna vengono ereditati dal padre per impostazione predefinita; le eccezioni specifiche per tier vengono dichiarate una sola volta. La propagazione automatica su tutti i tipi di policy di Unity Catalog è in fase di completamento; progetta il framework pensando allo stato finale di destinazione.
• Dichiarare l'acquisizione dell'audit trail: ogni creazione di branch, ogni promozione, ogni applicazione di migrazione e ogni pattern di accesso finiscono automaticamente in tabelle di sistema interrogabili.
• Il DBA o il platform engineer applicano le regole tramite policy. Qualsiasi transizione che contraddica il modello dichiarato viene rifiutata.

Anti-pattern. Configurare la governance per singolo branch a runtime. Il vantaggio di dichiararla una sola volta sta nel fatto che il framework regge anche quando i branch vengono creati più velocemente di quanto un essere umano possa esaminarli. La configurazione manuale per singolo branch ricrea lo stesso collo di bottiglia che il branching aveva appena rimosso.

Dove si spinge il team di Jen. L'ingegnere di piattaforma o il DBA di Jen ha dichiarato la gerarchia dei livelli alla creazione del progetto. Ogni branch creato da Jen, dai suoi colleghi o dagli agenti del team eredita la configurazione dichiarata di mascheramento, permessi e audit. Quando il team aggiunge un nuovo livello, il framework registra il nuovo collegamento principale; le funzionalità in corso mantengono il loro genitore originale (nessuna riassegnazione retroattiva del genitore); le nuove funzionalità fanno il fork dal nuovo livello di ingresso.

Pratica #11: Agente come professionista con la stessa capacità di branching

Regola. Gli agenti operano all'interno della macchina a stati eseguibile del flusso di lavoro SCM: cinque stati, gate di blocco tra di essi, file di stato con schema validato. Le stesse regole del flusso di lavoro governano Jen e l'agente; un substrato comune le applica indipendentemente da chi stia agendo.

Perché questa è un'abitudine duratura ora? La creazione di branch è un'operazione sui metadati, quindi il volume gestito dagli agenti è fattibile. Il substrato sviluppato per l'utilizzo da parte degli agenti può rifiutare transizioni che contraddicono la gerarchia dei livelli dichiarata o lo stato del gate registrato. Non c'è un contesto della finestra di chat su cui ripiegare; solo l'artefatto su disco (workflow-state.json) supera il confine tra le transizioni di gate.

Meccanica:

• La macchina a stati SCM ha cinque stati: scaffold-complete, feature-claimed, pr-ready, ci-green, merged. Ogni transizione è guidata da una CLI; ogni CLI convalida le precondizioni prima di eseguire il lavoro.
• La superficie del gate è .lakebase/workflow-state.json, convalidata rispetto a scm-workflow-state.schema.json. Ogni transizione scrive il nuovo stato e gli invarianti necessari al gate successivo.
• Le decisioni strutturali (gerarchia dei livelli, livello di origine per funzionalità, percorso di promozione, contratti di handoff) appartengono ai ruoli (architetto o scrum master), vengono registrate e quindi applicate dal substrato.
• Gli agenti chiamano le CLI. Il substrato applica le regole; gli agenti non possono aggirarle. Un gate fallito lascia la macchina a stati ripristinabile allo stato precedente; l'agente non "riprova in modo diverso".
• I gate di CI eseguiti all'interno di pr-ready su ci-green testano un database Postgres reale su un branch, con il diff dello schema pubblicato sulla PR. Lo stato reale del database è ciò su cui viene misurato il lavoro dell'agente.

Anti-pattern. Trattare un agente come un ingegnere senior in una finestra di chat usando "scarica il contesto e chiedi l'output" funziona su scala di un singolo sviluppatore, ma si interrompe su scala di team perché il "contesto" non può essere esaminato, governato o riprodotto. Usa invece il modello artifact-as-API: gli agenti LEGGONO workflow-state.json e gli input documentati per la loro fase; SCRIVONO gli output documentati; i validatori controllano; il gate successivo si attiva solo quando il contratto è rispettato.

Dove si spinge il team di Jen. Ogni agente nel team di Jen opera all'interno della stessa macchina a cinque stati in cui operano Jen e i suoi colleghi. Il ruolo di scrum master possiede i contratti di handoff; il substrato rifiuta le transizioni che non li soddisfano. Un agente non può rilasciare una funzionalità di cui è stato fatto il fork dal livello errato; un agente non può eseguire il merge prima che la CI sia verde; un agente non può bypassare l'artefatto schema-diff. Il framework regge indipendentemente da chi o cosa abbia avviato l'azione.

TDD come livello opzionale intrecciato in cima

La pratica #11 stabilisce il flusso di lavoro SCM come base di riferimento: ogni consumatore del kit lo segue, sia agenti che umani. Il TDD è una considerazione a parte che si sovrappone a quella base per i team che desiderano una disciplina basata sui test (test-first). È opzionale; i gate SCM sono obbligatori indipendentemente dal percorso.

Perché i test sono importanti, anche prima del TDD: quando gli agenti scrivono codice, i test sono l'unico strumento di controllo che scala. Kent Beck, nella sua intervista del 2026 Pragmatic Engineer, ha menzionato pubblicamente questa modalità di errore: ha difficoltà a impedire agli agenti IA di eliminare i test per farli passare. La barra verde è facile da soddisfare quando nulla nel ciclo costringe l'agente a confrontarsi con la forma reale del sistema. I mock rendono questo aspetto banale. Anche i sostituti in memoria lo fanno.

Il branching rende onesta la barra verde a livello di dati. Un database reale su un branch reale è ciò contro cui l'agente sta effettuando i test; i vincoli dello schema rifiutano gli inserimenti di righe non corrispondenti, le chiavi esterne rifiutano gli orfani, la forma reale dei dati espone presupposti che il mock avrebbe assorbito silenziosamente, l'agente non può eliminare le tabelle. Il costo della falsa conformità aumenta con questi guardrail.

Ma il substrato è necessario, non sufficiente. I test devono provenire da qualche parte. Se l'agente li scrive, l'agente può anche eliminarli. Questo è il divario che il TDD colma.

Il flusso di lavoro TDD si sovrappone al flusso di lavoro SCM. Si attiva tra gli stati SCM feature-claimed e pr-ready; richiama SCM per le operazioni sui branch (i branch degli esperimenti di ciclo utilizzano la primitiva SCM sottostante); non richiama SCM verso l'alto. La dipendenza è unidirezionale. I team che non desiderano il livello TDD possono rilasciare funzionalità modificando direttamente il branch della funzionalità e soddisfare comunque ogni gate SCM.

Il Lakebase App Dev Kit distribuisce il flusso di lavoro TDD come una seconda macchina a stati con i propri agenti per ruolo e validatori di gate:

• Spec-author trasforma la narrazione del richiedente in un artefatto di funzionalità strutturato, con schema validato.
• Architect-reviewer mappa i requisiti non funzionali e i principi architetturali della funzionalità in decisioni architetturali, con output come architecture.json più testo descrittivo.
• Test-strategist produce l'elenco dei test e gli scenari per criterio di accettazione, con output come test-list.json più markdown renderizzato. Ogni NFR ha almeno un criterio di accettazione (AC); ogni AC ha uno scenario.
• Scrum-master orchestra i cicli di compilazione. Ogni ciclo esegue il fork di un branch di esperimento (utilizzando il substrato SCM sottostante), esegue un agente driver per implementare l'AC successivo, esegue un agente navigatore per esaminare e convalidare il risultato.
• Driver e navigator sono lo scrittore di test e lo scrittore di codice del ciclo interno, accoppiati, RED-GREEN-REFACTOR.

Ogni ruolo ha input e output documentati, convalidati rispetto a uno schema. Ogni agente riceve solo i suoi input documentati; gli output vengono convalidati prima dell'esecuzione del ruolo successivo. L'artefatto è l'API tra i ruoli; lo schema è il controllo del tipo. Un artefatto mancante viene trattato come un gate fallito. Un artefatto malformato viene trattato come uno mancante. Il livello TDD prende in prestito lo stesso modello artifact-as-API stabilito dalla Pratica #11 per SCM.

Il livello TDD si trova nella Guida di accompagnamento: Lakebase App Dev Kit (open-source, con un e-book di accompagnamento per i professionisti umani). Le macchine a stati SCM e TDD, i contratti degli agenti per ruolo, i controlli di conformità degli artefatti e i validatori dei gate vengono tutti distribuiti come CLI che qualsiasi orchestratore (il kit, l'estensione dell'IDE, un job di CI, una sessione di shell umana) può chiamare.

In breve: SCM è la base di riferimento (Pratica #11). Il TDD è un livello superiore. Il branching rende onesti i test; il TDD fa sì che i test vengano prima; il kit rende eseguibili entrambi i flussi di lavoro.

Cosa mostra il team di Jen

La Parte 1 ha guidato Jen attraverso una funzionalità: ha associato un branch di codice a un branch Lakebase, ha eseguito una migrazione reale su dati strutturati come quelli di produzione in pochi secondi, ha effettuato test senza mock, ha aperto una PR con il diff dello schema pubblicato inline per la revisione e ha eseguito il merge con la migrazione applicata e i branch effimeri ripuliti. Il cambiamento del database è diventato parte del normale sviluppo.

La parte 2 ha definito il playbook: le sette pratiche del 2003, i limiti che ne hanno mantenute cinque a livello di aspirazione fino al 2026, le stesse sette rielaborate una volta introdotto il branching, oltre a due nuove pratiche che la tecnologia rende possibili per il singolo sviluppatore. Nove pratiche nel lavoro quotidiano, altre due che emergono su scala di team.

La parte 3 ha portato il playbook all'interno del team. Ha definito la topologia dei tier, descrivendo come i branch a lungo termine risiedano all'interno di un unico parent Lakebase, come il modello di autorizzazione diventi l'artefatto di progettazione del platform engineer, dichiarato una sola volta e applicato dal substrato (Pratica #10). Come il ruolo del DBA completi la sua evoluzione in platform architect, con cinque conferme della tesi sul personale del 2003. Gli agenti entrano nel workflow con la stessa funzionalità, all'interno della macchina a stati eseguibile del workflow SCM, con il substrato che applica i gate indipendentemente da chi o cosa stia agendo (Pratica #11). Il TDD è un livello opzionale integrato: una disciplina basata sul "test-first" con ruoli dedicati, gate e contratti di artefatti, per i team che lo desiderano.

La guida Companion: Plugin Walkthrough copre la Lakebase SCM Extension per VS Code e Cursor end-to-end.

Il Companion: Lakebase App Dev Kit, con un e-book di accompagnamento per i professionisti umani, copre il workflow TDD sopra descritto: le macchine a stati SCM e TDD, gli agenti per ruolo, i validatori dei gate e i contratti di artefatti che rendono sicuro l'inserimento degli agenti nel team.

La metodologia è stata chiara per vent'anni. La funzionalità tecnica è arrivata nel 2026. Il playbook per professionisti umani e agenti è ora operativo. Il team di Jen è composto da cinquanta sviluppatori e una flotta di agenti; il workflow è lo stesso.

Conclusione: la possibilità di creare branch di un database offre ora un'immensa flessibilità al team di sviluppo per il provisioning dei database, la creazione di test su schemi reali, l'esecuzione della CI per ogni creazione di PR sul proprio database e la possibilità per gli agenti di lavorare in questo modo, il tutto con il framework di governance di Unity Catalog che applica le policy.

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