|dcm|の展開と管理¶

このトピックでは、アカウントを含め、Snowflake環境を管理するための|dcm|を作成してデプロイする方法について説明します。

|dcm-object|の管理には、次の手順が含まれます。

|dcm-object|に向けてSnowflakeアカウントを準備する。
プロジェクト構成とプロジェクトファイル内のオブジェクトを定義する。
|dcm|オブジェクトを作成する。
デプロイ前に提案された変更をプレビューする計画を立てる。
プロジェクトをデプロイする。
必要に応じてプロセスを監視、更新、反復することで、プロジェクトを維持する。

プロジェクトへのインクリメント変更だけでなく、大規模なアカウントインフラストラクチャの変更も継続的にデプロイできます。

Snowflakeは、1回のデプロイで0から100の大規模なアカウントインフラストラクチャの変更を行うのではなく、プロジェクトへのインクリメント変更と追加を継続的にデプロイすることをお勧めします。

|dcm-object|の準備¶

|dcm|を開始するには、Snowflakeアカウントが次の前提条件を満たしている必要があります。

|dcm|オブジェクトを作成できるデータベースとスキーマ
|dcm|オブジェクトを作成する権限と、ウェアハウスでクエリを実行するためのアクセス権を持つロール
|sf-cli|の場合、仮ステージを作成する権限を持つロール

このセクションでは、|dcm|の準備のために完了する必要のあるタスクについて説明します。

:ref:`|sf-cli|またはCortexCLIを使用する場合は、DCMプロジェクト<label-dcm_projects_interface_tools>`で使用するインターフェースをインストールします。
:ref:`Git統合を構成します<label-dcm_projects_git_integration>`（推奨ですが、必須ではありません）

注釈

`snowflake-labs DCMリポジトリ<https://github.com/Snowflake-Labs/snowflake-dcm-projects>`__は継続的に更新されており、使い始めるのに役立つリソースが提供されています。

クイックスタートとでもプロジェクト ：Snowflakeワークスペースまたはローカルフォルダーにリポジトリをクローンして、 DCM Projects コマンドを試し、 DCM Projects 機能を試します。
再利用可能GitHubアクション ：マニフェストの解析、接続のテスト、計画、およびCI/CDパイプラインへの DCM Projects のデプロイのための複合アクション。詳細については、 GitHub アクションをご参照ください。
サンプルワークフロー ：完全なCI/CDパイプラインに再利用可能なアクションを構成する、すぐに使えるワークフローファイル。

インターフェースツール¶

|dcm|には次のインターフェースオプションがあります。


インターフェースツール	最適な用途
Snowsight Snowsightのワークスペースは、アカウント内のSnowflakeネイティブクラウドIDEです。	UI経由で、DCM定義ファイルを簡単に作成またはアップロードします。 Gitリポジトリに接続して、変更をプル/プッシュします。定義ファイルを精査、編集、およびデバッグします。ワークスペースUIを使用して、DCM PLANおよびDEPLOYコマンドを実行します。データベースカタログを参照して、\|dcm-object\|オブジェクトとその構成、管理対象オブジェクト、およびデプロイ履歴を確認します。ターゲットプロファイルを選択して、リンクされた\|dcm-object\|およびテンプレート化構成を自動的に使用します。
Snowflake CLIを使用したローカルIDE ソフトウェアエンジニアにとって非常に使いやすいカスタマイズされたインターフェース。	定義ファイルをローカルで作成および編集します。 Gitリポジトリに接続して、変更をプル/プッシュします。ディレクトリコンテキストとオプションのフラグを含む簡潔な\|sf-cli\|コマンド。豊富なフォーマット出力と、:file:`.json`ファイルとして保存するオプション。エージェントまたは支援型開発のためにCortex Code CLIを活用するオプション。ローカルIDEでの\|sf-cli\|のインストールと実行について詳しくは、:ref:`label-dcm_projects_snowflake_cli`を参照してください。
Cortexコード Snowflake向けのエージェントAIツール。詳細については、 \|dcm\|向けCortex Code をご参照ください。	AI支援またはエージェントによるローカル定義ファイルのオーサリング。静的分析およびDCM PLANコマンドの実行による、AI支援またはエージェント型のコード検証およびデバッグ。
SQLコマンド	Snowflake CLI REPL、ワークスペース、ノートブック、またはワークシートからSQLコマンドを実行します。追加の引数でコマンドをカスタマイズします。同じコマンドがすべてのSnowflake SQLインターフェースで機能します。

|dcm|向けCortex Code¶

Cortex Codeは、Snowflake向けのエージェントAIツールです。DCMスキルを有効にすると、Cortex Codeは自律的に|dcm|を作成、移行、デバッグ、デプロイできます。また、ステップバイステップで連携して作業することもできます。

注釈

DCMスキルを備えたCortex Codeは現在、Cortex Code CLI経由でのみ利用可能です。Snowsightワークスペースでは利用できません。

Cortex Code DCMスキルにより、以下が可能になります。

マニフェストファイル、フォルダー構造、定義ファイルなど、新しい|dcm-object|をゼロから構築します。
DEFINEステートメント、Jinjaテンプレート、およびマクロを作成および編集します。
PLAN、DEPLOY、REFRESH、TEST、およびPREVIEWコマンドを実行します。
計画の出力を解釈し、障害を診断して、修正を提案します。
デプロイメントアーティファクトをダウンロードして検査します。
既存の|dcm-object|をナビゲートして説明します。

Cortex Code DCMスキルを使い始めるには、次の手順に従います。

:doc:`Cortex Codeのインストール</user-guide/cortex-code/cortex-code-cli>`で説明されているように、Cortex Code CLIをインストールします。
ターミナルでCortex Codeを起動します。
`$dcm`スキルリファレンスを使用するか、自然言語プロンプトで`DCM`という用語を使用して、|dcm|と対話形式でやり取りします。

例:

「分析パイプライン用の新しいDCMプロジェクトを作成」
「PRODターゲットに対してプロジェクト計画を作成」
「前回の計画が失敗したのはなぜですか？」
「カスタマー支出のための新しい動的テーブル定義を追加」

Snowflake CLI の DCM Projects¶

|sf-cli|は、Snowflakeのコマンドラインインターフェースです。ローカルのIDEからSnowflakeアカウントとやり取りするために使用できるツールです。

DCMプロジェクトには、|sf-cli|バージョン3.16以降が必要です。:doc:`/developer-guide/snowflake-cli/installation/installation`で説明されているように、|sf-cli|をインストールまたはアップグレードします。
:doc:`Snowflakeの構成CLIおよびSnowflakeへの接続</developer-guide/snowflake-cli/connecting/connect>`で説明されているように、Snowflakeアカウントへの接続を構成します。有効な接続があることを確認します。
```
snow connection test
```
Gitリポジトリクローンのローカルディレクトリにナビゲートします。例:
```
cd ./Quickstarts/DCM_Quickstart_1
```
利用可能な|sf-cli| DCMコマンドを確認します。
```
snow dcm --help
```

Git統合¶

|dcm-object|定義ファイルが保存されているGitリポジトリに接続します。

Gitリポジトリから新しいワークスペースを作成します。
予定している変更のためのGitブランチを作成または選択します。

Snowflakeでは、ブランチからワークスペースエディターにファイルがクローンされます。
|dcm-object|定義ファイルがあるフォルダー、または作成したいフォルダーにナビゲートします。

DCM project の作成¶

予算のロールと権限¶

|dcm-object|オブジェクトを作成するユーザーのロールには、次のロールと権限が必要です。

CREATE DCM PROJECT ON SCHEMA権限。

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

DCM project の作成¶

次のオプションのいずれかを使用して|dcm-object|オブジェクトを作成します。

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

アクセス制御とロールの権限¶

スキーマレベルの|dcm-object|オブジェクトに対するロールベースのアクセス制御（RBAC）を、READ、MONITOR、またはOWNERSHIP権限に設定できます。

これらの権限は、ワークスペース、ステージ、またはリポジトリに格納されている定義ファイルのアクセス制御とは独立しています。


権限	説明	許可されている操作
READ	\|dcm-object\|オブジェクトが存在するかどうかを示します。 \|dcm-object\|によってデプロイされた、ユーザーのロールに表示されるオブジェクトと付与を一覧表示します。つまり、\|dcm-object\|に対するREADと、オブジェクト自体に対するREADの両方が必要になります。	SHOW DCM PROJECTS LIKE「%project」 DESCRIBE DCM PROJECT <project> SHOW ENTITIES IN DCM PROJECT <project>
MONITOR	すべてのアーティファクトを含む、完全なデプロイメント履歴へのアクセス権を付与します。変更を直接デプロイする能力なしで、実稼働のデプロイメントを分析、デバッグ、または監査する能力をロールに付与します。	すべてのREAD権限 DESCRIBE DCM PROJECT <project>（最新のデプロイメントのソースとデプロイメントパスを含む） INFORMATION_SCHEMA.DCM_DEPLOYMENT_HISTORY (project_name => 'db.schema.project') SHOW DEPLOYMENTS IN DCM PROJECT <project> LISTデプロイメント内のすべてのファイル GET\|dcm-object\|内のファイルへのアクセス
OWNERSHIP	\|dcm-object\|オブジェクトの作成に使用されるロールは、そのプロジェクトの所有者のロールです。変更をデプロイする能力をロールに付与します。プロジェクトがまだデプロイされていない場合に、プロジェクトの所有権を別のロールに譲渡する能力をロールに付与します。	すべてのMONITOR権限 EXECUTE DCM PROJECT <project> PLAN EXECUTE DCM PROJECT <project> DEPLOY EXECUTE DCM PROJECT <project> PREVIEW EXECUTE DCM PROJECT <project> REFRESH EXECUTE DCM PROJECT <project> TEST DROP DCM PROJECT <project> ALTER DCM PROJECT <project> DCM PROJECT <project> TO ROLE <role2>でのGRANT READ DCM PROJECT <project> TO ROLE <role2>でのGRANT MONITOR

注釈

Snowflakeの他のコマンドと同様に、:code:`EXECUTE DCM PROJECT`も、実行ユーザーが**セカンダリロールからの権限**を有効にしている場合、その権限を反映した状態で動作します。プロジェクト所有者ロール以外のロール権限を利用しないように、:code:`USE SECONDARY ROLES NONE;`を実行します。これにより、同じプライマリロールを持つ異なるサービスユーザーが実行する場合、どの環境においてもデプロイの挙動が一定に保たれることが保証されます。

DCM管理のオブジェクトの所有権¶

|dcm-object|をデプロイするロールは、デフォルトで、デプロイされたすべてのオブジェクトに対するOWNERSHIP権限を有しています。

プロジェクト定義には、他のロールへのGRANT OWNERSHIPステートメントを含めることができます。Snowflakeは、|dcm-object|所有者ロールが、保持する別の下位レベルのロールに対してのみDCM管理オブジェクトの所有権を付与することをお勧めします。その後、プロジェクト所有者ロールが新しいオブジェクト所有者ロールの権限を「継承する」ため、プロジェクトはこのオブジェクトを引き続き管理できます。

|dcm-object|所有者ロールが、自身が保持しない別のロールにDCM管理オブジェクトの所有権を付与すると、プロジェクト所有者ロールのオブジェクトに対する所有権はなくなります。それで、プロジェクトからこのデプロイされたオブジェクトを管理することはできなくなります。それ以降のデプロイは失敗します。この場合、オブジェクト定義をプロジェクトから削除するか、所有権をプロジェクト所有者ロールに戻す必要があります。

注釈

移行されたオブジェクトの場合、現在の状態と|dcm-object|の定義が同期されるよう、対応するGRANT OWNERSHIPステートメントもプロジェクト定義に追加することをお勧めします。

|dcm-object|を定義する¶

|dcm-object|はマニフェストファイルと1つまたは複数のSQLオブジェクト定義ファイルに基づいています。これらのファイルは通常、Gitリポジトリまたはローカルワークスペースに保存および管理されます。

マニフェストファイル
- 対応するアカウント識別子、|dcm-object|オブジェクト、これらのオブジェクトの所有者ロール、およびオプションのテンプレート構成を持つ、1つまたは複数のターゲット環境を指定します。
- オプションで、テンプレートのデフォルトと、:ref:`テンプレート変数<label-dcm_projects_files_configurations>`の値を持つ、1つまたは複数の構成を指定します。
オブジェクト定義ファイル
- この|dcm-object|で、合わせて管理するSnowflakeオブジェクト、付与、および期待値のグループを定義します。

|dcm-object|フォルダーと定義ファイルの設定方法、およびテンプレートを使用して|dcm-object|を定義する方法については、:ref:`label-dcm_projects_files`を参照してください。

|dcm-object|の計画¶

|dcm-object|を計画すると、デプロイメント前の変更をプレビューするためのドライランが実行されます。Snowflakeは:ref:`プロジェクト定義ファイル<label-dcm_projects_definition_files>`を既存のオブジェクトと比較し、どのオブジェクトが作成、変更、またはドロップされるかを表示します。アカウントに変更は加えられません。

DCMプロジェクトをデプロイする前に、計画を使用して変更を精査し、検証します。:ref:`設定<label-dcm_projects_files_configurations>`や計画結果の出力パスなどのオプションを指定できます。

PLANは、DDLステートメントを実行しないことを除いて、実際には可能な限りDEPLOYコマンドを模倣します。

重要

デプロイ前に常にプロジェクトでPLANコマンドを実行して、構文、テンプレート、オブジェクトの依存関係、アクセス権限などのエラーがないことを確認します。計画の出力を精査してエラーをデバッグし、提供された変数でレンダリングされたJinjaをプレビューします。また、デプロイ後に発生する変更もプレビューします。

計画では次のステップが実行されます。

選択された構成プロファイルまたは実行時に提供された値で、すべてのJinjaテンプレートをレンダリングする。
前回のデプロイメントの一部として定義されたエンティティの現在の状態と、すべての定義を比較する。
定義されたすべてのステートメントをCREATE、ALTER、DROP、GRANT、およびREVOKEステートメントに変換する。
相互依存関係に基づいてすべてのステートメントを並べ替える。
すべてのステートメントをコンパイルする。

注釈

PLANはデプロイ中に発生する可能性のあるほぼすべてのエラーを補足しますが、デプロイの成功を保証するものではありません。

PLAN コマンドを実行します¶

PLANコマンドは、入力として次の情報を受け取ります。

マニフェストファイルへのパス

CLIはマニフェストからターゲットを読み取ります（default_target``または--target``フラグ）。SQLコマンドの場合は、マニフェストファイルへのパスとプロジェクト名を指定する必要があります。
Jinja変数の定義値（オプション）。
ターゲットの``templating_config``は自動的に構成プロファイルを選択します。SQLコマンドの場合、プロファイルを指定するにはUSING CONFIGURATION句を使用します。
上書きする構成プロファイルの1つまたは複数の値（オプション）。

以下は、PLANコマンドの実行方法の例です。

ローカルのIDEターミナルで、またはGitワークフローの一部として、:code:`snow dcm plan`コマンドを実行します。

ローカルディレクトリからDCMプロジェクトを計画するCLIコマンドの例は次のとおりです。

cd ./Quickstarts/DCM_Project_Quickstart_1/
snow dcm plan

SnowflakeステージまたはGitリポジトリクローンからDCMプロジェクトを計画するCLIコマンドの例は次のとおりです。

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

オプションの引数を使用してDCMプロジェクトを計画するCLIコマンドの例は次のとおりです。

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

変数は二重引用符で囲む必要があり、文字列値には追加の一重引用符が必要です。値のリストには角括弧が必要です。

Snowflake内の、またはSnowflakeに接続されたSQLコマンドを実行できる任意の場所から、SQLでDCM PLANを実行できます。PLAN`モードで:doc:/sql-reference/sql/execute-dcm-project`コマンドを使用します。

ワークスペースパスからDCMプロジェクトを計画するSQLコマンドの例は次のとおりです。

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

構成プロファイルでJinjaを使用し、``wh_size``および``teams``を上書きする場合に、DCMプロジェクトを計画するSQLコマンドの例は次のとおりです。

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV
  PLAN
  USING CONFIGURATION DEV (wh_size => 'MEDIUM', teams => ['TEAM_A', 'TEAM_B'])
FROM
  'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/Quickstarts/DCM_Project_Quickstart_9_36'

構成プロファイルなしでJinjaテンプレート化を使用する場合に|dcm-object|を計画するSQLコマンドの例は次のとおりです。

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV
  PLAN
  USING (wh_size => 'MEDIUM')
FROM
  'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/Quickstarts/DCM_Project_Quickstart_9_36';

定義ファイルパス¶

マニフェストファイルと定義ファイルの場所を参照する場合、次のオプションがあります。

ワークスペースパスから

Snowsightユーザーインターフェースは、現在のワークスペース内にあるすべての|dcm-object|定義を自動的に一覧表示します。これらのパスのいずれかを選択すると、ワークスペースによりそれが使用され、DCMコマンドが実行されます。

ワークスペースで手動によりSQLコマンドを実行する場合、任意のワークスペース内の同じパスを参照することもできます。

ヒント：ワークスペース内にあるすべてのファイルの背後にあるスリードットメニューを使用すると、そのファイルへのフルパスをSQLコードにコピーできます。

ワークスペースパスからDCMプロジェクトを計画するSQLコマンドの例は次のとおりです。
```
EXECUTE DCM PROJECT DCM_PROJECT_DEV
  PLAN
  USING CONFIGURATION DEV
FROM
  'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/Quickstarts/DCM_Project_Quickstart_1'
```
ディスク上のローカルGitリポジトリクローンから

ローカルのIDEでCLIコマンドを実行する前に、``manifest.yml``ファイルを含むディレクトリを選択します。または、使用するマニフェストと定義を含む別のローカルディレクトリを指定することもできます。

ローカルGitリポジトリの現在のディレクトリから|dcm-object|を計画するCLIコマンドの例は次のとおりです。
```
cd ./Quickstarts/DCM_Project_Quickstart_1/

snow dcm plan

snow dcm plan --target PROD
```
ローカルGitリポジトリクローンの別のディレクトリから|dcm-object|を計画するCLIコマンドの例は次のとおりです。
```
snow dcm plan DCM_PROJECT_DEV --configuration DEV --from ./Quickstarts/DCM_Project_Quickstart_2/
```
ワークフロー内のリモートリポジトリから

同じCLI構文は、DCMコマンドがCI/CDワークフローで実行される場合に使用できます。CLIを直接呼び出すか、SnowflakeラボのDCMリポジトリから再利用可能GitHubアクションを使用して、CLI設定、認証、およびDCMコマンドを内部的に使用します。

再利用可能 dcm-plan アクションの使用例：
```
steps:
  - uses: actions/checkout@v4
  - uses: Snowflake-Labs/snowflake-dcm-projects/actions/dcm-plan@v1
    with:
      target: PROD
      project-path: Quickstarts/DCM_Project_Quickstart_1/
      snowflake-user: ${{ env.SNOWFLAKE_USER }}
```
Snowflake内のステージまたはGitリポジトリクローンから

DCMコマンドを実行するPROCEDUREまたはTASKをSnowflake内で実行する場合、このSQLコマンドは、アカウント内のSnowflakeステージまたはGitリポジトリクローンへの絶対パスを参照できます。

Gitリポジトリクローンの場合は、最新バージョンを利用するために、まずALTER GIT REPOSITORY FETCHの実行を検討してください。

``'@...'``パスは、DCM SQLコマンドを実行する場合にのみ使用できます。

SnowflakeのステージまたはGitリポジトリクローンからDCMプロジェクトを計画するSQLコマンドの例は次のとおりです。
```
EXECUTE DCM PROJECT DCM_PROJECT_DEV
  PLAN
  USING CONFIGURATION DEV
FROM
  '@DCM_DEMO.DEPLOY.DCM_DEMO/branches/main/Quickstarts/DCM_Project_Quickstart_1/'
```

計画の出力¶

PLANおよびDEPLOY出力形式（JSONスキーマや例など）について詳しくは、:doc:`/sql-reference/sql/execute-dcm-project`コマンドリファレンスの:ref:`PLANおよびDEPLOY出力<label-dcm_projects_plan_deploy_output>`セクションを参照してください。

|dcm-object|のデプロイ¶

|dcm-object|を展開するとき、次のアクションが実行されます。

定義されているがまだ存在しないオブジェクトは作成されます。
既に存在するが現在の定義と異なるオブジェクトは変更されます。
定義されたとおりにすでに存在するオブジェクトはスキップされます。
すでに存在するが定義されなくなったオブジェクトはドロップされます。

プロジェクトで定義された権限付与とアタッチされたデータ品質の期待値にも、同じ動作が適用されます。

重要

意図しないデータの損失を避けるため、DEPLOYを実行する前に、常にPLANを実行して出力を精査してください。

各|dcm-object|は、常に1つのインスタンスのみをデプロイできます。複数の構成プロファイルを共存させることはできません。同じ|dcm-object|で構成Bをデプロイすると、Bで定義されていない以前の他の構成のオブジェクトはすべてドロップされます。

ターゲット環境ごとに単一の|dcm-object|を作成します。その後、各環境の|dcm-object|は同じ定義ファイルを参照しつつ、``suffix => 'DEV_JS'``のように各変数の異なる値を使用し独立してデプロイできるため、同じSnowflakeアカウント上にそれぞれ独立して存在できます。

事前定義されたプロファイルを少し変更して使用する場合は、実行時に選択した変数の値を上書きできます。

例:

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV
  DEPLOY
  USING CONFIGURATION DEV (suffix=>'DEV_USER', user=>'JANEDOE')
FROM
  'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/DCM_Project_Quickstart_1';

snow dcm deploy DCM_PROJECT_DEV --configuration DEV --variable "suffix='DEV_USER'" --variable "user='JANEDOE'"

各デプロイ試行（成功、失敗、またはキャンセル）には、デプロイ番号（たとえば``DEPLOYMENT$1``など）が付与されます。デプロイ履歴での可視性を高めるために、オプションで一意の文字列を指定し、個々のデプロイに名前を付けるデプロイエイリアスとして使用できます。デプロイエイリアスは、コード変更のコミットメッセージのようなものと考えてください。

各DEPLOYコマンドは、デプロイの一部として、まず内部のPRE-PLANを実行します。PRE-PLANが成功した場合、その直後にDEPLOYが実行されます。この内部プランのステップを中断または精査するオプションはありません。PRE-PLANは、デプロイ中の障害のリスクをさらに軽減するために実行されます。DEPLOYが失敗した場合、PRE-PLANステップとDEPLOYステップのどちらで失敗したかをエラーメッセージで確認できます。PRE-PLANステップでの失敗はPLANと似ており、DDLの変更は実行されません。

重要

DEPLOYステップでの失敗により、定義された変更が部分的に実行される場合があります。これにより、管理オブジェクトの一部が未定義の状態になる可能性があります。ほとんどの場合、根本原因を修正してDEPLOYを再度実行すると、定義されたターゲット状態に復元されます。

DEPLOY出力ファイルのターゲットパスはカスタマイズできません。デプロイメントのアーティファクトは常に|dcm-object|内に保存されます。

DEPLOY コマンドを実行します¶

DEPLOYコマンドを実行するには、次の入力を指定します。

マニフェストファイルへのパス。
マニフェストで構成プロファイルが定義されている場合は、構成プロファイル名を指定する必要があります。
デフォルト値を上書きする構成プロファイルの値（オプション）。
デプロイ*エイリアス*（オプション）。

以下は、DEPLOYコマンドの実行方法の例です。

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

構成プロファイルでJinjaを使用し、``wh_size``および``teams``を上書きする場合に、|dcm-object|をデプロイするSQLコマンドの例は次のとおりです。

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';

:code:`snow dcm deploy`は、ローカルのIDEターミナル、またはGitワークフローの一部として実行できます。

ローカルディレクトリから|dcm-object|をデプロイするCLIコマンドの例は次のとおりです。

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

デフォルト以外の環境をターゲットにして|dcm-object|をデプロイするCLIコマンドの例は次のとおりです。

snow dcm deploy --target PROD_US

オプション引数を指定して|dcm-object|をデプロイするCLIコマンドの例は次のとおりです。

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

標準計画の出力構造については、:ref:`label-dcm_projects_plan_deploy_output`を参照してください。

|dcm-object|を管理する¶

|dcm-object|が管理するすべてのオブジェクトを表示¶

:doc:`/sql-reference/sql/show-entities-in-dcm-project`コマンドを使用すると、特定の|dcm-object|によって現在管理されているすべてのSnowflakeオブジェクトのリストを表示できます。すべてのオブジェクトに関する完全修飾名のリストを提供します。結果を表示するには、|dcm-object|に対するREAD権限と、管理対象オブジェクト自体を表示する権限の両方が必要です。

注釈

結果は、必ずしも最新のデプロイのオブジェクトと一致するとは限りません。プロジェクトから手動でドロップまたは切り離されたオブジェクトは、結果に一覧表示されません。

:code:`LIKE`を使用して名前で検索するか、フロー演算子を使用して結果セットに対し追加の処理やフィルタリングを実行できます。

同様に、このプロジェクトで定義およびデプロイされた権限について、SHOW GRANTSおよびSHOW FUTURE GRANTSを実行できます。

現在|dcm-object|によって管理されているすべてのオブジェクトを表示する例は次のとおりです。

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;

|dcm-object|からのオブジェクトの切り離し¶

再度デプロイする前に、:ref:`プロジェクト定義ファイル<label-dcm_projects_definition_files>`から対応するDEFINEステートメントを必ず削除してください。そうでない場合、オブジェクトは|dcm-object|に再統合されます。

|dcm-object|からオブジェクトを切り離すSQLコマンドの例は次のとおりです。

ALTER TABLE MY_DB.MY_SCH.MY_TABLE
  UNSET DCM PROJECT;

デプロイ済みの権限付与や期待値は、DCMプロジェクトから切り離すことはできません。

|dcm-object|のドロップ¶

|dcm-object|オブジェクトがドロップされた場合、管理対象のすべてのエンティティ、権限付与、および期待値は「管理対象外」としてそのまま残ります。

重要

|dcm-object|オブジェクトをドロップまたは置換すると、オブジェクトに含まれるすべてのデプロイ履歴アーティファクトが失われます。

DROP DCM PROJECT [IF EXISTS] <my_project>;

snow dcm drop my_project

|dcm-object|デプロイの自動化¶

CI/CDベストプラクティス¶

CI/CDパイプラインを使用してデプロイメントを自動化する場合は、次のプラクティスに従ってください。

本番以外の環境をターゲットとする|dcm-object|は、誤って本番環境にデプロイされるのを避けるため、本番環境に対応するオブジェクトとは異なるロールにより、所有されている必要があります。
本番環境をターゲットとする|dcm-object|は、プロジェクト内のすべてのオブジェクトをデプロイできる特別に調整されたアクセス権限を持つ、本番デプロイ専用のロールにより、所有されている必要があります。
- |dcm-object|の所有権向けに、一般的な管理者ロールを使用しないでください。そのようなロールはサービスユーザーにのみ付与し、個々の開発者には付与しないでください。
- 個々の開発者ではなく、サービスユーザーにのみ専用の本番デプロイロールを付与します。
- 重要なインフラやデータ製品の不変性を確保するため、所有権を本番デプロイロールに制限します。
  
  専用の本番デプロイロールが本番オブジェクトの所有権を他のロールに付与した場合、それらのロールを付与されたユーザーは本番オブジェクトを変更またはドロップできます。

GitHub アクション¶

SnowflakeラボのDCMリポジトリは、 DCM Projects パイプラインを自動化する再利用可能な複合GitHubアクションのセットを提供します。各アクションはライフサイクルの1つのステップを処理し、独自のワークフローからそれらを参照してエンドツーエンドのCI/CDパイプラインを構築できます。ワークフロー構文のみがプラットフォーム間で異なります。同じCI/CD概念がAzure DevOps、GitLab CI/CD、Bitbucket Pipelinesなどに適用されます。

注釈

SnowflakeラボのDCMリポジトリのGitHubアクションは評価目的のためにそのまま提供されます。Snowflakeによって公式にサポートされていません。自分のリスクで使用してください。

次の再利用可能なアクションが利用可能です。


アクション	説明
`dcm-parse-manifest`	`manifest.yml` を解析し、ターゲット名をマトリックス戦略のためのJSON配列として出力します。
`dcm-connection-test`	Snowflake接続をテストし、接続ロールがマニフェスト `project_owner` と一致することを検証し、 DCM project オブジェクトが既に存在するかどうかをチェックします。
`dcm-plan`	`snow dcm plan` を実行し、変更セット（オブジェクトドメインごとのCREATE、ALTER、DROPのカウント）を要約し、プランアーティファクトのアップロードを行います。オプションで、関連するプルリクエストへのコメントとしてプラン概要を投稿します。
`dcm-deploy`	オプションのデータドロップ検出、動的テーブルのリフレッシュ、期待値テスト、デプロイ後SQLスクリプトを備えた、DCM project をデプロイします。オプションで、デプロイ概要をプルリクエストに投稿します。

ワークフローでアクションを使うには、以下で参照します。

- uses: Snowflake-Labs/snowflake-dcm-projects/actions/<action-name>@v1

各アクションの入出力の完全なドキュメントについては、アクションREADME をご参照ください。

前提条件¶

再利用可能GitHubアクションを使用する前に、次のセットアップ手順を完了します。

|dcm-object|ファイルをGitリポジトリに保存します。
各マニフェストターゲットに対して GitHub環境 を作成します（例： DCM_STAGE 、 DCM_PROD_US ）。環境の名前は manifest.yml のターゲット名と一致している必要があります。
ワークフロー env ブロック内、またはGitHubリポジトリ変数として SNOWFLAKE_USER および DCM_PROJECT_PATH 変数を設定します。

ワークフローに必要な権限を付与します。

permissions:
  id-token: write       # Required for OIDC authentication
  contents: read
  pull-requests: write  # Required only when using comment-on-pr

認証¶

すべてのアクションは、 Snowflake CLI GitHubアクションを使用して認証します。OIDC（OpenID Connect）は、パスワードや秘密キーを秘密情報として保存する必要がないGitHubの組み込みIDトークンを使用するため、推奨されるアプローチです。

OIDC認証を構成するには、GitHubのOIDCプロバイダー信頼するワークロードIDを持つSnowflakeサービスユーザーを作成します。

CREATE USER SVC_GITHUB_ACTIONS
  TYPE = SERVICE
  DEFAULT_ROLE = 'PUBLIC'
  COMMENT = 'GitHub Actions service user for CI/CD via OIDC'
  WORKLOAD_IDENTITY = (
    TYPE = OIDC
    ISSUER = 'https://token.actions.githubusercontent.com'
    SUBJECT = 'repo:<owner>/<repo>:environment:<env_name>'
  );

<owner>/<repo> をあなたのGitHubリポジトリと置き換え、 <env_name> をGitHub環境名（例： DCM_STAGE ）と置き換えます。複数の環境がある場合は、環境ごとに個別のサービスユーザーを作成するか、サブジェクトクレームのカスタマイズを使用します。次に、サービスユーザーにマニフェスト内で project_owner として指定されたロールを付与します。

OIDCが使用できない場合、アクションはパスワード、PAT、キーペア認証もサポートします。セットアップ手順については、アクションのREADME認証セクションをご参照ください。

サンプルワークフロー¶

SnowflakeラボのDCMリポジトリ内の GitHubワークフローディレクトリには、再利用可能なアクションを完全なCI/CDパイプラインに構成ためにすぐに使えるワークフローファイルが含まれています。リポジトリの .github/workflows/ ディレクトリにコピーし、プロジェクト用にカスタマイズできます。完全な設定の手順については、ワークフローのサンプル README をご参照ください。

すべてのサンプルワークフローは、環境固有の構成が重複するGitHubシークレットではなく、バージョン管理された manifest.yml 内に保持されるように、マニフェストターゲットからSnowflake account_identifier および project_owner ロールを直接読み取ります。サービスユーザーの認証情報のみがシークレットとして保存されます。

サンプルワークフローは、任意の|dcm| CI/CDセットアップに適用可能な次のパターンを示しています。

マニフェスト駆動型の構成 ：各ワークフローはマニフェストターゲットから account_identifier 、 project_owner 、 project_name を読み取り、環境構成を1か所で管理します。
データドロップ保護 ：デプロイワークフローは、データを保持するオブジェクト（データベース、スキーマ、テーブル、ステージ）に対する破壊的なDROP操作を検出し、見つかった場合はデプロイをブロックします。
ステージから本番環境への順次昇格 ：実稼働へのデプロイは、ステージングのデプロイが成功し、動的テーブルが更新され、データ品質テストに合格した後にのみ開始されます。
プルリクエストのコメント ：計画とデプロイの概要は、元のプルリクエストにコメントとして投稿されます。

サンプルワークフロー：接続をテストする¶

ワークフロー構成ファイル：DCM_1_Test_Connections.yml
トリガー：``workflow_dispatch``イベントを使用した手動トリガー

このワークフローでは、GitHubアクションのサービスユーザーが、マニフェストで定義されたすべてのターゲット環境に接続できるかどうかを検証します。新しいリポジトリのセットアップ、新しいアカウントのオンボーディング、または認証問題のデバッグ時に使用します。ワークフローでは次の手順を実行します。

``manifest.yml``のすべてのターゲット名を動的に解析する。
GitHubアクションマトリックス戦略を使用して、各ターゲットを並行してテストする。
各ターゲットについて、Snowflake接続を検証し、接続されたアカウント、ユーザー、およびロールをレポートし、接続されたロールが|dcm-object|の所有者と一致するかどうかを確認する。
|dcm-object|オブジェクトがすでに存在するかどうか、およびサービスユーザーがデプロイ権限を持っているかどうかをレポートする。

サンプルワークフロー：PRからメインをテストする¶

ワークフロー構成ファイル： DCM_2_Test_PR_to_main.yml
トリガー：``main``ブランチに対して開かれた、同期された、または再開されたプルリクエスト

このワークフローは、すべてのプルリクエストの統合テストとして、実稼働ターゲットに対するPLANを実行します。これにより、レビュアーは計画された変更の概要をプルリクエスト上で直接確認できます。ワークフローでは次の手順を実行します。

PRODターゲットに対して snow dcm plan を実行する。
``plan_result.json``を解析し、オブジェクトドメインごとにグループ化されたCREATE、ALTER、およびDROP操作を要約する。
後で検査できるようにプランアーティファクトをアップロードする。
プルリクエストへのコメントとして計画概要を投稿する。
PLANが失敗した場合にチェックを失敗させ、マージをブロックする。

サンプルワークフロー：本番環境へのデプロイ¶

ワークフロー構成ファイル： DCM_3_Deploy_to_Prod.yml
トリガー：``main``ブランチへのプッシュ（通常はマージされたプルリクエスト）

このワークフローは、単一の本番ターゲットにデプロイします。ステージング環境が不要な場合や、ステージングが別に処理される場合に使用します。ワークフローでは次の手順を実行します。

計画： snow dcm plan を実行し、変更セットを要約する。
データドロップ検出：計画に。データベース、スキーマ、テーブル、またはステージのDROP操作が含まれる場合、パイプラインをブロックする。
デプロイ``snow dcm deploy``を実行する。
ポストスクリプト（任意）：Jinja変数注入によりSQLポストフックスクリプトを実行する。
動的テーブルの更新（オプション）： snow dcm refresh を実行して新しい変換ロジックを適用する。
期待をテストする（オプション）： snow dcm test を実行してデータ品質の期待値を検証する。

デプロイ後、ワークフローはオプションで、元のプルリクエストにステータスの概要を送信します。

サンプルワークフロー：ステージにデプロイしてから実稼働¶

ワークフロー構成ファイル： DCM_4_Deploy_to_Stage_then_Prod.yml
トリガー：``main``ブランチへのプッシュ（通常はマージされたプルリクエスト）

このワークフローは、シーケンスプロモーションパイプラインを実装します。変更は最初にステージングにデプロイされ、エンドツーエンドで検証された後にのみ、実稼働にプロモーションされます。いずれかのステップが失敗した場合、パイプラインは停止し、実稼働には影響しません。

各ターゲットのデプロイシーケンス（STAGE、次にPROD）には次が含まれます。

計画： snow dcm plan を実行し、変更セットを要約する。
データドロップ検出：計画に。データベース、スキーマ、テーブル、またはステージのDROP操作が含まれる場合、パイプラインをブロックする。
デプロイ``snow dcm deploy``を実行する。
ポストスクリプト（任意）：Jinja変数注入によりSQLポストフックスクリプトを実行する。
動的テーブルの更新（オプション）： snow dcm refresh を実行して新しい変換ロジックを適用する。
期待をテストする（オプション）： snow dcm test を実行してデータ品質の期待値を検証する。

実稼働のデプロイは、すべてのステージングステップが合格した後にのみ開始されます。すべてのジョブが完了すると、ワークフローはオプションで、元のプルリクエストに最終的なステータス概要を投稿します。

よくある質問（FAQ）¶

既存のオブジェクトの名前を変更するにはどうすればよいですか？

DCMプロジェクトの外部でALTERコマンドを実行する。
定義を変更する。
PLANを実行して、新しい定義が新しい状態と一致すること（PLANに変更がないこと）を確認する。
DEPLOYを実行して、新しい状態を保存する。

DEFINEステートメントでまだサポートされていないオブジェクトをデプロイするにはどうすればよいですか？

DCMプロジェクトの計画またはデプロイを実行した後、別のSQLスクリプトでCREATE IF NOT EXISTSまたはCREATE OR REPLACEステートメントを実行できます。

どちらのオプションも、Jinja2テンプレート化とdry-runをサポートしています（dry-runはJinjaテンプレート化をレンダリングしますが、SQLのコンパイルが成功するかどうかは確認しません）。

例:

EXECUTE DCM PROJECT my_project
  PLAN ...
USING ...
FROM ...

EXECUTE IMMEDIATE
FROM
  'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/head/DCM_Project_Quickstart_1/hooks/post_hook.sql'
  USING (db => 'DEV')
  dry_run = TRUE      -- shows the rendered Jinja but does not verify successful compilation
;

snow dcm deploy --target DEV

snow sql -f hooks/post_hook.sql --variable "db='DEV'" --enable-templating JINJA

インターフェースツール	最適な用途
Snowsight Snowsightのワークスペースは、アカウント内のSnowflakeネイティブクラウドIDEです。	UI経由で、DCM定義ファイルを簡単に作成またはアップロードします。 Gitリポジトリに接続して、変更をプル/プッシュします。定義ファイルを精査、編集、およびデバッグします。ワークスペースUIを使用して、DCM PLANおよびDEPLOYコマンドを実行します。データベースカタログを参照して、\|dcm-object\|オブジェクトとその構成、管理対象オブジェクト、およびデプロイ履歴を確認します。ターゲットプロファイルを選択して、リンクされた\|dcm-object\|およびテンプレート化構成を自動的に使用します。
Snowflake CLIを使用したローカルIDE ソフトウェアエンジニアにとって非常に使いやすいカスタマイズされたインターフェース。	定義ファイルをローカルで作成および編集します。 Gitリポジトリに接続して、変更をプル/プッシュします。ディレクトリコンテキストとオプションのフラグを含む簡潔な\|sf-cli\|コマンド。豊富なフォーマット出力と、:file:`.json`ファイルとして保存するオプション。エージェントまたは支援型開発のためにCortex Code CLIを活用するオプション。ローカルIDEでの\|sf-cli\|のインストールと実行について詳しくは、:ref:`label-dcm_projects_snowflake_cli`を参照してください。
Cortexコード Snowflake向けのエージェントAIツール。詳細については、 \|dcm\|向けCortex Code をご参照ください。	AI支援またはエージェントによるローカル定義ファイルのオーサリング。静的分析およびDCM PLANコマンドの実行による、AI支援またはエージェント型のコード検証およびデバッグ。
SQLコマンド	Snowflake CLI REPL、ワークスペース、ノートブック、またはワークシートからSQLコマンドを実行します。追加の引数でコマンドをカスタマイズします。同じコマンドがすべてのSnowflake SQLインターフェースで機能します。