Dev, QA, production
How a release reaches you
Dev
Every change is built and tested in a developer's own database first, on both dbt engines.
QA
One pull request into qa; a fresh QA build from cleared databases, as QA's own identity, certified on six gates.
Main
The certified qa squash-merged into main; qa then converges with main.
Production
Production built from main by its own job and identity, and checked against QA row for row.
Release
Tagged on the commit production built, named for the idea that holds it together.
What protects it
Guards on every build
137 tests. Data tests and unit tests across two dbt engines, every build.
Two identities. QA's builder cannot touch production, and production's cannot touch QA.
Inspectors and auditors. Records the vault cannot accept, and counts that do not reconcile, are written down, never dropped.
Baselines. Every build compares its results with the state just before it.
Read-only
The code itself
Generated from the repository on every build of this site.
The vault
Staging, hubs, links, satellites and their dated views: each a declaration the datavault4dbt macros build.
Read the codeInfrastructure
Every database, role, grant and protection rule as a committed script, the connector's code, and the runbooks for QA and production.
Read the codeThe standards conversation
Aligning with your standards
Data Vault practitioners follow different approaches. The principles are shared, but teams make different choices about business keys, how satellites are split, where integration happens, how releases are tested and promoted. None of these is the one right answer; each reflects a team’s experience.
This vault is one way to apply them: an approach that generally follows the shared principles, using an insurance distributor as its subject area. This site presents it, with the releases, the documentation, the model and the code, as a starting point for a conversation about standards. Yours may well differ, and where it does, we want to follow yours.
Wherever your approach would enhance it, start from the vault’s structure. Each release includes its DDL in the repository, at infra/snowflake/ddl/dv.sql: bring it into a modeling tool such as ER/Studio, model your standard, and send it back, by email or on a branch of your own. We build it into the vault and send you the pull request, so you can review your approach in the actual code.
Ray will send you an invitation to the repository; just tell him your GitHub username.
See the evidence
The QA certification of release 1, gate by gate.
Read the QA certification