Product — Versioning & environments
Evolving the warehouse without rebuilding it.
A data warehouse lives: new sources, new rules, new marts. The risk isn't modeling, it's deploying a change to production without knowing what it breaks. beVault versions the metamodel and replays promotions in a controlled way, environment by environment.
- Metamodel versioned in the Git Store
- Separate dev, staging and production environments
- Audited, reversible and traceable promotions
- Non-destructive deployments: history is preserved
The principle
The model is a code artifact, not a UI setting
Everything you describe in metaVault is stored as versioned metadata. A change can be reviewed, compared and promoted like any software change.
Git Store
Every version of the model is recorded with its author, date and scope. You compare two versions before deciding.
Separate environments
Dev, staging, and production share the same reference model but have distinct parameters and targets.
Non-destructive deployments
A structural change doesn't erase loaded history: the Data Vault extends, it doesn't fully reload.
Audit traceability
Who promoted what, when and to which environment: the audit trail supports compliance reviews.
The delivery cycle
From change to production
- 01
Model in dev
The change is described in metaVault; DV 2.1 compliance checks apply immediately.
- 02
Generate and test
The load code is regenerated and run on the development environment, with Verify rules active.
- 03
Promote to staging
The version is promoted as-is: what is validated in staging is exactly what goes to production.
- 04
Deploy to production
The deployment is applied according to your change calendar, with no full reload of the history.
Product evolution
Branch management
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.
See the metaVault modelingFrequently asked questions
What production teams ask for
Can we roll back after a promotion?
Yes. The previous version of the model remains available in the Git Store and can be re-promoted; historized data is not destroyed by a version rollback.
Do we need an external Git repository?
The Git Store is built into the platform. It can be connected to your existing CI/CD pipeline if you want promotions to be triggered from your pipelines.
How many environments can be managed?
The number of environments is not limited by the product: it depends on your organization and your target infrastructure.
Next step