Deploy Code Changes On Merge

This template creates a Bolt schedule that automatically executes dbt™ model builds and deploys them to production when a new pull request is merged into the main branch. This type of Bolt schedule is commonly referred to as Continuous Deployment or "CD".

Key Benefits

• Automatically deploy dbt™ model changes to production after merge

• Rebuild only modified models and their downstream dependencies

Prerequisites

• Scheduler Environment is connected to your data warehouse provider

• Existing Bolt Schedule that has executed "dbt run" successfully

---

How to Configure

Implementing the Continuous Deployment schedule requires a multi-step setup process. Follow these instructions carefully to ensure a successful configuration:

Part 1: Initial Schedule Setup

This initial setup lays the foundation for the Continuous Deployment schedule. It involves creating the schedule, configuring the Deferred Schedule and Last Run Type settings, and defining the commands and triggers.

1. From the Bolt home screen, select + New Schedule and then + Create New Schedule.

2. Schedule Type: Select Deferred, which enables manifest comparison between runs to identify the minimal set of models that need to be rebuilt.

3. Name: Provide a relevant name (e.g. "Continuous Deployment")

4. Description (Optional): Describe the purpose of this schedule (e.g. "Deploy dbt models to production when a new pull request is merged")

5. Deferred Schedule: Initially, select an existing production schedule that has successfully executed the dbt run command. This allows the first Continuous Deployment run to have manifest files (AKA artifacts) to compare against.

6. Last Run Type: Select Last Successful Run to ensure the schedule defers to a run that completed without any errors.

7. Command Settings: Add dbt run --select state:modified+ to rebuild only the dbt models that have been modified since the last successful run.

If you've implemented Turbo CI, don't include dbt build as Turbo CI already handles model building and tests in the pull request workflow.

1. Trigger Type:

   • If on GitHub, use the "On Merge" trigger to automatically run the schedule when a pull request is merged.

   • If on other platforms (GitLab, Azure, BitBucket), use the "Standard Schedule" trigger set to "OFF" and trigger manually.

2. Notification Settings (Optional): Configure success, failure, and SLA breach alerts via email, Slack, or MS Teams.

3. Click "Deploy" to publish the new Continuous Deployment schedule.

Part 2: Generate Initial Artifacts

The first run of the Continuous Deployment schedule is crucial, as it generates the initial manifest files (artifacts) that will be used for state comparison in subsequent runs. This part covers executing that initial run.

1. From the Bolt home screen, click on the newly created Continuous Deployment schedule.

2. Click "Run" to execute an initial run of the schedule and generate the manifest files (artifacts).

3. Verify the initial run was successful by checking the run history

To view all generated artifacts, see documentation analyzing individual run details.

Part 3: Transition to Self-Sustaining Schedule

After the initial run, we can update the Deferred Schedule configuration to make the Continuous Deployment schedule self-sustaining. This allows it to compare each subsequent run against its own previous successful execution.

1. From the Bolt home screen, click on the Continuous Deployment schedule.

2. Click "Edit" to modify the schedule configuration.

3. Update the Deferred Schedule to "self" so the schedule can compare against its own previous successful run.

4. Click "Deploy" to save the changes.

Now your Continuous Deployment schedule is set up and ready to automatically deploy dbt™ model changes to production after each merge. The schedule will intelligently rebuild only the necessary models, optimizing compute and providing immediate visibility into the deployment status.