Deploying migrations
For the copy-paste commands, see Deploying migrations locally. This page covers how schemachange deploy actually decides what to run, and where the two projects' deploy scripts genuinely differ.
How schemachange decides what to run
Each project has its own change-history table, and schemachange consults it before every deploy:
- Versioned (
V) files: if the version number is already recorded as applied, skip it. Never re-run. - Repeatable (
R) files: compute the file's current checksum; if it doesn't match what's recorded, run it and update the record. If it matches, skip it.
Stock and Redbook's histories are entirely independent — VEHICLE_STOCK_DB.VEHICLE_STOCK_SCHEMA.SCHEMACHANGE_HISTORY for stock, SPECIFICATIONS_DB.REDBOOK_SCHEMA.SCHEMACHANGE_HISTORY for Redbook. Deploying one tells you nothing about the other.
Authentication: the personal admin connection, not the dbt service account
Both projects' deploy-migrations.sh connect using your personal snowflake-drive-{env}-admin Snow CLI connection (from ~/.snowflake/config.toml), then execute as the DRIVE_{ENV}_ROLE_DBT role via schemachange's -r/--role flag. This is a different identity than the dbt service account key (DRIVE_STAGING_DBT_KEY_PATH) used for dbt runs — migrations don't touch that key at all. See Snowflake resources & RBAC for the role, and Secrets & SSM conventions for where the admin connection's key comes from.
The two scripts aren't identical
Both take the same [environment] [role] arguments and follow the same dry-run → confirm → deploy flow, but the scripts themselves differ in two ways that matter for where you run them from:
| Stock | Redbook | |
|---|---|---|
| Run from | src/stock/dbt (the dbt project root) | src/redbook/dbt/migrations (the migrations directory itself) |
| Why | Script sets MIGRATIONS_DIR="migrations" and checks that subdirectory exists | Script sets MIGRATIONS_DIR="." and checks for *.sql in the current directory |
| Missing change-history table | Assumes it already exists | Dry-runs once; if that fails, retries with --schemachange-create-change-history-table |
Running redbook's script from src/redbook/dbt instead of src/redbook/dbt/migrations fails — there's no *.sql to find in the parent directory. The Getting Started runbook gives the correct invocation for each.
Non-interactive deployment
Both scripts read the confirmation prompt from stdin, so piping y skips it — this is what CI/automation should do rather than trying to pass a flag:
echo "y" | ./deploy-migrations.sh staging