Formation dbt

Dans l'article précédent, on a documenté le projet. À ce stade, il est structuré, matérialisé, testé et documenté. C'est un vrai mini projet dbt complet.

Sauf qu'il vit encore sur ton laptop, en dev, et que tu lances tout à la main. En prod, c'est une autre histoire avec du code versionné, des environnements séparés, et des exécutions automatiques. C'est la dernière brique des fondamentaux, et c'est ce qu'on pose aujourd'hui.

Versionner le projet avec Git

Avant de parler de prod, il faut mettre le projet sous Git. Git te donne l'historique de tes changements, la possibilité de revenir en arrière, le travail à plusieurs, et c'est le point de départ de toute automatisation.

Place-toi dans ton dossier projet et initialise le dépôt :

git init

Avant de committer quoi que ce soit, on crée un fichier .gitignore pour exclure ce qui n'a rien à faire dans le dépôt :

target/
dbt_packages/
logs/

Ces trois dossiers sont régénérés par dbt à chaque exécution. Les versionner ne sert à rien et pollue le dépôt. Tu commits ton code (modèles, YAML, macros) mais pas les artefacts.

git add .
git commit -m "Projet dbt initial : staging, marts, tests, doc"

Ensuite tu crées un dépôt sur GitHub et tu y pousses ton projet :

git remote add origin https://github.com/ton-compte/dbt_projet.git
git branch -M main
git push -u origin main
SourceTree
💡
Si tu n'aimes pas Git en ligne de commande, jette un oeil à Sourcetree : une appli gratuite pour manipuler ton repo Git en interface graphique, sans taper une seule commande.
⚠️
Souviens-toi, le profiles.yml est dans C:\Users\<user>\.dbt\profiles.yml, en dehors du projet, et il contient tes identifiants de connexion. Il n'est donc pas dans ton dépôt, et c'est voulu car on ne pousse jamais de clé ou password sur Git. En production, on injecte ces valeurs via des variables d'environnement.

dbt build

Jusqu'ici, on lançait dbt run pour construire les modèles, puis dbt test pour les vérifier. En production, on utilise une seule commande qui fait les deux, et mieux :

dbt build

dbt build parcourt ton graphe dans l'ordre des dépendances et, pour chaque modèle, il le construit puis le teste immédiatement avant de passer à la suite. Il enchaîne aussi les seeds et les snapshots au bon moment.

La différence avec un dbt run suivi d'un dbt test est subtile mais capitale. Si un modèle échoue à ses tests, dbt build ne construit pas les modèles qui en dépendent. Un run puis un test séparés auraient déjà tout construit avant de découvrir le problème. C'est pour ça que dbt build est la commande de prod.

Séparer dev et prod

En dev, on écrit dans le schéma dev. En production, on ne veut surtout pas écrire au même endroit car il faut un schéma séparé, pour que tes essais sur ton laptop ne touchent jamais aux données que consomment les dashboards.

Ça se règle dans le profiles.yml, en ajoutant une sortie prod à côté de dev :

dbt_projet:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: "{{ env_var('SNOWFLAKE_ACCOUNT') }}"
      user: "{{ env_var('SNOWFLAKE_USER') }}"
      password: "{{ env_var('SNOWFLAKE_PASSWORD') }}"
      role: dbt_role
      warehouse: dbt_wh
      database: analytics
      schema: dev
      threads: 4
    prod:
      type: snowflake
      account: "{{ env_var('SNOWFLAKE_ACCOUNT') }}"
      user: "{{ env_var('SNOWFLAKE_USER') }}"
      password: "{{ env_var('SNOWFLAKE_PASSWORD') }}"
      role: dbt_role
      warehouse: dbt_wh
      database: analytics
      schema: prod
      threads: 8

Par défaut (target: dev), tes commandes écrivent dans dev. Pour viser la production, tu ajoutes --target prod :

dbt build --target prod

Là, dbt construit tout dans le schéma prod. Même code, environnement différent.

💡
Dans un vrai projet, la dev et la prod n’utilisent généralement pas le même user, le même warehouse, le même rôle ni la même base. L’authentification est aussi plus robuste, souvent via une key pair ou un mécanisme géré par l’orchestrateur. Mais le principe reste le même , car au final on exécute le même projet dbt avec une target différente.

Faire tourner dbt en prod

Lancer dbt build --target prod à la main, c'est bien pour un premier déploiement. Mais la prod, c'est automatique car le projet doit tourner tout seul, sur un planning, sans toi devant le clavier.

Plusieurs options selon ton contexte :

  • dbt Cloud : la solution managée de dbt, avec planification, logs, environnements et interface dédiée. Pas de serveur à gérer.
  • dbt Projects on Snowflake : si ton projet vit déjà sur Snowflake, tu exécutes et orchestres tes projets dbt directement dans l'écosystème Snowflake, sans outil externe.
  • Un orchestrateur (Airflow, Dagster...) : le bon choix quand dbt n'est qu'une étape d'une chaîne plus large (ingestion, dbt, exports).
  • GitHub Actions ou un autre CI/CD : pour déclencher dbt après un merge ou dans un pipeline de déploiement.
  • Un cron sur un serveur : la solution minimale, un planning qui lance dbt build --target prod chaque nuit. Suffisant pour démarrer, mais pas robuste sur le long terme.

Le détail de l'orchestration mérite son propre article, on y reviendra dans la section avancée.

Ne reconstruire que le nécessaire

Un dernier réflexe à connaître. Sur un gros projet, reconstruire tous les modèles à chaque exécution devient lent et coûteux. dbt sait ne traiter qu'un sous-ensemble grâce au sélecteur --select :

dbt build --select stg_orders+

Le + après le nom signifie "ce modèle et tout ce qui en dépend en aval". Et il existe d'autres sélections encore plus puissantes qu'on verra en détail plus loin dans la série. Pour l'instant, sache juste que tu n'es pas condamné à tout reconstruire à chaque fois.

La suite ?

Récap. de cet article :

  • Mettre le projet sous Git avec un .gitignore propre.
  • Comprendre pourquoi dbt build est la commande de prod.
  • Séparer les environnements dev et prod dans le profiles.yml.
  • Voir les trois façons de faire tourner dbt en production.
  • Découvrir la sélection ciblée avec --select.

Et surtout, on boucle ici tout le palier des fondamentaux. Reprends le chemin parcouru depuis le début : on a installé dbt, branché Snowflake, construit des sources et du staging, choisi les matérialisations, ajouté des tests, documenté, et déployé. Tu sais maintenant monter un projet dbt complet, de bout en bout.

À partir du prochain article, on passe au niveau avancé. On commencera par le chargement incrémental en détail et donc comment ne traiter que les nouvelles lignes sur les grosses tables, avec is_incremental() et la clé unique. Ce sera le moment de faire le lien avec mon article sur le MERGE SQL.

Aller plus loin

Cet article fait partie de la formation dbt complète, du premier modèle au déploiement en production.

👉 Suivre toute la formation dbt

Pour comprendre ce que coûtent tes exécutions de production côté Snowflake (compute, warehouses, planification), tout est dans le parcours.

👉 Accéder à la Formation Snowflake

Et pour t'entraîner sur dbt en conditions d'examen, la certification dbt Analytics Engineering teste précisément le déploiement, dbt build et la gestion des environnements.

👉 Préparer la certification dbt sur DataCertification.fr

Tu veux que je t'accompagne sur ton projet data (Snowflake, dbt, modélisation, industrialisation) ?

👉 Réserver un appel de 30 minutes

Questions fréquentes

Quelle différence entre dbt run et dbt build ?

dbt run construit seulement les modèles. dbt build construit chaque modèle puis le teste immédiatement, et enchaîne aussi les seeds et les snapshots, le tout dans l'ordre des dépendances. Surtout, si un modèle échoue à ses tests, dbt build ne construit pas les modèles qui en dépendent, ce qui évite de propager de la donnée fausse en aval. C'est la commande recommandée en prod.

Comment versionner un projet dbt avec Git ?

On initialise un dépôt avec git init dans le dossier du projet, on ajoute un .gitignore qui exclut les dossiers target, dbt_packages et logs, puis on commite le code et on le pousse sur un dépôt distant comme GitHub. On versionne les modèles, les YAML et les macros, jamais les artefacts régénérés ni les fichiers de connexion.

Comment séparer les environnements dev et prod en dbt ?

Dans le profiles.yml, on définit plusieurs sorties (outputs), par exemple dev et prod, chacune pointant vers un schéma différent. Par défaut les commandes utilisent la cible dev. Pour viser la prod, on ajoute l'option --target prod, ce qui exécute le même code dans l'environnement de production sans toucher au dev.

Faut-il mettre le profiles.yml sur Git ?

Non, jamais. Le profiles.yml contient tes identifiants de connexion à l'entrepôt. En production, les valeurs sensibles sont injectées via des variables d'environnement plutôt que via un fichier.