Lakebase e SDLC agentico: branching dei database per gli agenti di coding

L'IA ha cambiato il modo in cui viene sviluppato il software. Man mano che gli agenti di codifica assumono una quota crescente del lavoro di sviluppo, i developer si stanno orientando sempre più verso la loro orchestrazione. Eseguire più agenti in parallelo sta diventando la norma e gli strumenti si sono evoluti di conseguenza, da skill e hook a MCP e subagenti, tutti progettati per rendere gli agenti più sicuri ed efficaci.

Tuttavia, un elemento fondamentale nel workflow di sviluppo viene ancora spesso trascurato: il database.

Ogni agente simultaneo deve scrivere codice, applicare modifiche allo schema ed eseguire test su un database. Con gli ambienti condivisi, come un singolo database di sviluppo o staging tipico delle configurazioni tradizionali, si creano problemi reali. Gli agenti possono andare in conflitto sulle modifiche allo schema, interferire tra loro o ricorrere a mock che non riflettono i dati reali. Questi erano già punti critici per i developer, ma vengono esacerbati dagli agenti di codifica. Gli agenti si muovono più velocemente, operano in parallelo e hanno bisogno di un ambiente sicuro per evitare di mettere a rischio i dati di produzione o esporre dati sensibili.

L'architettura di Lakebase Postgres risolve questo problema con il branching del database. Proprio come Git consente di creare branch del codice, Lakebase permette di creare il branch di un intero database in meno di un secondo, a prescindere dalle sue dimensioni. Utilizza la tecnica copy-on-write, in modo che i branch condividano i dati del branch padre ma consumino archiviazione aggiuntiva solo man mano che divergono. Inoltre, possono scalare a zero, il che significa che i branch inattivi non comportano costi di elaborazione. Questo è importante quando si eseguono più agenti contemporaneamente. Ogni branch è completamente isolato, consentendo a un agente di applicare migrazioni, eseguire test e disattivare il branch una volta terminato il lavoro.

In questo articolo, ti mostrerò come funziona in pratica con un workflow end-to-end per un ciclo di sviluppo di Lakebase basato su agenti di codifica. Un repository di esempio è disponibile qui con esempi di workflow di GitHub Actions per realizzare quanto descritto nelle sezioni seguenti.

Preferisci vederlo in azione? Guarda la video guida qui sotto.

Prima di iniziare, una nota sugli ambienti con Databricks. Una configurazione comune quando si usa Lakebase Postgres consiste nell'utilizzare un workspace Databricks per ciascun ambiente, ad esempio dev, staging e prod. La maggior parte dei team vorrà sfruttare i workspace per varie ragioni, come sicurezza e conformità, anche se è possibile utilizzare un unico workspace. Allo stesso modo, anche la creazione di branch da un database popolato iniziale (seeded) anziché dal database di produzione è una pratica comune, per evitare di esporre dati sensibili come i PII. In questo articolo utilizzeremo un singolo workspace per semplicità, ma i medesimi concetti di base si applicano alle configurazioni multi-workspace e possono essere implementati con la stessa facilità.

Database sicuri e isolati per agenti di codifica in parallelo

L'impatto principale sui database tradizionali deriva dall'operatività simultanea di più agenti di codifica. Quando sviluppano nuove funzionalità o risolvono problemi, ciascun agente deve spesso leggere lo schema del database, applicare modifiche, inserire dati iniziali (seed) ed eseguire test. Senza isolamento, questi agenti possono interferire tra loro o danneggiare un database condiviso. Il branching del database fornisce a ciascun agente un ambiente isolato per lavorare in modo indipendente senza influire sugli altri agenti in esecuzione nello stesso momento.

Un modo pratico per evitare conflitti di codice a livello locale consiste nello sfruttare le worktree di Git. Una worktree fornisce a ciascun agente la propria directory con il rispettivo branch verificato, evitando così conflitti a livello di file. Le worktree di Git risolvono l'isolamento del codice per gli agenti in parallelo. Il branching di Lakebase risolve l'altra metà del problema: l'isolamento del database. Aggiungendo un hook post-checkout al repository, ogni nuova worktree ottiene automaticamente il proprio branch di database. Al termine dello sviluppo, l'agente aprirà una PR. Il comportamento dell'agente può essere guidato tramite file di istruzioni del repository come AGENTS.md o CLAUDE.md.

Ecco un esempio di workflow che utilizza Claude Code, le worktree e il branching di Lakebase per uno sviluppo con IA sicuro:

• L'agente esegue claude -worktree feature-123
• Git crea una worktree per il branch feature-123
• Un hook post-checkout si attiva automaticamente, creando un branch di database
• Ora l'agente dispone della propria directory di codice e del proprio database completamente isolato

Quando l'agente ha terminato, crea una PR. Questo comportamento è specificato nel file di istruzioni del repository. Una volta creata la PR, sia la worktree sia il branch del database possono essere disattivati. Un'importante differenza rispetto a Git è che i branch di Lakebase non vengono riaccorpati nel branch principale. Poiché il parent e il child possono cambiare entrambi in modo indipendente, riconciliare i relativi dati può diventare rapidamente impraticabile. Al contrario, le modifiche allo schema vengono tracciate nel codice insieme alla logica dell'applicazione, quindi promosse nel branch parent tramite migrazioni utilizzando strumenti come Drizzle, Flyway, Liquibase o Alembic.

Nel nostro esempio utilizziamo Drizzle. Quando è necessaria una modifica allo schema, l'agente aggiunge la migrazione corrispondente al codebase. L'automazione del deployment applica quindi tale migrazione durante il deployment dell'applicazione di anteprima e nuovamente quando la modifica viene integrata nel branch principale.

Database effimeri per ogni Pull Request

Una volta aperta una Pull Request (PR), vogliamo convalidare e testare automaticamente il codice su un database reale prima che qualsiasi modifica arrivi in produzione.

Utilizzando strumenti di continuous integration (in questo caso GitHub Actions), viene creato un branch Lakebase effimero per ogni PR, come figlio del branch di produzione. Quel branch diventa l'ambiente di database per la PR. I test automatizzati possono essere eseguiti su di esso, è possibile distribuire un'applicazione di anteprima e i revisori possono convalidare le modifiche su un database reale.

Poiché il branch parte dalla produzione, è anche possibile applicare e testare la migrazione dello schema prima che la modifica arrivi in produzione.

Una volta approvata e integrata la PR, il codice della funzionalità e le istruzioni di migrazione vengono promossi e il branch temporaneo di Lakebase viene eliminato.

Un tipico workflow di GitHub Actions è il seguente:

• Viene aperta una PR sul branch main
• La CI chiama la CLI di Lakebase per creare un branch come pr-123
• Lo strumento di migrazione (Drizzle, Alembic, ecc.) viene eseguito sul nuovo branch di database dedicato
• Viene distribuita un'app di anteprima, puntata sulla stringa di connessione del branch
• Viene generata una diff dello schema e pubblicata come commento alla PR, mostrando esattamente quali tabelle, colonne o indici sono cambiati
• Il revisore convalida sia il codice sia le modifiche al database
• Quando la PR viene chiusa o integrata, la CI elimina il branch

Nell'esempio del repository, distribuiamo l'applicazione con Databricks Apps, ma il concetto si applica a qualsiasi altra piattaforma di hosting come Vercel, Netlify, Cloudflare e molte altre.

Riproduzione dei bug, migrazioni e test con i branch di database

Oltre alle attività di sviluppo, il branching del database può supportare diversi altri workflow utili. Questi non sono implementati nel repository di esempio, ma possono rappresentare preziose aggiunte a un workflow di sviluppo Lakebase. Ad esempio, con il branching del database, puoi creare un branch isolato dalla produzione in un determinato momento, in genere subito prima della comparsa di un bug, ed esaminare il problema confrontandolo con i dati reali, riprodurre il bug in tutta sicurezza e dismettere il branch una volta convalidata la correzione.

Il branching può anche rendere più sicure le migrazioni di schema. Prima di distribuire una modifica in produzione, puoi creare automaticamente un branch del database, applicare la migrazione, eseguire i test e verificare che l'applicazione continui a funzionare come previsto. Una volta convalidata la migrazione, la stessa modifica può essere promossa in produzione.

Questi workflow sono molto efficaci perché consentono agli sviluppatori di lavorare con dati simili a quelli di produzione o derivati dalla produzione, ad esempio utilizzando il mascheramento di Unity Catalog, senza mettere a rischio il database attivo. Ogni branch è isolato ed effimero, il che lo rende un ambiente sicuro per il debugging, il testing e la convalida.

Conclusione

Insieme, questi pattern formano il ciclo di sviluppo di Lakebase: un branch per agente, un branch per PR e branch isolati per la convalida della produzione.

Per l'SDLC basato su agenti, il branching del database offre una base sicura e flessibile per i team di sviluppo che lavorano con agenti di codifica. Prova tu stesso il branching.

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