Présentation de Consort : le développement piloté par les tests sur une base de données avec branches

Pendant 25 ans, j'ai conçu des logiciels en m'appuyant sur les pratiques avec lesquelles j'ai grandi : le TDD de Kent Beck, le Refactoring de Martin Fowler, le Clean Code d'Uncle Bob, le Continuous Delivery de Jez Humble et Dave Farley, et l'Evolutionary Database Design de Pramod Sadalage et Scott Ambler.

Avec les pratiques modernes de développement logiciel, le code peut être divisé en branches, les environnements sont conteneurisés et l'infrastructure devient du code. Mais une partie de la pile technologique n'a jamais suivi le mouvement : la base de données. Elle restait là, tel un monolithe rigide, et nous devions accepter de nombreux contournements, comme l'utilisation de mocks au lieu de données réelles, un environnement de staging partagé et des modifications de schéma exécutées comme une cérémonie délicate.

Cela fait un moment que je discute avec des équipes de développement logiciel de Lakebase Postgres et de la façon dont cela change nos habitudes. Vous m'avez peut-être déjà entendu dire : Créez des branches pour votre base de données comme vous le faites pour votre code. Mais qu'est-ce que cela signifie en pratique, et comment l'appliquer ?

Ce qui change avec la création de branches de base de données

Les tests d'intégration reviennent au cœur de la boucle interne

Tester par rapport à une base de données réelle était autrefois une préoccupation de la boucle externe. Déployer une base de données, l'alimenter avec un schéma et des données, gérer les versions du schéma, et faire cela pour chaque test unitaire était trop coûteux, alors je ne le faisais pas. Personne ne le faisait. À la place, nous écrivions des tests unitaires par rapport à des objets fictifs (mocks), non pas parce que les mocks étaient bons, mais parce qu'une base de données réelle dans la boucle interne était hors de portée. Et nous savons que les mocks dérivent avec le temps ; ils se décalent du comportement réel de la base de données et plus vous les maintenez, moins ils vérifient le comportement réel.

La création de branches par copie sur écriture (copy-on-write) élimine la raison d'être des mocks. Vous créez une branche isolée de la base de données réelle en un temps pratiquement constant, quelle que soit la taille des données. Le premier test que j'écris, façon TDD, s'exécute sur une branche active de données réelles, pas sur une simulation. Je peux exécuter des tests destructifs, tout casser, bousiller mon schéma, sans jamais toucher au travail du reste de l'équipe. C'est ma branche. Quand j'ai fini, je la jette.

Le code et le schéma sont livrés ensemble

Puisque le schéma voyage désormais sous forme de migrations versionnées (Alembic, Flyway ou Knex, selon la pile technologique), une modification de schéma et le code dont elle dépend se déplacent ensemble comme une seule unité. Vous fusionnez le schéma (pas les données), et le code s'aligne avec lui. Deux ingénieurs à qui j'ai montré cela, dans des équipes différentes, ont utilisé la même expression pour le décrire : le Data CD.

La panne de production de 2 heures du matin est détectée avant de se produire

Quand quelque chose casse en production, c'est généralement à 2 heures du matin, et vous devez faire de l'ingénierie inverse pour comprendre ce qui a changé. La création de branches inverse la donne. À chaque pull request, puis lors de la fusion, vous créez une nouvelle branche de base de données à partir de l'environnement cible, vous y exécutez les migrations et la suite complète de tests, et vous détectez la régression ou le conflit avant le déploiement. La modification de schéma figure dans la pull request sous forme de migration, de sorte que votre DBA l'examine directement en tant que propriétaire du code, et non comme un ticket dans une file d'attente en aval.

Promouvoir une modification de schéma était autrefois une cérémonie à haut risque. Maintenant, vous créez une branche de la prod, appliquez la modification, la testez de manière isolée et la promouvez. Faire la même chose sur une configuration Postgres cloud standard nécessite un tas de scripts DevOps fragiles et fait perdre un temps humain précieux.

Rien de tout cela n'est une simple fonctionnalité de base de données que l'on active. Il s'agit d'un changement de moment où les tests difficiles ont lieu, tout au début (shift left), dans la boucle même où vous écrivez le code.

Un framework de développement agentique avec création de branches de base de données

Maintenant que l'infrastructure pour la création de branches est là, ce qui manquait au débat, c'était un outil pour la mettre en œuvre dans une véritable boucle de développement. C'est pourquoi j'ai conçu Consort.

Consort est un framework de développement agentique open source qui utilise la création de branches Lakebase comme fondement de sa construction pilotée par les tests. Si vous connaissez Scrum, l'idée est dans le nom. Chaque rôle de l'équipe (product owner, auteur des spécifications, réviseur d'architecture, DBA, stratège de test et binôme navigateur/conducteur) devient un agent. Ils collaborent ensemble, dirigés par un chef d'orchestre, pour former un ensemble (un consort).

Le travail se déroule sur deux voies : une voie de conception axée d'abord sur les spécifications, où l'intention est convenue et figée, et une voie de construction qui exécute le cycle complet rouge/vert/refactorisation sur une branche active de la base de données réelle. Quelques composants permettent de maintenir l'ensemble cohérent lorsqu'un agent est celui qui écrit le code.

• L'agent dispose d'une limite réelle sur laquelle se baser. Donnez à un agent quelque chose de concret et il résoudra le problème, car il peut voir quand le code ne fonctionne pas. Donnez-lui un test hermétique et simulé (mocké), et il vous fournira volontiers un code qui semble réussir mais qui échouera dès que vous l'exécuterez sur une base de données réelle. Une branche active de données réelles constitue cette limite concrète ; l'agent ne peut pas faire de suppositions face à une base de données réellement présente.
• Le conducteur ne peut pas changer les règles du jeu. Le rôle qui écrit le code ne peut pas modifier un test pour le faire réussir. La seule exception est un remplacement légitime, une story ultérieure qui retire un ancien test de manière justifiée. Le statut vert signifie que le test s'est exécuté et a réussi sur la branche réelle de la base de données, et non pas simplement parce que l'agent l'a affirmé.
• Le chef d'orchestre est du code, pas un agent. Le rôle que l'équipe appelle le scrum master devient une machine à états déterministe. Il oriente le travail, gère les étapes de validation humaine et redirige vers le rôle responsable en cas de conflit, de sorte que le processus qui pilote le cycle ne peut pas sauter une étape ou perdre le fil.
• Il ne perd pas de vue sa mission. Le reproche que j'entends le plus souvent à propos des autres frameworks est qu'après quelques jours, l'agent perd de vue sa mission, ce qui génère de la frustration et pousse à tout recommencer. Consort conserve les artefacts de chaque fonctionnalité dans une structure de répertoires dédiée que les agents lisent comme un contrat entre les rôles. C'est le même passage de relais qu'au sein d'une équipe réelle : chaque spécialiste examine le travail, ajoute ses remarques et le transmet au suivant.

Comme stratégie d'optimisation (pour que vos agents ne passent pas le début de chaque tour à tout analyser à nouveau), Consort fournit à chaque agent un package de contexte ciblé, les tests exacts à réussir, les exigences de conception et l'emplacement de ces tests, plutôt que de le laisser en roue libre sur l'ensemble du code. C'est avec un accès non ciblé que les agents dérivent et passent un temps infini à s'éparpiller sur le code pour essayer de comprendre quoi faire et où aller, jusqu'à en oublier le principe DRY.

L'architecte examine les spécifications avant qu'aucun code ne soit écrit et intègre la conception qui vous importe, y compris les exigences transversales, l'architecture en couches et des patterns comme DRY, SRP et SOLID. Cette conception initiale évite de se retrouver avec tout le code dans un seul fichier. Et lorsque vous souhaitez explorer des pistes, Consort lance des expérimentations parallèles pour une story, chacune sur sa propre branche de base de données et son propre arbre de travail (worktree), de manière totalement isolée, afin que vous puissiez essayer plusieurs approches et conserver la meilleure. Quand j'ai montré cela à d'autres ingénieurs, ils ont généralement reconnu immédiatement l'outil qu'ils essayaient de construire eux-mêmes.

Vous pouvez suivre tout le processus et orienter la direction. Un plug-in VS Code affiche vos branches Git et Lakebase associées à travers les différents niveaux, avec les modifications de code et de schéma dans une vue diff unique. Un tableau de bord d'observabilité affiche chaque étape en direct : chaque rôle, son prompt et les artefacts qu'il produit pour le rôle suivant. Et à chaque étape de validation, vous inspectez vous-même le logiciel fonctionnel, s'exécutant sur sa propre branche, avant d'approuver son passage à l'étape suivante.

Ce que Consort est (et n'est pas)

Consort est open source et soutenu par la communauté. C'est un projet que vous pouvez adopter, exécuter et recommander, avec son propre cycle de vie. Ce n'est pas une fonctionnalité de plateforme intégrée avec un SLA.

Vous n'avez pas besoin de reconfigurer votre pile technologique pour l'utiliser. Lakebase repose sur Postgres, donc votre application finale s'exécute dessus sans nécessiter de workflow de création de branches ; l'association des branches Git et Lakebase est une opération que vous effectuez pendant le développement.

Pendant 25 ans, la base de données a été la seule partie de notre pile technologique pour laquelle on ne pouvait pas créer de branches. Maintenant, c'est possible. C'est ce qui change, et c'est pourquoi j'ai conçu Consort.

Essayez-le vous-même

Vous avez seulement besoin de Lakebase. Obtenez-le avec l'édition gratuite.

Le reste de la pile technologique est ouvert – Java, Python ou Node – il fonctionne sur Claude et dispose d'un plug-in VS Code complémentaire.

Quand vous êtes prêt, cela ne prend que trois commandes :

/consort:start vous guide dans un projet. Commencez par l'exemple StockFlow. Il s'initialise avec trois fichiers, et vous pouvez le regarder se transformer en une base de code complète à partir de là.

Une (r)évolution dans la construction de logiciels

Si ce travail vous inspire et que vous souhaitez l'améliorer, je recherche d'autres contributeurs et propriétaires de code (codeowners). Si vous souhaitez participer, ou simplement voir comment fonctionne l'architecture interne, un article est disponible sur arXiv : https://arxiv.org/abs/2609.09671 ou visitez le dépôt : https://github.com/databricks-solutions/consort

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