# Best Practices for CICD Deployment

**URL:** <https://discourse.getdbt.com/t/best-practices-for-cicd-deployment/618>\
**Category:** In-Depth Discussions\
**Tags:** best-practice, ci-cd\
**Created:** [October 3, 2019, 7:33pm UTC](https://discourse.getdbt.com/t/best-practices-for-cicd-deployment/618 "2019-10-03T19:33:06Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![dave\_connors](https://avatars.discourse-cdn.com/v4/letter/d/b2d939/32.png) [@dave\_connors](https://discourse.getdbt.com/u/dave_connors)\
**Post date:** [October 3, 2019, 7:33pm UTC](https://discourse.getdbt.com/t/best-practices-for-cicd-deployment/618/1 "2019-10-03T19:33:06Z")

</div>

Hey there!

I am a relatively new dbt user who is nearing the stage of deploying to production, and my team is going to use CI/CD on gitlab. Are there any best practices or words of wisdom we should be aware of as we start setting this up? I’l be working with a dev who is much better at CI/CD but has almost no exposure to dbt architecture/set up.

Thanks in advance!

---

<div class="post-metadata">

**Author:** ![tmurphy](https://sea2.discourse-cdn.com/flex020/user_avatar/discourse.getdbt.com/tmurphy/32/43_2.png) [@tmurphy](https://discourse.getdbt.com/u/tmurphy)\
**Post date:** [October 3, 2019, 8:13pm UTC](https://discourse.getdbt.com/t/best-practices-for-cicd-deployment/618/2 "2019-10-03T20:13:48Z")

</div>

dbt cloud is a great option depending on the size of your team and data engineering maturity.

At GitLab, we run dbt in production via Airflow. Our DAGs are defined in [this part of our repo](https://gitlab.com/gitlab-data/analytics/tree/master/dags/transformation). We run Airflow on Kubernetes in GCP. Our Docker images are stored in [this project](https://gitlab.com/gitlab-data/data-image).

For CI, we use GitLab CI. In merge requests, our jobs are set to run in a separate Snowflake database (a clone). Here’s all the [job definitions](https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/snowflake-dbt-ci.yml) for dbt. The rest of the CI pipeline is defined [here](https://gitlab.com/gitlab-data/analytics/blob/master/.gitlab-ci.yml).

General principles, I think, are that you want to have your MRs run dbt using real data but writing to either a dev schema or a separate DB clone like we do. If you make dbt reference environment variables for where to write then you can control it quite nicely that way. (See our [profile here](https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/profile/profiles.yml) for details on that).

Hope this is useful!

---

<div class="post-metadata">

**Author:** ![yu-iskw](https://avatars.discourse-cdn.com/v4/letter/y/cab0a1/32.png) [@yu-iskw](https://discourse.getdbt.com/u/yu-iskw)\
**Post date:** [August 12, 2020, 11:35am UTC](https://discourse.getdbt.com/t/best-practices-for-cicd-deployment/618/3 "2020-08-12T11:35:11Z")

</div>

@tmurphyThank you for sharing the knowledge. That would be super helpful. I was wondering how to pass airflow’s macros, especially `{{ ds }}` and `{{ execution_date }}`. A possible solution I was thinking was using environment variables. So, I was encouraged, seeing the repository. Many thanks!

> <https://gitlab.com/gitlab-data/analytics/-/blob/master/dags/airflow_utils.py#L213>