Portare il CI/CD dentro un database transazionale è più difficile di quanto sembri. Glaspoort, operatore di infrastruttura in fibra nei Paesi Bassi, lo racconta descrivendo come gestisce le modifiche allo schema del database dietro la propria applicazione, costruita direttamente sui prodotti Databricks e con Lakebase — il database OLTP serverless su Postgres — come store transazionale.
Il punto di partenza è il branching di Lakebase: un branch è una copia copy-on-write del Postgres di partenza, che non duplica i dati ma forka lo stato in modo istantaneo e diverge solo quando ci si scrive sopra. L’analogia con git è voluta: un feature branch corrisponde a un database branch. C’è però un vincolo critico: per fare il reset di un branch dal suo parent bisogna prima cancellare i suoi figli.
La trappola del reset-from-parent
Lo schema istintivo — un branch di sviluppo lungo-vivente da produzione, l’acceptance sotto sviluppo, le feature sotto ancora — porta a due problemi prevedibili: gli ambienti divergono da produzione e rinfrescarli diventa costoso. Per resettare development dal parent occorre eliminare acceptance e tutti i feature branch, ricreare gli ambienti, ricablare le connection string e riapplicare i grant. Un’operazione così pesante spinge il team a non farla, e si torna a testare su dati stantii.
La scelta di Glaspoort: sempre branch da produzione
La correzione è una riga di pensiero: ogni ambiente lungo-vivente è figlio di produzione, non di un altro ambiente. Development e acceptance stanno affiancati sotto produzione, così rinfrescarne uno non obbliga a cancellare l’altro. Nel loop quotidiano, ogni PR effimera (TTL di 1 ora) fa sì che la CI tagli un branch pr-xxxx fresco da produzione, archiviato alla chiusura per restare sotto il limite di default di 10 branch non archiviati per progetto. Le migration vengono rieseguite (con un controllo git diff per saltare i replay inutili) e testate insieme alla nuova app image su uno staging slot prima di toccare qualsiasi ambiente reale.
Il vero perno è che i database non vengono mai rimessi insieme via merge: una modifica si promuove rieseguendo le migration sul branch di destinazione. Le migration, non i database, sono la fonte di verità. Sulla scelta di merge Glaspoort ha optato per il modello “merge appena la CI è verde” (PR stacking), tenendo una crisis pipeline separata per gli hotfix urgenti.
Sul fronte sicurezza, l’app non conserva un segreto database di lunga durata: una password statica in Azure Key Vault genera una credenziale con TTL di 60 minuti, che il client rinnova prima della scadenza. I grant restano applicati a mano su produzione e i branch figli li ereditano a ogni refresh.
In sintesi
- Branchando sempre da produzione si evita la “trappola del reset-from-parent” e si mantengono gli ambienti allineati ai dati reali.
- Le migration come unica fonte di verità rendono ogni branch ricostruibile e usa-e-getta.
- Trade-off aperto tra PR stacking (velocità) e per-PR promotion (indipendenza e hotfix): Glaspoort ha scelto la velocità con una crisis pipeline di riserva.
Fonte: Branching databases like code: a CI/CD pattern for Lakebase, in production at Glaspoort — https://www.databricks.com/blog/branching-databases-code-cicd-pattern-lakebase-production-glaspoort
Hai qualcosa da aggiungere? Unisciti alla discussione.