<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>dbt Guide for Production on Jaehyeon Kim</title><link>https://jaehyeon.me/series/dbt-guide-for-production/</link><description>Recent content in dbt Guide for Production on Jaehyeon Kim</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Copyright © 2023-2026 Jaehyeon Kim. All Rights Reserved.</copyright><lastBuildDate>Fri, 13 Sep 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://jaehyeon.me/series/dbt-guide-for-production/index.xml" rel="self" type="application/rss+xml"/><item><title>Guide to Running DBT in Production</title><link>https://jaehyeon.me/blog/2024-09-13-dbt-guide/</link><pubDate>Fri, 13 Sep 2024 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2024-09-13-dbt-guide/</guid><description><![CDATA[<p>Deploying a <em>dbt</em> project in multiple environments is the focus here, and we walk through the entire CI/CD process step-by-step. In the <a href="/blog/2024-09-05-dbt-cicd-demo/">previous post</a>, we started discussing a <em>continuous integration/continuous delivery (CI/CD)</em> process of a <em>dbt</em> project by introducing two GitHub Actions workflows - <code>slim-ci</code> and <code>deploy</code>. The former is triggered when a pull request is created to the main branch, and it builds only modified models and its first-order children in a <em>ci</em> dataset, followed by performing tests on them. The second workflow gets triggered once a pull request is merged. Beginning with running unit tests, it packages the <em>dbt</em> project as a Docker container and publishes to <em>Artifact Registry</em>.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2024-09-13-dbt-guide/featured.png" length="71185" type="image/png"/></item><item><title>DBT CI/CD Demo with BigQuery and GitHub Actions</title><link>https://jaehyeon.me/blog/2024-09-05-dbt-cicd-demo/</link><pubDate>Thu, 05 Sep 2024 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2024-09-05-dbt-cicd-demo/</guid><description><![CDATA[<p>Continuous integration (CI) is the process of ensuring new code integrates with the larger code base, and it puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch. Continuous delivery (CD) is an extension of continuous integration since it automatically deploys all code changes to a testing and/or production environment after the build stage. CI/CD helps development teams avoid bugs and code failures while maintaining a continuous cycle of software development and updates. In this post, we discuss how to set up a CI/CD pipeline for a <a href="https://www.getdbt.com/" target="_blank" rel="noopener noreferrer">data build tool (<em>dbt</em>)<i class="fas fa-external-link-square-alt ms-1"></i></a> project using <a href="https://github.com/features/actions" target="_blank" rel="noopener noreferrer">GitHub Actions<i class="fas fa-external-link-square-alt ms-1"></i></a> where <a href="https://cloud.google.com/bigquery?hl=en" target="_blank" rel="noopener noreferrer">BigQuery<i class="fas fa-external-link-square-alt ms-1"></i></a> is used as the target data warehouse.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2024-09-05-dbt-cicd-demo/featured.png" length="60835" type="image/png"/></item></channel></rss>