One deployment environment
What this looks like
- You have a single development environment where dbt users can access the dbt Cloud IDE and make changes to their code on feature branches created off of your default branch in your repository (most often the
- You have a single deployment environment (let’s call it “Production”) where your scheduled jobs run referencing the
- You also have a Slim CI job that kicks off anytime you open a PR to merge a feature branch into
main. This Slim CI job can run in your dbt “Production” environment.
☁️ Slim CI jobs run in a dedicated custom schema for each PR, so there will no collision with your production schemas.
Git workflowgit flow diagram for one deployment environment
- In the dbt Cloud IDE, developers work on feature branches, created from the
- When code is ready, developer opens a PR to merge feature branch into
- Slim CI Job automatically kicks off, and tests the changes made in the PR
- When Slim CI Job is successful and team is ready to deploy changes to Production, the PR is merged directly into the
mainbranch. The next time a production job runs, these changes will be incorporated and executed.
dbt Cloud setup
Create your development environment to power the dbt Cloud IDE. No extra customization needed!
Create your production deployment environment.
Define your dbt Cloud jobs in the production deployment environment from step 2.
Production job(s): You will need to set up at least one scheduled job that deploys your project to your production databases/schemas. You may create multiple jobs based on your business SLAs.
Slim CI Job: Unlike the production jobs, which are triggered via the scheduler, this job will be triggered when PRs are opened in your repository. Enable this option by selecting
Run on Pull Requests?under the
Webhookstab under the
💡 This job will also need to defer to one of the Production jobs created in step 3a. This enables the use of the
statemodifiers in your selection syntax to only run changes introduced by your PR.
When this works well
This approach is the recommended approach for most use-cases as it allows changes to code to be quickly promoted to production, with confidence that they can be trusted. With this option, multiple developers can easily contributing to the same code base with confidence.
💡 Check out Sunrun's Coalesce 2022 talk on Automating CI/CD in dbt Cloud, where they simplified their CI/CD process from several long-lived branches to a single long-lived main branch with feature branches.
When this doesn’t work so well
- You have a formal QA process before merging code into production.
- You want to control when features are released to production.
- You need to have scheduled jobs running in many environments due to dependencies on outside systems.
- e.g. Your organization has many applications that consume and test data changes in a lower non-Production environment before changes should be promoted to Production.