Branch
Le branching dans Lakebase vous permet de gérer les versions, tester et faire évoluer votre environnement de données en toute sécurité, de manière similaire au branching de votre code dans Git. Vous pouvez créer instantanément des branches isolées et entièrement fonctionnelles pour le développement, l'expérimentation ou le test des modifications de schéma, sans impacter les charges de travail de production.
Par default, Lakebase crée une seule branch production lorsque vous créez un nouveau projet. Ceci est votre default branch, destinée à héberger les données de production de votre application.
Vous pouvez créer des Branch supplémentaires selon vos besoins pour les adapter à votre flux de travail. Par exemple, ajoutez une Branch development pour la construction et les tests, une Branch staging pour les tests de préproduction, ou créez des Branch par développeur pour une isolation complète. Chaque Branch fonctionne de manière indépendante, de sorte que les modifications apportées à un enfant n'affectent jamais son parent. Avec le Reset de Branch, vous pouvez refresh n’importe quelle Branch enfant à partir de son parent afin d’obtenir le schéma et les données les plus récents, et ce, sans script d’alimentation ni de suppression de données.
Fonctionnement des branches
Relations parent-enfant
Chaque Branch (sauf la Branch racine) a un parent. Ceci crée une hiérarchie :
production (root branch)
├── staging (child of production)
│ └── feature-test (child of staging)
└── development (child of production)
└── bugfix-branch (child of development)
This hierarchy gives you important isolation: changes you make to a child branch don't affect its parent, and changes to a parent don't automatically appear in children. This isolation extends to Postgres role state and databases as well: roles and databases created, GRANTs and REVOKEs applied, and role attributes modified on one branch have no effect on other branches. When you need updated data from the parent, you can reset the child branch. You can also create branches from any point in the parent's history, which is useful for point-in-time recovery, testing against historical data, or conformité scenarios.
Lorsque vous créez une Branch, vous choisissez de l'initialiser à partir des données actuelles ou d'un point spécifique dans le temps. Consultez Créer une branch pour obtenir des instructions pas à pas et des détails sur chaque option.
Stockage Copy-on-write
Lakebase utilise la technologie de copie sur écriture pour rendre le branchement parent-enfant efficace. Lorsque vous créez une nouvelle Branch, elle hérite à la fois du schéma et des données de son parent, mais partage le stockage sous-jacent par le biais de pointeurs vers les mêmes données. Ce n'est que lorsque vous modifiez des données que Lakebase écrit de nouvelles données. Cela signifie :
- Vos branches apparaissent instantanément ; la taille de votre base de données n'a aucune incidence sur le temps de création de Branch.
- La création de Branch n’a pas d’impact sur les performances de votre charge de travail de production.
Copy-on-write determines how Branch are stored, but how a Branch is billed depends on whether it expires. See How branching impacts Ressources consumption.
production branch child branch (at creation)
┌─────────────────┐ ┌─────────────────┐
│ [Data A] │◄──────│ → Data A │ (shared)
│ [Data B] │◄──────│ → Data B │ (shared)
│ [Data C] │◄──────│ → Data C │ (shared)
└─────────────────┘ └─────────────────┘
After modifying data in child branch:
┌─────────────────┐ ┌─────────────────┐
│ [Data A] │◄──────│ → Data A │ (shared)
│ [Data B] │ │ [Data B'] │ (changed)
│ [Data C] │◄──────│ → Data C │ (shared)
└─────────────────┘ └─────────────────┘
Only changed data is stored separately
Utilisation des branches
Branch Reset
La Reset de la Branch met à jour instantanément une Branch enfant pour qu'elle corresponde à l'état actuel de son parent. Ceci est utile lorsque vous souhaitez refresh votre Branch de développement ou de pré-production avec les dernières données de sa Branch parente. L'opération se termine instantanément en utilisant la technologie de copie sur écriture, et vos informations de connexion restent les mêmes.
La Reset de la Branch ne fonctionne que dans un sens (parent → enfant). Pour déplacer les modifications de l'enfant au parent, utilisez vos outils de migration standards pour appliquer les modifications de schéma. Consultez Reset a Branch pour les étapes détaillées et les scénarios.
Restauration à un instant T
Vous pouvez créer une branch à partir d'un point précis dans le temps au sein de votre fenêtre de restauration, ce qui est utile pour récupérer des erreurs de données comme les suppressions accidentelles, enquêter sur des problèmes passés ou accéder aux données historiques à des fins d'audit et de conformité. Par exemple, si une table critique a été supprimée hier à 10 h 23, vous pouvez créer une branch réglée sur 10 h 22 pour extraire les données manquantes. De même, vous pouvez créer des branches reflétant l'état de votre base de données à des dates spécifiques pour les rapprochements financiers, les audits réglementaires ou les analyses forensiques. Contrairement à la réinitialisation de Branch (qui met à jour une Branch existante sur place), la récupération ponctuelle crée une nouvelle Branch racine à partir de données historiques, tout en laissant votre Branch d'origine inchangée et opérationnelle. Consultez Restauration à un instant T pour plus de détails.
Types de Branch spéciaux
Branch default
Chaque projet Lakebase est créé avec une branch appelée production, mais vous pouvez désigner n'importe quelle branch comme default. La Branch default est exempte de la limite de compute actifs simultanément, garantissant ainsi qu'elle reste disponible à tout moment.
Branch protégées
Les branches protégées sont dotées de mesures de protection pour prévenir les modifications accidentelles. Elles ne peuvent pas être supprimées ou Reset depuis leur parent, et elles sont exemptes d'archivage automatique en raison d'inactivité. Les Branch protégées empêchent également la suppression de projets tant qu'elles existent, ce qui garantit que vous ne pouvez pas supprimer accidentellement une infrastructure critique. En outre, Lakebase donne la priorité aux données des Branch protégées dans son cache de stockage, privilégiant les performances des Branch protégées par rapport aux autres Branch. Chaque projet prend en charge une Branch protégée. Utilisez des branches protégées pour les données critiques, comme celles de production. Consultez les Branch protégées pour plus de détails.
Branch de récupération
Lakebase dispose d’un type de Branch spécial appelé « branch de récupération » qui est propre à la reprise après sinistre. En cas d’utilisation de la reprise après sinistre, si vous Trigger un basculement et que des transactions validées n’ont pas encore été répliquées vers un serveur secondaire, Lakebase conserve ces transactions non répliquées sous forme de branch de récupération une fois que le serveur principal d’origine est de nouveau en ligne. La Branch de récupération vous permet d’inspecter et de rapprocher les transactions de vos autres Branch. Cette fonctionnalité vous aide à prévenir les scénarios de « perte de données silencieuse ». Lakebase conserve les branches de récupération : vous devez les supprimer explicitement lorsque vous avez terminé. Reportez-vous à la reprise après sinistre pour plus de détails.
Impact de la création de branches sur la consommation de ressources
Avec les Branch, vous payez le compute et le stockage séparément.
Compute : chaque Branch a son propre compute que vous pouvez faire monter en charge de manière indépendante. Vous ne payez que pour les heures de compute actives. Les computes se désactivent lorsqu'ils sont inactifs. Cela signifie qu'une branch de développement que vous utilisez occasionnellement coûte bien moins cher que de faire fonctionner un serveur de développement dédié 24h/24 et 7j/7.
Stockage : la facturation du stockage pour une Branch dépend de son expiration ou non :
- Une Branch expirant n’est facturée que pour les données qui y sont modifiées. Grâce à la technique de copie sur écriture (« copy-on-write »), elle partage les données inchangées de son parent. Par exemple, si vous modifiez 1 Go de données sur une Branch expirant d’une base de données de 100 Go, vous payez environ 1 Go de stockage, et non une copie complète de 100 Go.
- Une Branch permanente, c’est-à-dire sans expiration, est facturée pour la totalité de sa taille de données, comme une base de données indépendante, même lorsque ses données ne diffèrent que légèrement de celles de sa parente.
Rendre une Branch permanente signifie que vous payez pour la totalité de sa taille de données, et non seulement pour les données qui y sont modifiées. Définir une Branch de manière à ce qu’elle n’expire jamais constitue toujours un choix délibéré : vous sélectionnez Jamais pour la fonction Suppression automatique lorsque vous créez la Branch, ou vous supprimez l’expiration d’une Branch existante. Si vous avez uniquement besoin d’une copie éphémère, conservez une expiration afin que la Branch soit facturée uniquement pour ce qui y est modifié. Voir la section Expiration des Branch.
Branch strategies
Voici quelques façons courantes dont les équipes organisent leurs Branch :
Simple (individus et petites équipes)
Utilisez votre default Branch avec une seule development Branch :
production
└── development
Votre Branch development est l'endroit où vous développez de nouvelles fonctionnalités en toute sécurité. Vous pouvez effectuer des modifications de schéma, ajouter des données de test et expérimenter sans aucun risque pour votre Branch de production. Lorsque vous êtes prêt, exécutez vos migrations de schéma testées contre production (à l'aide de votre outil de migration), puis Reset development pour start la fonctionnalité suivante avec des données actualisées.
Avec l'étape
Ajoutez une branch de staging pour les tests de préproduction :
production
├── staging
└── development
Si vous avez besoin de tests de pré-production, maintenez une Branch staging qui reflète les données de votre Branch de production. Déployez votre application, exécutez des tests d'intégration et de performance sur des données réalistes, et prenez confiance avant la mise en production. Periodically reset staging from production to refresh vos données de test.
Branch par développeur
Chaque développeur travaille en toute isolation :
production
└── development
├── dev-alice
├── dev-bob
└── dev-charlie
Ce modèle empêche les développeurs d'interférer avec le travail des uns et des autres et permet à chacun de tester les modifications de schéma indépendamment. Chaque développeur peut expérimenter ses propres modifications de schéma et de données sans affecter les autres, puis appliquer les migrations testées à la Branch partagée development ou production lorsqu'il est prêt.
Les modèles de staging et de per-developer utilisent des branches à longue durée de vie. Une Branch sans expiration est facturée pour l’intégralité de la taille de ses données. Consultez la page How branching impacts Ressources consumption.
Ressources supplémentaires
- Gérer les branches pour apprendre à créer, Reset et supprimer des branches
- Branch protégées pour protéger les Branch critiques