Deploy and manage DCM Projects¶

Interface tools¶

You have the following interface options available for DCM Projects.

Git integration¶

Connect to the Git repository where your DCM project definition files are stored.

Required roles and privileges¶

The role of the user who creates a DCM project object must have the following roles and privileges:

• The CREATE DCM PROJECT ON SCHEMA privilege:

  CopyExpand

  GRANT CREATE DCM PROJECT ON SCHEMA <schema_name> TO ROLE <role_name>;
  

  Show lessSee more

  Scroll to top

Create a DCM project¶

Create a DCM project object by using one of the following options.

CREATE [OR REPLACE] DCM PROJECT [IF NOT EXISTS] <my_project>
[COMMENT = 'my comment'];

snow dcm create <my_project> --if-not-exists

snow dcm create <my_project> --if-not-exists

snow dcm create # uses the name specified in the default target from the manifest

snow dcm create --target # uses the named target from the manifest

Ownership on DCM-managed objects¶

The role that deploys a DCM project, by default, has the OWNERSHIP privilege of all deployed objects.

The project definitions can include GRANT OWNERSHIP statements to other roles. Snowflake recommends that the DCM project owner role only grant ownership of DCM-managed objects to another lower-level role that it also holds. Then the project can continue to manage this object, as the project owner role “inherits” the privileges of the new object owner role.

If the DCM project owner role grants ownership of DCM-managed objects to another role that it does not hold itself, the project can no longer manage this deployed object because the project owner role no longer has ownership of it. Subsequent deployments will fail. The object definition needs to be removed from the project or ownership needs to be granted back to the project owner role.

If you want to migrate existing objects to be managed by a DCM project, the role that owns the DCM project object also has to have ownership privileges (direct or inherited through other roles) on the object to be managed by DCM project.

Run the PLAN command¶

The PLAN command takes the following information as input:

• The path to the manifest file

  The CLI reads the target from the manifest (default_target or --target flag). For SQL commands, the path to the manifest file and the project name must be provided.

• Defined values for Jinja variables (optional).

• The target’s templating_config automatically selects the configuration profile. For SQL commands, use the USING CONFIGURATION clause to specify the profile.

• One or more values of the configuration profile to overwrite (optional).

The following are examples of how to run the PLAN command.

Snowflake CLISnowsightSQL

Run the snow dcm plan command in your local IDE terminal or as part of a Git workflow.

An example of a CLI command to plan a DCM project from a local directory is:

CopyExpand

cd ./Quickstarts/DCM_Project_Quickstart_1/
snow dcm plan

Show lessSee more

Scroll to top

An example of a CLI command to plan a DCM project from a Snowflake stage or Git repository clone is:

CopyExpand

snow dcm plan --target PROD_US --save-output

Show lessSee more

Scroll to top

An example of a CLI command to plan a DCM project with optional arguments is:

CopyExpand

snow dcm plan
--variable "wh_size='MEDIUM'" --variable "teams = ['TEAM_A', 'TEAM_B']"
--save-output

Show lessSee more

Scroll to top

Variables are required in double-quotes with additional single quotes for string-values. Lists of values require square-brackets.

Definition file path¶

You have the following options to reference the location of the manifest and definition files.

• From a Workspace path

  The Snowsight user interface automatically lists all DCM project definitions inside the current workspace. You can select one of these paths and workspaces will use it to run DCM commands.

  If you want to manually run SQL commands in workspaces you can also refer to that same path inside any of your workspaces.

  Tip: The 3-dot menu behind every file in your workspace lets you copy the full path to that file into your SQL code.

  An example of a SQL command to plan a DCM project from a workspace path is:

  CopyExpand

  EXECUTE DCM PROJECT DCM_PROJECT_DEV
    PLAN
    USING CONFIGURATION DEV
  FROM
    'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/Quickstarts/DCM_Project_Quickstart_1'
  

  Show lessSee more

  Scroll to top

• From a local Git repository clone on your disk

  Select the directory that contains your manifest.yml file before running the CLI command in your local IDE. Alternatively you can specify a different local directory that contains the manifest and definitions you want to use.

  An example of a CLI command to plan a DCM project from the current directory of a local Git repo:

  CopyExpand

  cd ./Quickstarts/DCM_Project_Quickstart_1/
  
  snow dcm plan
  
  snow dcm plan --target PROD
  

  Show lessSee more

  Scroll to top

  An example of a CLI command to plan a DCM project from a different directory in a local Git repo clone:

  CopyExpand

  snow dcm plan DCM_PROJECT_DEV --configuration DEV --from ./Quickstarts/DCM_Project_Quickstart_2/
  

  Show lessSee more

  Scroll to top

• From your remote repository in a workflow

  The same CLI syntax can be used when the DCM commands are executed in a CI/CD workflow.

  An example of a CI/CD workflow to plan a DCM project from a local Git repo clone:

  CopyExpand

  steps:
    - name: Clone Repo
      uses: actions/checkout@v4
    - name: Setup SnowCLI
      uses: snowflakedb/snowflake-cli-action@v2.0
    - name: Run PLAN
      run: |
        cd ./Quickstarts/DCM_Project_Quickstart_1/
        snow dcm plan --target PROD --save-output
  

  Show lessSee more

  Scroll to top

• From a Stage or Git repository clone in Snowflake

  In case you want to run a Procedure or Task inside Snowflake that executes DCM commands, this SQL command can reference an absolute path to a Snowflake Stage or Git Repository Clone inside the account.

  For Git Repository clones consider first running ALTER GIT REPOSITORY FETCH to have the latest version.

  '@...' paths can only be used when executing DCM SQL commands.

  An example of a SQL command to plan a DCM project from a Stage or Git repository clone in Snowflake is:

  CopyExpand

  EXECUTE DCM PROJECT DCM_PROJECT_DEV
    PLAN
    USING CONFIGURATION DEV
  FROM
    '@DCM_DEMO.DEPLOY.DCM_DEMO/branches/main/Quickstarts/DCM_Project_Quickstart_1/'
  

  Show lessSee more

  Scroll to top

Plan output¶

The standard plan output contains the following information about the plan execution in JSON format:

version: 2
metadata:
  timestamp: <timestamp>
  query_id: <query_id>
  project_name: <project_name>
  user: <user>
  role_name: <role_name>
  command: <command>
  changes:
    - kind: <kind>
        "attribute_name": <attribute_name>,
        "value": <value>
        "changes": [
          {
            "kind": <kind>,
            "attribute_name": <attribute_name>,
            "value": <value>
          }
        ]
      }
    ]
  }
}

An example of a plan output:

{
  "version": 2,
  "metadata": {
    "timestamp": <timestamp>,
    "query_id": <query_id>,
    "project_name": <project_name>,
    "user": <user>,
    "role_name": <role_name>,
    "command": <command>
  },
  "changeset": [
    {
      "type": "CREATE",
      "object_id": {
        "domain": "TABLE",
        "name": "CUSTOMER_SUMMARY",
        "fqn": "MY_DB.ANALYTICS.CUSTOMER_SUMMARY",
        "database": "MY_DB",
        "schema": "ANALYTICS"
      },
      "changes": [
        {
          "kind": "set",
          "attribute_name": "warehouse_size",
          "value": "XSMALL"
        },
        {
          "kind": "set",
          "attribute_name": "query",
          "value": "SELECT customer_id, SUM(amount) AS total FROM orders GROUP BY customer_id"
        }
      ]
    },
    {
      "type": "ALTER",
      "object_id": {
        "domain": "DYNAMIC_TABLE",
        "name": "ORDER_DETAILS",
        "fqn": "MY_DB.ANALYTICS.ORDER_DETAILS",
        "database": "MY_DB",
        "schema": "ANALYTICS"
      },
      "changes": [
        {
          "kind": "changed",
          "attribute_name": "warehouse_size",
          "value": "SMALL",
          "prev_value": "XSMALL"
        },
        {
          "kind": "collection",
          "collection_name": "columns",
          "id_label": "name",
          "changes": [
            {
              "kind": "added",
              "item_id": "DISCOUNT_AMOUNT",
              "changes": [
                {
                  "kind": "set",
                  "attribute_name": "data_type",
                  "value": "NUMBER(10,2)"
                }
              ]
            },
            {
              "kind": "modified",
              "item_id": "ORDER_STATUS",
              "changes": [
                {
                  "kind": "changed",
                  "attribute_name": "data_type",
                  "value": "VARCHAR(50)",
                  "prev_value": "VARCHAR(20)"
                }
              ]
            },
            {
              "kind": "removed",
              "item_id": "LEGACY_FLAG"
            }
          ]
        }
      ]
    },
    {
      "type": "DROP",
      "object_id": {
        "domain": "VIEW",
        "name": "OLD_REPORT_VIEW",
        "fqn": "MY_DB.ANALYTICS.OLD_REPORT_VIEW",
        "database": "MY_DB",
        "schema": "ANALYTICS"
      },
      "changes": []
    }
  ]
}

Run the DEPLOY command¶

To execute the DEPLOY command, provide the following inputs:

• The path to the manifest file.

• A configuration profile must be named if configuration profiles are defined in the manifest.

• Optionally, values for the configuration profile overriding the default values.

• Optionally, a deployment alias.

The following are examples of how to run the DEPLOY command.

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV
  DEPLOY
FROM
  'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/Quickstarts/DCM_Project_Quickstart_1';

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV
  DEPLOY AS "testing 2 teams"
  USING CONFIGURATION DEV (wh_size => 'MEDIUM', teams => ['TEAM_A', 'TEAM_B'])
FROM
  'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/Quickstarts/DCM_Project_Quickstart_1';

cd ./Quickstarts/DCM_Project_Quickstart_1/
snow dcm deploy DCM_DEMO.PROJECTS.DCM_PROJECT_DEV

snow dcm deploy --target PROD_US

snow dcm deploy DCM_DEMO.PROJECTS.DCM_PROJECT_DEV \
--configuration DEV \
--variable "wh_size='MEDIUM'" --variable "teams = ['TEAM_A', 'TEAM_B']" \
--alias 'testing 2 teams'

See Plan output for the standard plan output structure.

Show all objects managed by a DCM project¶

The SHOW ENTITIES IN DCM PROJECT command allows you to see a list of all Snowflake objects that are currently managed by a specific DCM project. It provides a list of fully qualified names for all objects. To see the results, you need both READ privilege on the DCM project and privileges to see the managed object itself.

You can use LIKE to search by name or use a flow operator to further process or filter the result set.

Similarly you can SHOW GRANTS and SHOW FUTURE GRANTS that are defined and deployed with this project.

Examples to see all objects that are currently managed by a DCM project:

SHOW ENTITIES LIKE '%DASHBOARD%' IN DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV;

SHOW ENTITIES IN DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV
  ->> SELECT * FROM $1 WHERE "object_type" = 'DYNAMIC_TABLE';

SHOW [FUTURE] GRANTS IN DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV;

Detach objects from a DCM project¶

Using the ALTER <object> command with the UNSET DCM PROJECT clause, you can detach an object that was deployed and is now managed by a DCM project. The command removes the association between the object and the DCM project without dropping the object. You can use this command when you want to start managing an object by a different DCM project.

Make sure to remove the corresponding DEFINE statement from your project definition files before you deploy it again. Otherwise, the object will be reintegrated into the DCM project.

An example of a SQL command to detach an object from a DCM project:

ALTER TABLE MY_DB.MY_SCH.MY_TABLE
  UNSET DCM PROJECT;

You can not detach deployed grants or exectations from a DCM Project.

Drop a DCM project¶

When a DCM project object is dropped, all managed entities, grants, and expectations remain in place as “unmanaged”.

DROP DCM PROJECT [IF EXISTS] <my_project>;

snow dcm drop my_project

CI/CD best practices¶

Follow these practices when automating deployments with CI/CD pipelines:

• A DCM project targeting a non-production environment should be owned by a different role than its production counterpart to avoid accidental deployments to production.

• A DCM project targeting a production environment should be owned by a dedicated role for production deployments with specifically tailored access privileges that are just enough to deploy all objects in the project.

  • Avoid using general administrator roles for DCM project ownership. Grant such roles only to service users, not to individual developers.

  • Grant the dedicated production deployment role only to service users, not to individual developers.

  • Restrict the ownership to the production deployment role to ensure immutability of critical infrastructure or data products.

    If the dedicated production deployment role grants ownership of production objects to other roles, users who are granted those roles can still modify or drop the production objects.

GitHub Actions examples¶

This section provides sample GitHub Actions workflows that illustrate typical CI/CD patterns for DCM Projects. The same concepts apply to other Git-based platforms such as Azure DevOps, GitLab CI/CD, or Bitbucket Pipelines — only the workflow syntax differs.

Each sample provides building blocks that you can customize and combine based on your pipeline setup, environment topology, and organizational requirements.

The sample workflows demonstrate the following patterns applicable to any DCM CI/CD setup:

• Manifest-driven configuration Each workflow reads account_identifier, project_owner, and project_name from the manifest targets. This keeps environment configuration in one place and avoids duplicating it across GitHub secrets.

• Data drop protection The deploy workflow parses plan_result.json for destructive DROP operations on data-bearing objects, such as databases, schemas, tables, and stages, and blocks the deployment if any are found.

• Sequential stage-to-production promotion Production deployment starts only after staging deployment succeeds, dynamic tables are refreshed, and data quality tests pass.

• Structured plan output parsing Workflows use jq to extract operation counts and object domains from plan_result.json, making it easy to build custom summaries and checks.

• AI-powered summaries snow cortex complete generates natural-language summaries of post-hook script results and Dynamic Table refresh output for the GitHub Actions job summary.

Before running these sample workflows, complete the following prerequisites:

• Store the DCM project files in a Git repository.

• Grant a user privileges to create and run GitHub Actions.

• Configure GitHub secrets for the Snowflake service user credentials (SNOWFLAKE_USER, SNOWFLAKE_PASSWORD or a personal access token).

• Configure GitHub variables for the path to the DCM project folder (DCM_PROJECT_PATH).

• Configure GitHub environments for each manifest target (for example, DCM_STAGE, DCM_PROD_US).

For setting up a Snowflake connection in GitHub Actions, see the first half of the blog post, A Practical Guide to GitHub Actions CI/CD.

See the snowflake-labs DCM repository for a set of GitHub Actions workflows that cover the full CI/CD lifecycle for DCM Projects.

All sample workflows read the Snowflake account_identifier and project_owner role directly from the manifest targets using yq, so that environment-specific configuration lives in the version-controlled manifest.yml rather than in duplicated GitHub secrets. Only the service user credentials are stored as secrets.