Lakebase et SDLC agentique : le branching de bases de données pour les agents de codage

L'IA a modifié la façon dont les logiciels sont créés. À mesure que les agents de codage prennent une part croissante du travail de développement, les développeurs s'orientent de plus en plus vers leur orchestration. Exécuter plusieurs agents en parallèle devient la norme, et les outils ont évolué avec elle, des compétences et hooks jusqu'aux MCP, sous-agents, tous conçus pour rendre les agents plus sûrs et plus efficaces.

Pourtant, un élément essentiel au bon fonctionnement du workflow de développement reste souvent négligé : la base de données.

Chaque agent concurrent doit écrire du code, appliquer des modifications de schéma et exécuter des tests sur une base de données. Avec des environnements partagés, tels qu'une base de données unique de développement ou de staging typique des configurations traditionnelles, cela crée de vrais défis. Les agents peuvent entrer en conflit sur les modifications de schéma, s'interférer mutuellement ou recourir à des mocks qui ne reflètent pas les données réelles. C'étaient déjà des points de friction pour les développeurs, mais ils sont exacerbés par les agents de codage. Les agents avancent plus vite, fonctionnent en parallèle et ont besoin d'un environnement sûr pour éviter de mettre en danger les données de production ou d'exposer des données sensibles.

L'architecture Lakebase Postgres résout ce problème grâce au branching de base de données. Tout comme Git vous permet de créer des branches de code, Lakebase vous permet de créer une branche de toute une base de données en moins d'une seconde, quelle que soit sa taille. Il utilise le copy-on-write, de sorte que les branches partagent les données de la branche parente mais ne consomment du stockage supplémentaire que lorsqu'elles divergent. De plus, elles peuvent faire un scale-to-zero, ce qui signifie que les branches inactives n'engendrent aucun coût de calcul. C'est important lorsque vous exécutez plusieurs agents en même temps. Chaque branche est totalement isolée, permettant à un agent d'appliquer des migrations, d'exécuter des tests et de supprimer la branche une fois terminé.

Dans cet article, je vais vous montrer à quoi cela ressemble en pratique avec un workflow de bout en bout pour une boucle de développement Lakebase conçue autour d'agents de codage. Un dépôt d'exemple est disponible ici avec des exemples de workflows GitHub Actions pour réaliser ce qui est décrit dans les sections suivantes.

Vous préférez le voir en action ? Regardez la vidéo explicative ci-dessous.

Avant de commencer, une remarque sur les environnements avec Databricks. Une configuration courante lors de l'utilisation de Lakebase Postgres consiste à utiliser un espace de travail Databricks par environnement, tel que dev, staging et prod. La plupart des équipes voudront tirer parti des espaces de travail pour diverses raisons comme la sécurité et la conformité, bien qu'il soit également possible d'utiliser un seul espace de travail. De même, créer une branche à partir d'une base de données alimentée (seeded) plutôt que de la base de données de production est également courant, afin d'éviter d'exposer des données sensibles comme les PII. Dans cet article, nous utiliserons un seul espace de travail par souci de simplicité, mais les mêmes concepts fondamentaux s'appliquent aux configurations multi-espaces de travail et peuvent être mis en œuvre tout aussi facilement.

Bases de données sûres et isolées pour agents de codage parallèles

La principale perturbation des bases de données traditionnelles provient du travail simultané de plusieurs agents de codage. Lors du développement de nouvelles fonctionnalités ou de la résolution de problèmes, chaque agent a souvent besoin de lire le schéma de la base de données, d'appliquer des modifications, d'insérer des données de test et d'exécuter des tests. Sans isolation, ces agents peuvent s'interférer mutuellement ou corrompre une base de données partagée. Le branching de base de données offre à chaque agent un environnement isolé pour travailler de manière indépendante sans affecter les autres agents exécutés en même temps.

Un moyen pratique d'éviter les conflits de code au niveau local consiste à utiliser les worktrees Git. Un worktree donne à chaque agent son propre répertoire avec sa propre branche extraite, de sorte qu'il n'y a aucun conflit au niveau des fichiers entre eux. Les worktrees Git résolvent l'isolation du code pour les agents parallèles. Le branching Lakebase résout l'autre moitié : l'isolation de la base de données. En ajoutant un hook post-checkout au dépôt, chaque nouveau worktree obtient automatiquement sa propre branche de base de données. Une fois le développement terminé, l'agent ouvrira une PR. Le comportement de l'agent peut être guidé à travers des fichiers d'instructions de dépôt tels que AGENTS.md ou CLAUDE.md.

Voici un exemple de workflow utilisant Claude Code, des worktrees et le branching Lakebase pour un développement d'IA sécurisé :

• L'agent exécute claude -worktree feature-123
• Git crée un worktree pour la branche feature-123
• Un hook post-checkout se déclenche automatiquement, créant une branche de base de données
• L'agent dispose désormais de son propre répertoire de code et de sa propre base de données totalement isolée

Lorsque l'agent a terminé, il crée une PR. Ce comportement est défini dans le fichier d'instructions du dépôt. Une fois la PR créée, le worktree et la branche de base de données peuvent être supprimés. Une différence importante par rapport à Git est que les branches Lakebase ne sont pas fusionnées dans la branche principale. Comme le parent et l'enfant peuvent tous deux changer indépendamment, la réconciliation de leurs données peut rapidement devenir irréalisable. Au lieu de cela, les modifications de schéma sont suivies dans le code aux côtés de la logique d'application, puis transmises à la branche parente via des migrations à l'aide d'outils tels que Drizzle, Flyway, Liquibase ou Alembic.

Dans notre exemple, nous utilisons Drizzle. Lorsqu'une modification de schéma est nécessaire, l'agent ajoute la migration correspondante à la base de code. L'automatisation du déploiement applique ensuite cette migration lors du déploiement de l'application de prévisualisation, puis à nouveau lorsque la modification est fusionnée dans la branche principale.

Bases de données éphémères pour chaque Pull Request

Lorsqu'une Pull Request (PR) est ouverte, nous voulons valider et tester automatiquement le code par rapport à une vraie base de données avant que quoi que ce soit ne passe en production.

En utilisant des outils d'intégration continue, en l'occurrence GitHub Actions, une branche éphémère Lakebase est créée pour chaque PR, en tant qu'enfant de la branche de production. Cette branche devient l'environnement de base de données pour la PR. Des tests automatisés peuvent être exécutés dessus, une application de prévisualisation peut être déployée et les réviseurs peuvent valider la modification par rapport à une vraie base de données.

Comme la branche part de la production, la migration de schéma peut également être appliquée et testée avant que la modification n'atteigne la production.

Une fois la PR approuvée et fusionnée, le code de la fonctionnalité et les instructions de migration sont promus, et la branche Lakebase temporaire est supprimée.

Un workflow GitHub Actions courant ressemble à ceci :

• Une PR est ouverte vers main
• La CI appelle la CLI Lakebase pour créer une branche telle que pr-123
• L'outil de migration (Drizzle, Alembic, etc.) s'exécute sur la nouvelle branche de base de données dédiée
• Une application de prévisualisation est déployée et pointe vers la chaîne de connexion de la branche
• Un diff de schéma est généré et publié sous forme de commentaire dans la PR, indiquant exactement quelles tables, colonnes ou index ont changé
• Le réviseur valide à la fois le code et les modifications de la base de données
• Lorsque la PR est fermée ou fusionnée, la CI supprime la branche

Dans l'exemple du dépôt, nous déployons l'application avec Databricks Apps, mais le concept s'applique à n'importe quelle autre plateforme d'hébergement comme Vercel, Netlify, Cloudflare et bien d'autres.

Reproduction de bugs, migrations et tests avec les branches de bases de données

Au-delà des tâches de développement, la création de branches de base de données peut prendre en charge plusieurs autres flux de travail utiles. Ceux-ci ne sont pas implémentés dans le dépôt d'exemple, mais ils peuvent constituer des ajouts précieux à un flux de travail de développement Lakebase. Par exemple, avec la création de branches de base de données, vous pouvez créer une branche isolée à partir de la production à un instant précis, généralement juste avant l'apparition d'un bug, puis analyser le problème par rapport aux données réelles, reproduire le bug en toute sécurité et supprimer la branche une fois le correctif validé.

La création de branches peut également sécuriser les migrations de schéma. Avant de déployer une modification en production, vous pouvez créer automatiquement une branche de base de données, appliquer la migration, exécuter des tests et vérifier que l'application se comporte toujours comme prévu. Une fois la migration validée, cette même modification peut être promue en production.

Ces flux de travail sont puissants car ils permettent aux développeurs de travailler avec des données similaires à la production ou dérivées de celle-ci, en utilisant par exemple le masquage Unity Catalog, sans mettre la base de données en production en danger. Chaque branche est isolée et éphémère, ce qui en fait un environnement sûr pour le débogage, les tests et la validation.

Conclusion

Ensemble, ces modèles forment la boucle de développement Lakebase : une branche par agent, une branche par PR et des branches isolées pour la validation de la production.

Pour le SDLC agentique, la création de branches de base de données offre une fondation sûre et flexible pour les équipes de développement qui travaillent avec des agents de codage. Essayez la création de branches dès maintenant.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original