Versionnement de modèles dbt

VérifiéSûr

Chargez lorsque la tâche implique le versionnement de modèles dbt, la création d'une v2 d'un modèle, ou des modifications rétrocompatibles. Couvre la config YAML des versions, defined_in, latest_version et ref() avec épinglage de version.

Spar Skills Guide Bot
Data & IAIntermédiaire
81025/07/2026
Claude CodeCursorWindsurfCopilotCodex
#dbt#data-modeling#versioning#sql#analytics-engineering

Recommandé pour

Synthèse automatique

Ce skill guide la création de versions de modèles dbt via la configuration native `versions:` plutôt que par des copies suffixées `_v2`.

Points forts

  • Explique la structure YAML exacte (`versions:`, `defined_in`, `latest_version`) avec un exemple concret
  • Distingue clairement un nœud versionné (`model.projet.dim_customers.v2`) d'un modèle autonome `_v2`
  • Détaille la résolution de `ref()` avec ou sans épinglage de version pour les modèles en aval
  • Fournit une commande `dbt ls` pour vérifier que les nœuds de version sont bien enregistrés

Limites

  • Suppose dbt-core 1.6 ou supérieur, sans gérer les versions antérieures
  • Ne couvre ni les tests de version, ni les contrats, ni les breaking changes majeurs
  • L'exemple YAML du document présente une indentation irrégulière qui peut induire en erreur
Quand l'utiliser

À utiliser lorsqu'une tâche demande une v2 de modèle dbt ou une modification rétrocompatible devant préserver les `ref()` existants.

Quand l'éviter

À éviter pour des changements cassants assumés, des refontes complètes de modèles, ou sur des projets dbt antérieurs à la 1.6.

Analyse de sécurité

Sûr
Score qualité82/100

The skill only instructs read and dbt CLI commands (dbt ls) within an allowed dbt scope; no destructive, network exfiltration, or obfuscated actions.

Aucun point d'attention détecté

Comment cette analyse est faite

Exemples

Add a v2 with a renamed column
Create a v2 of dim_customers that renames account_status to customer_status, keeping v1 as the latest version for now.
Pin downstream model to v2
Update fct_orders to use version 2 of dim_customers while other models stay on the default version.
Verify versioned nodes
Check that dim_customers is properly registered as versions v1 and v2 in dbt.

name: dbt-versioning description: "Load when task involves dbt model versioning, creating v2 of a model, or backward-compatible model changes. Covers versions YAML config, defined_in, latest_version, and ref() with version pins." disable-model-invocation: false allowed-tools: Bash(dbt *)

dbt Model Versioning

1. Versioned Model vs Standalone Copy

When a task says "create a v2," "add a new version," or "backward-compatible change," use dbt's native versions: config (dbt-core 1.6+). Do NOT create a standalone model with a _v2 suffix - that produces a separate node (model.project.dim_customers_v2) instead of a version node (model.project.dim_customers.v2).

2. YAML Structure

Declare versions inside the model's .yml file under the model entry:

models:
 - name: dim_customers
    latest_version: 1
    versions:
 - v: 1
 - v: 2
        defined_in: dim_customers_v2

Rules:

  • versions: is a list of v: entries inside the models: block, under the model name.
  • defined_in: maps a version to its SQL filename (without .sql). Omit defined_in when the filename matches the default <model_name>_v<N>.sql.
  • latest_version: controls which version ref('dim_customers') resolves to. If the task says "not yet the primary version," set latest_version to the old version number.

3. File Naming

Version SQL files use the pattern <model_name>_v<N>.sql.

  • dim_customers.sql - original model, becomes v1 implicitly.
  • dim_customers_v2.sql - new version.

Do NOT rename or move the original SQL file. It remains v1 without changes.

4. How ref() Works with Versions

  • ref('dim_customers') resolves to whichever version latest_version specifies.
  • ref('dim_customers', v=2) pins to version 2 regardless of latest_version.

Downstream models that need the new version must use ref('dim_customers', v=2). Models using bare ref('dim_customers') continue to get the old version until latest_version is updated.

5. Writing the v2 SQL

Read the original model's SQL first. If the v2 only renames or adds columns, write a thin wrapper:

select
    customer_id,
    customer_name,
    account_status as customer_status  -- renamed column
from {{ ref('dim_customers', v=1) }}

Do NOT duplicate all upstream logic into the v2 file when a SELECT-with-renames suffices.

6. Verification

After creating the versioned model, run:

dbt ls --select dim_customers --output json

Confirm the output contains nodes model.<project>.dim_customers.v1 and model.<project>.dim_customers.v2. If these nodes are missing, the versions: YAML is wrong.

Rules

  • NEVER create a standalone _v2 model without versions: YAML - dbt will not register it as a version.
  • NEVER rename or move the original SQL file when adding a new version.
  • ALWAYS set latest_version explicitly - omitting it defaults to the highest version number, which may break downstream refs.
  • ALWAYS read test files in tests/ before writing models - they reveal required dbt features the task may only hint at.
Skills similaires