DCM Projects 배포 및 관리

이 항목에서는 계정을 포함하여 Snowflake 환경을 관리하기 위해 DCM Projects 를 생성하고 배포하는 방법에 대해 설명합니다.

DCM project 관리에는 다음 단계가 포함됩니다.

  1. DCM project 용 Snowflake 계정을 :ref:`준비 <label-dcm_projects_prepare>`합니다.

  2. 프로젝트 구성 및 프로젝트 파일의 오브젝트를 :ref:`정의 <label-dcm_projects_define>`합니다.

  3. DCM Projects 오브젝트를 :ref:`생성 <label-dcm_projects_create_object>`합니다.

  4. 배포 전에 제안된 변경 사항을 미리 볼 수 있도록 :ref:`계획 <label-dcm_projects_plan>`합니다.

  5. 프로젝트를 :ref:`배포 <label-dcm_projects_deploy>`합니다.

  6. 필요에 따라 프로세스를 모니터링, 업데이트 및 반복하여 프로젝트를 :ref:`유지 관리 <label-dcm_projects_manage>`합니다.

대규모 계정 인프라 변경 사항은 물론 프로젝트에 대한 증분 변경 사항을 지속적으로 배포할 수 있습니다.

단일 배포에서 대규모 계정 인프라 변경 사항을 0개에서 100개까지 변경하는 대신 프로젝트에 증분 변경 사항과 추가 사항을 지속적으로 배포하는 것이 좋습니다.

DCM project 를 위한 준비

DCM Projects 를 시작하려면 Snowflake 계정이 다음 전제 조건을 충족해야 합니다.

  • DCM Projects 오브젝트를 생성할 수 있는 데이터베이스와 스키마

  • DCM Projects 오브젝트를 생성하고 웨어하우스에서 쿼리를 실행할 수 있는 액세스 권한이 있는 역할

  • Snowflake CLI 의 경우, 임시 스테이지를 생성할 수 있는 권한이 있는 역할

이 섹션에서는 DCM Projects 를 준비하기 위해 완료해야 하는 작업에 대해 설명합니다.

  • Snowflake CLI 또는 Cortex CLI를 사용하려는 경우 :ref:`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 Workspace 또는 로컬 폴더에 복제하여 DCM Projects 명령을 테스트하고 DCM Projects 기능을 살펴볼 수 있는 리포지토리입니다.

  • 샘플 GitHub 작업 및 워크플로: Snowflake CLI를 사용하여 DCM 프로젝트를 테스트하고 배포하는 CI/CD 파이프라인 템플릿입니다.

인터페이스 도구

DCM Projects 에 사용할 수 있는 인터페이스 옵션은 다음과 같습니다.

인터페이스 도구

적합한 대상

Snowsight

Snowsight의 작업 공간은 계정의 Snowflake 네이티브 클라우드 IDE입니다.

  • UI를 통해 DCM 정의 파일을 쉽게 생성하거나 업로드합니다.

  • Git 리포지토리에 연결하여 변경 사항을 끌어오고 푸시합니다.

  • 정의 파일을 검토, 편집, 디버깅합니다.

  • 작업 공간 UI를 사용하여 DCM PLAN 및 DEPLOY 명령을 실행합니다.

  • 데이터베이스 카탈로그를 찾아보고 DCM project 오브젝트 및 해당 구성, 관리 오브젝트, 배포 기록을 확인합니다.

  • 대상 프로필을 선택하여 연결된 DCM project 및 템플릿 구성을 자동으로 사용합니다.

Snowflake CLI**를 사용한 **로컬 IDE

소프트웨어 엔지니어에게 가장 친숙하고 개인화된 인터페이스입니다.

  • 로컬에서 정의 파일을 생성하고 편집합니다.

  • Git 리포지토리에 연결하여 변경 사항을 끌어오고 푸시합니다.

  • 디렉터리 컨텍스트 및 선택적 플래그가 포함된 간결한 Snowflake CLI 명령입니다.

  • 풍부한 형식의 출력 및 .json 파일로 저장하는 옵션이 있습니다.

  • 에이전트 또는 보조 개발을 위해 Cortex Code CLI를 활용할 수 있는 옵션입니다.

  • 로컬 IDE에서의 Snowflake CLI 설치 및 실행에 대한 자세한 내용은 Snowflake CLI (DCM Projects). 섹션을 참조하세요.

Cortex Code

Snowflake용 에이전트 AI 도구입니다. 자세한 내용은 DCM Projects 의 Cortex Code 섹션을 참조하십시오.

  • AI 지원 또는 에이전트 기반 로컬 정의 파일의 작성입니다.

  • 정적 분석 및 DCM PLAN 명령을 실행하여 AI 지원 또는 에이전트 기반 코드 유효성 검사 및 디버깅을 수행합니다.

SQL 명령

  • Snowflake CLI REPL, 작업 공간, 노트북 또는 워크시트에서 SQL 명령을 실행합니다.

  • 추가 인자로 명령을 사용자 지정합니다.

  • 모든 Snowflake SQL 인터페이스에서 동일한 명령이 작동합니다.

DCM Projects 의 Cortex Code

Cortex Code는 Snowflake용 에이전트 AI 도구입니다. DCM 스킬이 활성화된 경우 Cortex Code는 자동으로 DCM Projects 를 생성, 마이그레이션, 디버깅 및 배포할 수 있습니다. 또한 단계별로 함께 작동할 수도 있습니다.

참고

DCM 스킬을 사용한 Cortex Code는 현재 Cortex Code CLI를 통해서만 사용할 수 있습니다. Snowsight Workspace에서는 사용할 수 없습니다.

Cortex Code DCM 스킬은 다음을 활성화합니다.

  • 매니페스트 파일, 폴더 구조 및 정의 파일을 포함하여 처음부터 새로운 DCM project 를 스캐폴딩합니다.

  • DEFINE 문, Jinja 템플릿, 매크로를 작성하고 편집합니다.

  • PLAN, DEPLOY, REFRESH, TEST, PREVIEW 명령을 실행합니다.

  • 계획 출력을 해석하고, 실패를 진단하고, 수정 사항을 제안합니다.

  • 배포 아티팩트를 다운로드하고 검사합니다.

  • 기존 DCM project 를 탐색하고 설명합니다.

Cortex Code DCM 스킬을 시작하려면 다음 단계를 따릅니다.

  1. :doc:`Cortex Code 설치하기 </user-guide/cortex-code/cortex-code-cli>`에 설명된 대로 Cortex Code CLI를 설치합니다.

  2. 터미널에서 Cortex Code를 시작합니다.

  3. $dcm 스킬 참조를 사용하거나 자연어 프롬프트에서 DCM 용어를 사용하여 DCM Projects 와 대화형으로 상호 작용합니다.

예:

  • “분석 파이프라인을 위한 새 DCM 프로젝트를 생성해줘”

  • “PROD 대상에 대한 프로젝트 계획을 세워줘”

  • “마지막 계획이 실패한 이유가 뭐야?”

  • “고객 지출에 대한 새로운 동적 테이블 정의를 추가해줘”

Snowflake CLI (DCM Projects).

Snowflake CLI 는 Snowflake용 명령줄 인터페이스입니다. 로컬 IDE에서 Snowflake 계정과 상호 작용하는 데 사용할 수 있는 도구입니다.

  1. DCM 프로젝트에는 Snowflake CLI 버전 3.16 이상이 필요합니다. Snowflake CLI 설치하기 에 설명된 대로 Snowflake CLI 를 설치하거나 업그레이드합니다.

  2. :doc:`Snowflake CLI 구성 및 Snowflake에 연결하기 </developer-guide/snowflake-cli/connecting/connect>`에 설명된 대로 Snowflake 계정에 대한 연결을 구성합니다. 연결이 작동하는지 확인합니다.

    snow connection test
    
  3. Git 리포지토리 복제본의 로컬 디렉터리로 이동합니다. 예:

    cd ./Quickstarts/DCM_Quickstart_1
    
  4. 사용할 수 있는 Snowflake CLI DCM 명령을 확인합니다.

    snow dcm --help
    

Git 통합

DCM project 정의 파일이 저장된 Git 리포지토리에 연결합니다.

  1. :ref:`Git 리포지토리에서 새 작업 공간을 생성 <label-create_a_git_workspace>`합니다.

  2. 계획된 변경 사항에 대한 Git 분기를 생성하거나 선택합니다.

    Snowflake는 해당 분기의 파일을 작업 공간 편집기로 복제합니다.

  3. DCM project 정의 파일이 있거나 해당 파일을 생성하려는 폴더로 이동합니다.

다음 경우에 |dcm-object|를 만듭니다.

필수 역할 및 권한

DCM project 오브젝트를 생성하는 사용자의 역할에는 다음과 같은 역할과 권한이 있어야 합니다.

  • CREATE DCM PROJECT ON SCHEMA 권한:

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

다음 경우에 |dcm-object|를 만듭니다.

다음 옵션 중 하나를 사용하여 DCM project 오브젝트를 생성합니다.

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

액세스 제어 및 역할 권한

READ, MONITOR 또는 OWNERSHIP 권한에 스키마 수준 DCM project 오브젝트의 역할 기반 액세스 제어(RBAC)를 설정할 수 있습니다.

이러한 권한은 작업 공간, 스테이지 또는 리포지토리에 저장된 정의 파일에 대한 액세스 제어와 무관합니다.

권한

설명

허용되는 작업

READ

  • DCM project 오브젝트가 존재하는지 여부를 표시합니다.

  • 사용자의 역할에 표시되는 DCM project 에서 배포한 오브젝트와 권한을 나열합니다.

    즉, DCM project 에 대한 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

  • DCM project 내부의 파일에 대한 모든 액세스 권한 GET

OWNERSHIP

  • DCM project 오브젝트를 생성하는 데 사용되는 역할은 해당 프로젝트의 소유자입니다.

  • 역할에 변경 사항을 배포할 수 있는 권한을 부여합니다.

  • 프로젝트가 아직 배포되지 않은 경우 역할에 프로젝트의 소유권을 다른 역할로 이전할 수 있는 권한을 부여합니다.

  • 모든 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 project 를 배포하는 역할에는 기본적으로 배포된 모든 오브젝트에 대한 OWNERSHIP 권한이 있습니다.

프로젝트 정의에는 다른 역할에 대한 GRANT OWNERSHIP 문이 포함될 수 있습니다. Snowflake는 DCM project 소유자 역할이 자신이 보유한 다른 하위 수준 역할에만 DCM 관리 오브젝트의 소유권을 부여할 것을 권장합니다. 그러면 프로젝트 소유자 역할이 새 오브젝트 소유자 역할의 권한을 “상속”하므로 프로젝트는 이 오브젝트를 계속 관리할 수 있습니다.

DCM project 소유자 역할이 자신이 보유하지 않은 다른 역할에 DCM 관리 오브젝트의 소유권을 부여하는 경우, 프로젝트 소유자 역할에 더 이상 소유권이 없으므로 프로젝트는 이 배포된 오브젝트를 더 이상 관리할 수 없습니다. 이후 배포는 실패합니다. 프로젝트에서 오브젝트 정의를 제거하거나 프로젝트 소유자 역할에 소유권을 다시 부여해야 합니다.

DCM project 에서 관리할 기존 오브젝트를 마이그레이션하려는 경우, DCM project 오브젝트를 소유한 역할에는 DCM project 에서 관리할 오브젝트에 대한 소유권 권한(직접 또는 다른 역할을 통해 상속됨)도 있어야 합니다.

참고

마이그레이션된 오브젝트인 경우 해당 GRANT OWNERSHIP 문을 프로젝트 정의에도 추가하여 현재 상태 및 DCM project 정의가 동기화되도록 하는 것이 좋습니다.

DCM project 정의

DCM project 는 매니페스트 파일과 하나 이상의 SQL 오브젝트 정의 파일을 기반으로 합니다. 이러한 파일은 일반적으로 Git 리포지토리 또는 로컬 작업 공간에 저장되고 관리됩니다.

  • 매니페스트 파일

    • 하나 이상의 대상 환경과 해당 계정 식별자, DCM project 오브젝트, 이러한 오브젝트의 소유자 역할 및 선택적 템플릿 구성을 지정합니다.

    • 선택적으로, 템플릿 기본값과 :ref:`템플릿 변수 <label-dcm_projects_files_configurations>`에 대한 값이 있는 하나 이상의 구성을 지정합니다.

  • 오브젝트 정의 파일

    • 이 DCM project 에서 함께 관리하려는 Snowflake 오브젝트, 권한 부여 및 기대치 그룹을 정의합니다.

DCM project 폴더 및 정의 파일을 설정하는 방법 및 템플릿을 사용하여 DCM project 를 정의하는 방법은 정의 파일을 저장할 DCM project 폴더 생성 섹션을 참조하세요.

DCM project 계획

DCM project 계획은 배포 전에 변경 사항을 미리 보기 위해 테스트 실행을 수행합니다. Snowflake는 :ref:`프로젝트 정의 파일 <label-dcm_projects_definition_files>`을 기존 오브젝트와 비교하여 생성, 변경, 삭제할 오브젝트를 보여줍니다. 계정에는 변경 사항이 없습니다.

계획을 사용하여 DCM 프로젝트를 배포하기 전에 변경 사항을 검토하고 유효성을 검사합니다. 구성 또는 계획 결과의 출력 경로와 같은 옵션을 지정할 수 있습니다.

PLAN은 DDL 문을 실제로 실행하지 않는다는 점을 제외하면 DEPLOY 명령을 최대한 모방합니다.

중요

배포 전에 항상 프로젝트에 PLAN 명령을 실행하여 구문, 템플릿, 오브젝트 종속성, 액세스 권한 등으로 인한 오류가 없는지 확인합니다. 계획 출력을 검토하여 오류를 디버깅하고, 제공된 변수로 렌더링된 Jinja를 미리 보고, 배포 후 변경 사항을 미리 봅니다.

이 계획은 다음 단계를 수행합니다.

  1. 선택한 구성 프로필 또는 런타임 시 제공된 값으로 모든 Jinja 템플릿을 렌더링합니다.

  2. 모든 정의를 마지막 배포의 일부로 정의된 엔터티의 현재 상태와 비교합니다.

  3. 정의된 모든 문을 CREATE, ALTER, DROP, GRANT 및 REVOKE 문으로 변환합니다.

  4. 해당 상호 종속성을 기반으로 모든 문을 정렬합니다.

  5. 모든 문을 컴파일합니다.

참고

PLAN은 배포 중에 발생할 수 있는 거의 모든 오류를 포착하지만 성공적인 배포를 보장하지는 않습니다.

PLAN 명령 실행

PLAN 명령은 다음 정보를 입력으로 사용합니다.

  • 매니페스트 파일의 경로

    CLI는 매니페스트(default_target 또는 --target 플래그)에서 대상을 읽습니다. SQL 명령의 경우 매니페스트 파일의 경로와 프로젝트 이름을 제공해야 합니다.

  • Jinja 변수에 대해 정의된 값(선택 사항).

  • 대상의 ``templating_config``는 구성 프로필을 자동으로 선택합니다. SQL 명령의 경우, USING CONFIGURATION 절을 사용하여 프로필을 지정합니다.

  • 덮어쓸 구성 프로필의 하나 이상의 값(선택 사항).

다음은 PLAN 명령을 실행하는 방법의 예제입니다.

로컬 IDE 터미널에서 또는 Git 워크플로의 일부로 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 CLI 명령

정의 파일 경로

매니페스트 및 정의 파일의 위치를 참조하는 옵션은 다음과 같습니다.

  • 작업 공간 경로에서

    Snowsight 사용자 인터페이스에는 현재 작업 공간 내의 모든 DCM project 정의가 자동으로 나열됩니다. 이러한 경로 중 하나를 선택할 수 있으며, 작업 공간은 이를 사용하여 DCM 명령을 실행합니다.

    작업 공간에서 SQL 명령을 수동으로 실행하려는 경우, 작업 공간 내에서 동일한 경로를 참조할 수도 있습니다.

    팁: 작업 공간의 모든 파일 뒤에 있는 점 3개 메뉴를 사용하면 해당 파일의 전체 경로를 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 project 를 계획하는 CLI 명령의 예제는 다음과 같습니다.

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

    로컬 Git 리포지토리 복제본의 다른 디렉터리에서 DCM project 를 계획하는 CLI 명령의 예제는 다음과 같습니다.

    snow dcm plan DCM_PROJECT_DEV --configuration DEV --from ./Quickstarts/DCM_Project_Quickstart_2/
    
  • 워크플로의 원격 리포지토리에서

    DCM 명령이 CI/CD 워크플로에서 실행되는 경우 동일한 CLI 구문을 사용할 수 있습니다.

    로컬 Git 리포지토리 복제본에서 DCM project 를 계획하는 CI/CD 워크플로의 예제는 다음과 같습니다.

    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
    
  • Snowflake의 스테이지 또는 Git 리포지토리 복제본에서

    DCM 명령을 실행하는 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/'
    

계획 출력

참고

미리 보기 단계에서는 정확한 출력 유형이 변경될 수 있습니다.

표준 계획 출력에는 JSON 형식의 계획 실행에 대한 다음 정보가 포함됩니다.

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>
          }
        ]
      }
    ]
  }
}

속성

설명

version

출력 형식의 스키마 버전입니다. 버전 2는 최신 버전이며 유일하게 지원되는 버전입니다.

metadata

실행에 대한 컨텍스트 정보입니다.

metadata.timestamp

명령이 실행된 시점의 ISO 8601 타임스탬프입니다.

metadata.query_id

이 계획을 생성한 쿼리의 고유 식별자입니다.

metadata.project_name

DCM 프로젝트 오브젝트의 정규화된 이름입니다.

metadata.user

명령을 실행한 사용자의 이름입니다.

metadata.role_name

명령을 실행하는 데 사용되는 활성 역할입니다.

metadata.command

실행된 명령입니다. PLAN 또는 ``DEPLOY``입니다.

changeset

변경 항목의 배열입니다. 각 항목은 생성, 변경 또는 삭제된 하나의 오브젝트를 나타냅니다. 빈 배열은 프로젝트 정의가 이미 계정과 동기화되어 있음을 나타냅니다.

changeset[].type

오브젝트에 대해 계획된 작업입니다. 가능한 값은 CREATE, ALTER, ``DROP``입니다.

changeset[].object_id

대상 오브젝트를 식별합니다.

changeset[].object_id.domain

Snowflake 오브젝트 유형입니다.

changeset[].object_id.name

오브젝트의 이름입니다.

changeset[].object_id.fqn

오브젝트의 정규화된 이름입니다.

changeset[].object_id.database

오브젝트가 포함된 데이터베이스입니다. 계정 수준 오브젝트의 경우 생략됩니다.

changeset[].object_id.schema

오브젝트가 포함된 스키마입니다. 데이터베이스 수준 및 계정 수준 오브젝트의 경우 생략됩니다.

changeset[].changes

특정 특성 수정 사항을 자세히 설명하는 변경 설명자의 배열입니다.

changeset[].changes[].kind

변경 유형입니다. 가능한 값: set, changed, unset, nested, collection. kind 값에 따라 오브젝트의 나머지 키가 결정됩니다.

changeset[].changes[].attribute_name

설정되거나 변경되는 특성의 이름입니다. kind``가 ``set, changed 또는 ``unset``인 경우 표시됩니다.

changeset[].changes[].value

특성의 새 값입니다. kind``가 ``set 또는 ``changed``인 경우 표시됩니다.

changeset[].changes[].prev_value

변경 전 속성의 이전 값입니다. ``kind``가 ``changed``인 경우에만 표시됩니다.

changeset[].changes[].collection_name

수정 중인 컬렉션의 이름(예: columns, constraints, privileges, expectations)입니다. ``kind``가 ``collection``인 경우에만 표시됩니다.

changeset[].changes[].id_label

컬렉션 내의 항목을 식별하는 데 사용되는 레이블(예: name)입니다. 특정 컬렉션에만 표시됩니다.

changeset[].changes[].changes

컬렉션 항목 설명자의 중첩된 배열입니다. ``kind``가 ``collection``인 경우에만 표시됩니다.

changeset[].changes[].changes[].kind

컬렉션 항목에 대한 변경 유형입니다. 가능한 값은 added, removed, ``modified``입니다.

changeset[].changes[].changes[].item_id

컬렉션 내의 항목을 식별합니다. 컬렉션 유형에 따라 문자열 또는 오브젝트일 수 있습니다.

changeset[].changes[].changes[].changes

이 항목에 대한 추가 변경 설명자의 배열입니다. addedmodified 항목의 경우 표시됩니다. removed 항목의 경우 항상 표시되지 않습니다.

계획 출력의 예제:

{
  "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": []
    }
  ]
}

DCM project 배포

DCM project 를 배포할 때 다음 작업이 수행됩니다.

  • 정의되었지만 아직 존재하지 않는 오브젝트가 생성됩니다.

  • 이미 존재하지만 현재 정의와 다른 오브젝트가 변경됩니다.

  • 정의된 대로 이미 존재하는 오브젝트는 건너뜁니다.

  • 이미 존재하지만 더 이상 정의되지 않은 오브젝트가 삭제됩니다.

프로젝트에 정의된 권한 부여 및 첨부된 데이터 품질 기대치에도 동일한 동작이 적용됩니다.

중요

의도하지 않은 데이터 손실을 방지하려면 항상 DEPLOY를 실행하기 전에 실행하고 **PLAN 출력을 검토**합니다.

DCM project 는 한 번에 하나의 인스턴스만 배포할 수 있습니다. 여러 구성 프로필을 함께 사용할 수 없습니다. 동일한 DCM project 로 구성 B를 배포하면 B에 정의되지 않은 다른 이전 구성의 모든 오브젝트가 삭제됩니다.

각 대상 환경에 대한 하나의 DCM project 를 생성합니다. 그러면 각 환경에 대한 DCM project 가 동일한 정의 파일을 가리키지만 ``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 project 내부에 저장됩니다.

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

구성 프로필이 있지만 wh_size``teams``를 덮어쓰는 Jinja를 사용할 때 DCM project 를 계획하는 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';

표준 계획 출력 구조의 경우 계획 출력 섹션을 참조하세요.

DCM project 관리

DCM project 에서 관리하는 모든 오브젝트 표시

SHOW ENTITIES IN DCM PROJECT 명령을 사용하면 현재 특정 DCM project 에서 관리하는 모든 Snowflake 오브젝트의 목록을 볼 수 있습니다. 모든 오브젝트의 정규화된 이름 목록을 제공합니다. 결과를 확인하려면 사용자에게 DCM project 에 대한 READ 권한 및 관리 오브젝트 자체를 확인할 수 있는 권한이 모두 필요합니다.

참고

결과가 가장 최근 배포의 오브젝트와 반드시 일치하는 것은 아닙니다. 프로젝트에서 수동으로 삭제하거나 분리한 오브젝트는 결과에 나열되지 않습니다.

:code:`LIKE`를 사용하여 이름으로 검색하거나 흐름 연산자를 사용하여 결과 세트를 추가로 처리 또는 필터링할 수 있습니다.

마찬가지로, 이 프로젝트와 함께 정의되고 배포되는 SHOW GRANTS 및 SHOW FUTURE GRANTS 권한도 사용할 수 있습니다.

현재 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;

DCM project 에서 오브젝트 분리

ALTER <오브젝트> 명령과 UNSET DCM PROJECT 절을 사용하면 배포된 후 현재 DCM project 에서 관리되는 오브젝트를 분리할 수 있습니다. 이 명령은 오브젝트를 삭제하지 않고 오브젝트와 DCM project 간의 연결을 제거합니다. 다른 DCM project 로 오브젝트 관리를 시작하려는 경우 이 명령을 사용할 수 있습니다.

다시 배포하기 전에 :ref:`프로젝트 정의 파일 <label-dcm_projects_definition_files>`에서 해당 DEFINE 문을 제거해야 합니다. 그렇지 않으면 오브젝트가 DCM project 에 다시 통합됩니다.

DCM project 에서 오브젝트를 분리하는 SQL 명령의 예제는 다음과 같습니다.

ALTER TABLE MY_DB.MY_SCH.MY_TABLE
  UNSET DCM PROJECT;

배포된 권한 부여 또는 실행은 DCM 프로젝트에서 분리할 수 없습니다.

DCM project 삭제

DCM project 오브젝트가 삭제되더라도 관리되는 모든 엔터티, 권한 부여 및 기대치는 “관리되지 않는” 상태로 유지됩니다.

중요

DCM project 오브젝트를 삭제하거나 바꾸면 오브젝트에 포함된 모든 배포 기록 아티팩트가 손실됩니다.

DROP DCM PROJECT [IF EXISTS] <my_project>;

DCM project 배포 자동화

CI/CD 모범 사례

CI/CD 파이프라인을 사용하여 배포를 자동화할 때 다음 사례를 따릅니다.

  • 비프로덕션 환경을 대상으로 하는 DCM project 는 프로덕션 환경에 실수로 배포하는 것을 방지하기 위해 프로덕션 환경과 다른 역할이 소유해야 합니다.

  • 프로덕션 환경을 대상으로 하는 DCM project 는 프로젝트의 모든 오브젝트를 배포하기에 충분한 특별히 맞춤화된 액세스 권한이 있는 프로덕션 배포를 위한 전용 역할이 소유해야 합니다.

    • DCM project 소유권에 일반 관리자 역할을 사용하지 마세요. 개별 개발자가 아닌 서비스 사용자에게만 이러한 역할을 부여합니다.

    • 개별 개발자가 아닌 서비스 사용자에게만 전용 프로덕션 배포 역할을 부여합니다.

    • 중요한 인프라 또는 데이터 제품의 불변성을 보장하기 위해 소유권을 프로덕션 배포 역할로 제한합니다.

      전용 프로덕션 배포 역할이 프로덕션 오브젝트의 소유권을 다른 역할에 부여하는 경우 해당 역할이 부여된 사용자는 프로덕션 오브젝트를 계속 수정하거나 삭제할 수 있습니다.

GitHub Actions 예제

이 섹션에서는 DCM Projects 에 대한 일반적인 CI/CD 패턴을 보여주는 샘플 GitHub Actions 워크플로를 제공합니다. Azure DevOps, GitLab CI/CD 또는 Bitbucket Pipelines와 같은 다른 Git 기반 플랫폼에도 동일한 개념이 적용되며, 워크플로 구문만 다릅니다.

각 샘플은 파이프라인 설정, 환경 토폴로지, 조직 요구 사항에 따라 사용자 지정하고 결합할 수 있는 구성 요소를 제공합니다.

샘플 워크플로는 모든 DCM CI/CD 설정에 적용 가능한 다음 패턴을 보여줍니다.

  • 매니페스트 기반 구성 각 워크플로는 매니페스트 대상에서 account_identifier, project_owner, ``project_name``을 읽습니다. 이를 통해 환경 구성이 한 곳에 유지되고 GitHub 시크릿에서 중복되는 것을 방지할 수 있습니다.

  • 데이터 삭제 방지 배포 워크플로는 ``plan_result.json``을 구문 분석하여 데이터베이스, 스키마, 테이블, 스테이지와 같은 데이터가 포함된 오브젝트에 대한 파괴적인 DROP 작업을 감지하고 해당 작업이 발견되면 배포를 차단합니다.

  • 스테이지에서 프로덕션으로 순차적인 승격 프로덕션 배포는 스테이징 배포가 성공하고 동적 테이블을 새로 고치고 데이터 품질 테스트를 통과한 후에만 시작됩니다.

  • 정형 계획 출력 구문 분석 워크플로는 ``jq``를 사용하여 ``plan_result.json``에서 작업 수 및 오브젝트 도메인을 추출하므로 사용자 지정 요약 및 검사를 쉽게 빌드할 수 있습니다.

  • AI 기반 요약 ``snow cortex complete``은 GitHub 작업 요약에 대한 후처리 스크립트 결과 및 동적 테이블 새로 고침 출력의 자연어 요약을 생성합니다.

이러한 샘플 워크플로를 실행하기 전에 다음 전제 조건을 완료합니다.

  • DCM project 파일을 Git 리포지토리에 저장합니다.

  • 사용자에게 GitHub Actions를 생성하고 실행할 수 있는 권한을 부여합니다.

  • Snowflake 서비스 사용자 자격 증명(SNOWFLAKE_USER, SNOWFLAKE_PASSWORD 또는 개인 액세스 토큰)에 대한 GitHub 시크릿을 구성합니다.

  • DCM project 폴더 경로(DCM_PROJECT_PATH)에 대한 GitHub 변수를 구성합니다.

  • 각 매니페스트 대상(예 :DCM_STAGE, DCM_PROD_US)에 대한 GitHub 환경을 구성합니다.

GitHub Actions에서 Snowflake 연결 설정에 대한 내용은 블로그 게시물 `GitHub Actions CI/CD에 대한 실용적인 가이드 <https://medium.com/@uche.nkadi/automate-your-dbt-project-on-snowflake-a-practical-guide-to-github-actions-ci-cd-a366b6e061e5>`_의 전반부를 참조하세요.

DCM Projects 의 전체 CI/CD 수명 주기를 다루는 GitHub Actions 워크플로의 세트에 대한 내용은 `Snowflake-labs DCM 리포지토리 <https://github.com/Snowflake-Labs/snowflake_dcm_projects/GitHub_workflows>`_를 참조하세요.

모든 샘플 워크플로는 yq``를 사용하여 매니페스트 대상에서 Snowflake ``account_identifierproject_owner 역할을 직접 읽으므로 환경별 구성은 중복된 GitHub 시크릿이 아닌 버전 제어되는 ``manifest.yml``에 저장됩니다. 서비스 사용자 자격 증명만 시크릿으로 저장됩니다.

샘플 워크플로: 연결 및 권한 유효성 검사

이 워크플로는 GitHub Actions 서비스 사용자가 매니페스트에 정의된 모든 대상 환경에 연결할 수 있는지 확인합니다. 새 리포지토리를 설정하거나, 새 계정을 온보딩하거나, 인증 문제를 디버깅할 때 사용합니다. 워크플로는 다음 단계를 수행합니다.

  • ``manifest.yml``의 모든 대상 이름을 동적으로 구문 분석합니다.

  • GitHub Actions 매트릭스 전략을 사용하여 각 대상을 병렬로 테스트합니다.

  • 각 대상에 대해, Snowflake 연결을 확인하고, 연결된 계정, 사용자, 역할을 보고하고, 연결된 역할이 DCM project 소유자와 일치하는지 확인합니다.

  • DCM project 오브젝트가 이미 존재하고 서비스 사용자에게 배포 권한이 있는지 여부를 보고합니다.

샘플 워크플로: 끌어오기 요청 시 변경 사항 미리 보기

  • 워크플로 구성 파일: DCM_1_Test_PR_to_main.yml

  • 트리거: main 분기에 대한 끌어오기 요청이 열렸거나, 동기화되거나, 다시 열렸습니다.

이 워크플로는 모든 끌어오기 요청에 대한 통합 테스트로 스테이징 및 프로덕션 대상 모두에 대해 PLAN을 실행합니다. 끌어오기 요청 시 계획된 변경 사항에 대한 요약을 검토자에게 직접 제공합니다. 워크플로는 다음 단계를 수행합니다.

  • STAGE 및 PROD 대상에 대해 ``snow dcm plan``을 병렬로 실행합니다.

  • ``plan_result.json``을 구문 분석하여 오브젝트 도메인별로 그룹화된 CREATE, ALTER, DROP 작업을 요약합니다.

  • 나중에 검사할 수 있도록 계획 아티팩트를 업로드합니다.

  • 두 환경 모두에 대한 계획 요약과 함께 끌어오기 요청에 통합된 설명을 게시합니다.

  • PLAN 중 하나라도 실패하는 경우 병합이 차단됩니다.

샘플 워크플로: 스테이지 및 프로덕션에 변경 사항 배포

이 워크플로는 순차적 승격 파이프라인을 구현합니다. 변경 사항은 먼저 스테이징에 배포되고 엔드투엔드 유효성을 검사한 후에만 프로덕션으로 승격됩니다. 스테이지가 실패하면 파이프라인이 중지되고 프로덕션에 영향을 주지 않습니다.

스테이지 배포 시퀀스:

  1. 계획: ``snow dcm plan``을 실행하고 변경 세트를 요약합니다.

  2. 데이터 삭제 감지: 계획 출력을 구문 분석하고 데이터베이스, 스키마, 테이블 또는 스테이지에 대한 DROP 작업이 포함된 경우 파이프라인을 차단합니다.

  3. 배포: ``snow dcm deploy``를 실행합니다.

  4. 게시 스크립트: ``snow sql``을 사용하여 Jinja 변수 삽입을 통해 선택적으로 SQL 후처리 스크립트를 실행합니다.

  5. 동적 테이블 새로 고침: ``snow dcm refresh``를 실행하여 새 변환 논리를 적용합니다.

  6. 테스트 기대치: ``snow dcm test``를 실행하여 데이터 품질 기대치를 검증합니다.

프로덕션 배포 시퀀스:

프로덕션 대상에 대해 동일한 6단계가 반복되지만, 모든 스테이징 작업이 통과된 후에만 수행됩니다.

모든 작업이 완료되면 워크플로는 원래 끌어오기 요청에 최종 상태 요약을 게시합니다.

참고

배포 워크플로는 ``snow cortex complete``을 사용하여 GitHub Actions 작업 요약에서 후처리 스크립트 결과 및 동적 테이블 새로 고침 출력에 대한 사람이 읽을 수 있는 요약을 생성합니다.

샘플 워크플로: 스테이지에서 기대치 테스트

이 워크플로는 전체 배포를 트리거하지 않고 스테이징 환경에서 데이터 품질을 검증하는 온디맨드 방식을 제공합니다. 수동 데이터 변경 또는 업스트림 데이터 새로 고침 후 기대치를 확인하거나 주기적인 품질 검사로 사용합니다. 워크플로는 다음 단계를 수행합니다.

  • 스테이징 DCM project 에서 관리하는 모든 동적 테이블을 새로 고칩니다.

  • 프로젝트의 테이블, 동적 테이블 및 뷰에 연결된 모든 데이터 품질 기대 테스트를 실행합니다.

  • 위반된 기대치에 대한 세부 정보와 함께 성공 또는 실패 상태를 보고합니다.

자주 묻는 질문(FAQ)

기존 오브젝트의 이름을 바꾸려면 어떻게 해야 하나요?
  1. DCM 프로젝트 외부에서 ALTER 명령을 실행합니다.

  2. 정의를 변경합니다.

  3. PLAN을 실행하여 새 정의가 새 상태와 일치하는지 확인합니다(PLAN에서 변경 사항 없음).

  4. DEPLOY를 실행하여 새 상태를 저장합니다.

DEFINE 문에서 아직 지원하지 않는 오브젝트를 배포하려면 어떻게 해야 하나요?

DCM 프로젝트 계획 또는 배포를 실행한 후 별도의 SQL 스크립트에서 CREATE IF NOT EXISTS 또는 CREATE OR REPLACE 문을 실행할 수 있습니다.

두 옵션 모두 Jinja2 템플릿 및 테스트를 지원합니다(테스트는 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
;