Snowflake Dev Environments, CI/CD Pipelines and Rollback

1.Environments, data layers and workload isolation

An architecture that supports a development lifecycle starts with one rule: you build and test changes somewhere other than production. Snowflake's DevOps guidance recommends separate development, test and production environments. Development work then can't damage production data. These environments don't have to share an account. A DCM Projects deployment target can point each environment at its own Snowflake account or database.

Inside a single account, the quickest way to set up a realistic dev, test or sandbox copy is zero-copy cloning. CREATE <object> … CLONE is mainly used for databases, schemas and tables. For those three object types it also accepts an AT | BEFORE clause, so a clone can show the source as it was at an earlier timestamp, offset or statement. The sources treat a sandbox as just another isolated environment built the same way, not as a separate feature. How long that history is kept is covered in the data-recovery lesson.

Within an environment, data usually moves through layers, or zones. Snowflake's dynamic-table guidance uses the medallion names. Raw data lands first, then it's cleaned, then it's aggregated, and each step runs as SQL inside Snowflake. That is the ELT shape: load first, transform in place. The DevOps guidance names dbt Projects on Snowflake as the tool for managing those SQL transformations.

Workload isolation follows the same thinking. The DCM example in the next section gives each team its own database, warehouse and admin role, and makes warehouse size a per-team template value. Each team's work therefore runs on compute sized for that team. Coverage note: the source documentation for this lesson doesn't cover data-lake design, storage directory structure, or migration from other platforms. Those exam-guide bullets aren't taught here, so read the Snowflake documentation on them directly.

Sources123

2.Objects as code: DCM Projects, Terraform and dbt

Snowflake's DevOps model rests on three principles: define objects as code, validate changes before you deploy them, and automate deployment with CI/CD. Two declarative tools put the first principle into practice, and they work at different layers.

DCM Projects (Database Change Management) are the Snowflake-native tool for objects inside databases. A project has a manifest.yml file, which sets deployment targets, owner roles and templating per environment. It also has definition files under sources/definitions/ that contain DEFINE, GRANT and ATTACH statements. Jinja2 templating lets one definition set up infrastructure for many teams:

{% for team in teams %}

  DEFINE DATABASE {{team.name}}_DB;

  DEFINE WAREHOUSE {{team.name}}_WH
    WITH
      warehouse_size = '{{team.wh_size}}'
      auto_suspend = 300;

  DEFINE ROLE {{team.name}}_ADMIN;

  GRANT OWNERSHIP ON DATABASE {{team.name}}_DB TO ROLE {{team.name}}_ADMIN;
  GRANT OWNERSHIP ON WAREHOUSE {{team.name}}_WH TO ROLE {{team.name}}_ADMIN;

{% endfor %}

For multiple environments, the manifest declares one target per environment. Each target names an account, a project object, an owner role and a templating configuration. The same definition files then deploy everywhere, with settings that differ by environment.

targets:
  DEV:
    account_identifier: MYORG-MYACCOUNT_DEV
    project_name: MY_DB.MY_SCHEMA.MY_PROJECT_DEV
    project_owner: DEV_DEPLOYER
    templating_config: DEV

Many organizations use both tools. Terraform covers the account level that platform teams own, and DCM covers the in-database objects that data engineers own. Each object should be managed by only one tool, so the two never try to reconcile the same state. Their plans also see different things. DCM plans against internal object state, while Terraform reads state through public SQL and can miss attributes that SHOW and DESCRIBE don't return. In return, every statement Terraform runs appears in query history. dbt Projects do a different job. They deploy dbt Core transformations as a versioned DBT PROJECT object that you can schedule with tasks, and you use them alongside one of the other two tools.

Sources1

3.CI/CD pipelines with Snowflake CLI

Snowflake CLI (snow) is the command-line tool a pipeline runs to deploy DCM projects, Snowpark applications, Native Apps and standalone SQL scripts, so you don't need a custom client. Snowflake maintains a GitHub Action, which is generally available, plus a GitLab CI/CD component and an Azure DevOps extension, both in public preview. Each one installs the CLI and configures authentication. On Jenkins, Bitbucket, CircleCI or any other runner that can run a shell command, a single command installs the CLI:

uv tool install snowflake-cli
snow --version

Every integration sets up Snowflake the same way. You create a service user for the pipeline, configure how it authenticates, and grant it only the roles it needs. The recommended method is workload identity federation (WIF) with OIDC. The runner gets a short-lived identity token that Snowflake validates directly, so no long-lived secret is stored anywhere.

CREATE USER <username>
  TYPE = SERVICE
  WORKLOAD_IDENTITY = (
    TYPE =  ? 
    ISSUER = '<ci-platform-issuer>'
    SUBJECT = '<ci-platform-subject>'
  );

To harden a pipeline, use one dedicated service user per repository or environment. Restrict which source IPs can authenticate with network policies. Commit only the connection skeleton of config.toml and inject secrets through environment variables. If you can't use OIDC, rotate keys on a schedule. When settings conflict, precedence runs as follows: command-line parameters win, then connection-specific environment variables, then config.toml, and generic variables such as SNOWFLAKE_USER come last.

Sources4

4.Git integration as the deployment source

Snowflake can integrate with a remote repository on GitHub, GitLab, BitBucket, Azure DevOps or AWS CodeCommit, including repositories hosted at custom URLs. Files sync into a Git repository clone in Snowflake that includes all branches, tags and commits. Developers keep their usual tools, and Snowflake becomes one more client of the repository.

From the clone you can fetch the latest branches and tags, browse files, and reference file paths as handler code for functions, procedures and tasks. You can run EXECUTE IMMEDIATE from .sql files, and commit and push from Workspaces, Streamlit apps and notebooks. In a pipeline, snow git execute runs SQL files straight from this integration as the deploy step.

Sources5

5.Rollback: redeploy the previous version

The cheapest rollback is the one you never need. A DCM plan lists every create, alter and drop before anything changes. You can run it as snow dcm plan --target PROD or with EXECUTE DCM PROJECT … PLAN. Terraform has the same plan-then-apply step.

For a single object that isn't managed by DCM or Terraform, CREATE OR ALTER <object> creates the object or alters it to match the definition. If you keep that statement in a versioned file in a remote repository, rolling back means running the previous version of the file. The Python API offers the same behaviour through create_or_alter.

CREATE OR ALTER TABLE vacation_spots (
  city VARCHAR,
  airport VARCHAR,
  avg_temperature_air_f FLOAT,
  avg_relative_humidity_pct FLOAT,
  avg_cloud_cover_pct FLOAT,
  precipitation_probability_pct FLOAT
) data_retention_time_in_days = 1;

Sources1

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.A username and password stored as a pipeline secret is fine for production CI/CD.Why is that wrong?

   Password authentication is only for legacy workflows. Use a SERVICE user with OIDC workload identity federation, or a key pair if OIDC isn't available.

   Covered in CI/CD pipelines with Snowflake CLI

2. 2.dbt Projects on Snowflake can replace DCM Projects or Terraform for managing object state.Why is that wrong?

   dbt manages SQL transformations. You still need DCM or Terraform to declare the objects themselves, and dbt runs alongside them.

   Covered in Objects as code: DCM Projects, Terraform and dbt

3. 3.A Terraform plan and a DCM plan detect exactly the same changes.Why is that wrong?

   DCM plans against internal object state. Terraform reads state through public SQL and can miss attributes that SHOW and DESCRIBE don't return.

   Covered in Objects as code: DCM Projects, Terraform and dbt