Skip to main content
Continuous Deployment (CD) runs a Bolt schedule as soon as changes are merged, so your production environment always reflects the latest approved work. In this guide you’ll create a CD schedule that deploys on merge, then hand off to the setup page for your git provider.
PrerequisitesEstimated time: 15 minutes.

Steps

1

Create or edit a Bolt schedule

In the Bolt UI, create a new schedule or open an existing one to edit. This schedule is what deploys your changes to production on merge.
2

Turn on Defer to a previous run

Enable Defer to a previous run so the job builds only what changed, comparing against a previous run’s state. This keeps each deployment fast and incremental.
3

Name the schedule and choose what to defer to

Give the schedule a descriptive name so it’s easy to identify.Choose the schedule to defer to (the same schedule or another), then set the comparison method to either Last run or Last successful run.
Deferring to the schedule’s own last successful run gives you efficient incremental builds.
4

Enter the dbt™ commands to run

Enter the commands the deployment should run. To build only changed models and their dependents, select modified state:
A schedule can run any commands (dbt™, Python scripts, or app triggers), not only dbt models.
5

Set the branch and the On Merge trigger

Choose the git branch to deploy from, for example main. Then set the trigger to On Merge, so the schedule runs whenever a pull request is merged into that branch.
6

Deploy the schedule

Deploy the schedule to save and activate it. Note its slug, which you’ll need if your git provider triggers Bolt through a pipeline.
Open a test pull request with a small model change and merge it. You’ll know it worked when the CD schedule kicks off automatically and the modified models rebuild in production. If nothing runs, revisit the branch and the On Merge trigger in step 5, and confirm your git provider is connected.

Set up your git provider

Finish the connection on the reference page for your provider. GitHub uses a native app with no pipeline required, while the others trigger the schedule from a pipeline using its slug.

GitHub

GitLab

Azure DevOps

BitBucket

Next steps

Set up Turbo CI

Test changes on every pull request before they merge.

Continuous Deployment reference

Every deployment option and the CD schedule settings.