Produit — Versioning & environnements
Faire évoluer l'entrepôt sans le reconstruire.
Un entrepôt de données vit : nouvelles sources, nouvelles règles, nouveaux marts. Le risque n'est pas de modéliser, c'est de livrer une évolution en production sans savoir ce qu'elle casse. beVault versionne le métamodèle et rejoue les promotions de manière contrôlée, environnement par environnement.
- Métamodèle versionné dans le Git Store
- Environnements dev, recette et production séparés
- Promotions auditées, réversibles et traçables
- Déploiements non destructifs : l'historique est préservé
Le principe
Le modèle est un artefact de code, pas un réglage d'interface
Tout ce que vous décrivez dans metaVault est stocké sous forme de métadonnées versionnées. Une évolution se relit, se compare et se promeut comme n'importe quel changement logiciel.
Git Store
Chaque version du modèle est enregistrée avec son auteur, sa date et son périmètre. Vous comparez deux versions avant de décider.
Environnements séparés
Dev, recette et production partagent le même modèle de référence mais des paramètres et des cibles distincts.
Déploiements non destructifs
Une évolution de structure n'efface pas l'historique chargé : le Data Vault s'étend, il ne se recharge pas intégralement.
Traçabilité d'audit
Qui a promu quoi, quand et vers quel environnement : la piste d'audit accompagne les revues de conformité.
Le cycle de livraison
De la modification au passage en production
- 01
Modéliser en dev
L'évolution est décrite dans metaVault ; les contrôles de conformité DV 2.1 s'appliquent immédiatement.
- 02
Générer et tester
Le code de chargement est régénéré et exécuté sur l'environnement de développement, avec les règles Verify actives.
- 03
Promouvoir en recette
La version est promue telle quelle : ce qui est validé en recette est exactement ce qui partira en production.
- 04
Déployer en production
Le déploiement est appliqué selon votre calendrier de changement, sans rechargement complet de l'historique.
Évolution produit
Gestion des branches
Autour d'un même Data Vault coexistent plusieurs lignes de travail : des équipes projet différentes, des chantiers de modélisation menés en parallèle, des changements en cours de revue, des variantes de développement et de production, et des promotions à opérer de façon maîtrisée entre environnements.
La gestion des branches permet de faire vivre ces lignes de travail séparément sur le métamodèle : isoler un changement, comparer deux versions du modèle, faire relire une évolution avant déploiement, puis promouvoir uniquement ce qui a été validé.
Une équipe refond le domaine Contrats pendant qu'une autre ajoute deux sources au domaine Clients : chacune travaille sur sa branche, les écarts sont comparés, puis fusionnés après revue — sans que l'une écrase le travail de l'autre.
Les équipes data gagnent des changements isolés, une revue avant déploiement, un historique clair des décisions et une promotion contrôlée des évolutions validées, y compris sur des programmes à plusieurs chantiers simultanés.
Voir la modélisation metaVaultQuestions fréquentes
Ce que demandent les équipes de production
Peut-on revenir en arrière après une promotion ?
Oui. La version précédente du modèle reste disponible dans le Git Store et peut être repromue ; les données historisées ne sont pas détruites par un retour de version.
Faut-il un dépôt Git externe ?
Le Git Store est intégré à la plateforme. Il peut être connecté à votre chaîne CI/CD existante si vous souhaitez que les promotions soient déclenchées depuis vos pipelines.
Combien d'environnements peut-on gérer ?
Le nombre d'environnements n'est pas limité par le produit : il dépend de votre organisation et de votre infrastructure cible.
Étape suivante