DCM Projects 배포 및 관리¶
이 항목에서는 계정을 포함하여 Snowflake 환경을 관리하기 위해 DCM Projects 를 생성하고 배포하는 방법에 대해 설명합니다.
DCM project 관리에는 다음 단계가 포함됩니다.
DCM project 용 Snowflake 계정을 :ref:`준비 <label-dcm_projects_prepare>`합니다.
프로젝트 구성 및 프로젝트 파일의 오브젝트를 :ref:`정의 <label-dcm_projects_define>`합니다.
DCM Projects 오브젝트를 :ref:`생성 <label-dcm_projects_create_object>`합니다.
배포 전에 제안된 변경 사항을 미리 볼 수 있도록 :ref:`계획 <label-dcm_projects_plan>`합니다.
프로젝트를 :ref:`배포 <label-dcm_projects_deploy>`합니다.
필요에 따라 프로세스를 모니터링, 업데이트 및 반복하여 프로젝트를 :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입니다. |
|
Snowflake CLI**를 사용한 **로컬 IDE 소프트웨어 엔지니어에게 가장 친숙하고 개인화된 인터페이스입니다. |
|
Cortex Code Snowflake용 에이전트 AI 도구입니다. 자세한 내용은 DCM Projects 의 Cortex Code 섹션을 참조하십시오. |
|
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 스킬을 시작하려면 다음 단계를 따릅니다.
:doc:`Cortex Code 설치하기 </user-guide/cortex-code/cortex-code-cli>`에 설명된 대로 Cortex Code CLI를 설치합니다.
터미널에서 Cortex Code를 시작합니다.
$dcm스킬 참조를 사용하거나 자연어 프롬프트에서DCM용어를 사용하여 DCM Projects 와 대화형으로 상호 작용합니다.
예:
“분석 파이프라인을 위한 새 DCM 프로젝트를 생성해줘”
“PROD 대상에 대한 프로젝트 계획을 세워줘”
“마지막 계획이 실패한 이유가 뭐야?”
“고객 지출에 대한 새로운 동적 테이블 정의를 추가해줘”
Snowflake CLI (DCM Projects).¶
Snowflake CLI 는 Snowflake용 명령줄 인터페이스입니다. 로컬 IDE에서 Snowflake 계정과 상호 작용하는 데 사용할 수 있는 도구입니다.
DCM 프로젝트에는 Snowflake CLI 버전 3.16 이상이 필요합니다. Snowflake CLI 설치하기 에 설명된 대로 Snowflake CLI 를 설치하거나 업그레이드합니다.
:doc:`Snowflake CLI 구성 및 Snowflake에 연결하기 </developer-guide/snowflake-cli/connecting/connect>`에 설명된 대로 Snowflake 계정에 대한 연결을 구성합니다. 연결이 작동하는지 확인합니다.
Git 리포지토리 복제본의 로컬 디렉터리로 이동합니다. 예:
사용할 수 있는 Snowflake CLI DCM 명령을 확인합니다.
Git 통합¶
DCM project 정의 파일이 저장된 Git 리포지토리에 연결합니다.
:ref:`Git 리포지토리에서 새 작업 공간을 생성 <label-create_a_git_workspace>`합니다.
계획된 변경 사항에 대한 Git 분기를 생성하거나 선택합니다.
Snowflake는 해당 분기의 파일을 작업 공간 편집기로 복제합니다.
DCM project 정의 파일이 있거나 해당 파일을 생성하려는 폴더로 이동합니다.
`Snowflake CLI <https://docs.snowflake.com/en/developer-guide/snowflake-cli/installation/installation>`_를 설치합니다.
여기에서는 VSCode용 `Snowflake 확장 프로그램 <https://docs.snowflake.com/en/user-guide/vscode-ext>`_이 필요하지 않지만, 도움이 될 수 있습니다.
`Snowflake에 연결 <https://docs.snowflake.com/en/developer-guide/snowflake-cli/connecting/connect>`_합니다.
Git 리포지토리에 연결합니다.
로컬 IDE를 원격 Git 리포지토리에 연결합니다.
계획된 변경 사항에 대한 분기를 생성하거나 선택합니다.
해당 분기를 로컬 디스크에 복제합니다.
DCM Projects 정의 파일이 있거나 해당 파일을 생성하려는 폴더로 이동합니다.
다음 경우에 |dcm-object|를 만듭니다.¶
필수 역할 및 권한¶
DCM project 오브젝트를 생성하는 사용자의 역할에는 다음과 같은 역할과 권한이 있어야 합니다.
CREATE DCM PROJECT ON SCHEMA 권한:
다음 경우에 |dcm-object|를 만듭니다.¶
다음 옵션 중 하나를 사용하여 DCM project 오브젝트를 생성합니다.
기본 대상이 아닌 대상에 대한 프로젝트를 생성하려면 다음 명령 중 하나를 사용합니다.
탐색 메뉴에서 Projects » Workspaces 를 선택합니다.
Workspaces 페이지에서 “+새 항목 추가” -> “DCM 프로젝트”를 선택하여 새 DCM project 폴더를 생성합니다.
“기본 대상 환경 정의”를 선택하여 매니페스트의 기본 대상에 대한 새 DCM project 오브젝트를 선택하거나 생성합니다.
매니페스트에 정의되어 있지만 아직 존재하지 않는 DCM project 오브젝트가 있는 대상에 DCM PLAN을 실행하는 경우, 계획을 실행하기 전에 정의된 이름과 소유자 역할을 기반으로 해당 DCM project 오브젝트 생성을 확인하는 UI가 표시됩니다.
:ui:`Target`은 지정된 DCM project 오브젝트가 이미 존재하며 사용할 수 있는지 여부를 나타냅니다.
녹색: DCM project 오브젝트가 존재하며 PLAN 또는 DEPLOY를 실행하는 데 사용할 수 있습니다.
빨간색: DCM project 오브젝트가 존재하지 않으며 먼저 생성해야 합니다.
액세스 제어 및 역할 권한¶
READ, MONITOR 또는 OWNERSHIP 권한에 스키마 수준 DCM project 오브젝트의 역할 기반 액세스 제어(RBAC)를 설정할 수 있습니다.
이러한 권한은 작업 공간, 스테이지 또는 리포지토리에 저장된 정의 파일에 대한 액세스 제어와 무관합니다.
권한 |
설명 |
허용되는 작업 |
|---|---|---|
READ |
|
|
MONITOR |
|
|
OWNERSHIP |
|
|
참고
다른 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를 미리 보고, 배포 후 변경 사항을 미리 봅니다.
이 계획은 다음 단계를 수행합니다.
선택한 구성 프로필 또는 런타임 시 제공된 값으로 모든 Jinja 템플릿을 렌더링합니다.
모든 정의를 마지막 배포의 일부로 정의된 엔터티의 현재 상태와 비교합니다.
정의된 모든 문을 CREATE, ALTER, DROP, GRANT 및 REVOKE 문으로 변환합니다.
해당 상호 종속성을 기반으로 모든 문을 정렬합니다.
모든 문을 컴파일합니다.
참고
PLAN은 배포 중에 발생할 수 있는 거의 모든 오류를 포착하지만 성공적인 배포를 보장하지는 않습니다.
PLAN 명령 실행¶
PLAN 명령은 다음 정보를 입력으로 사용합니다.
매니페스트 파일의 경로
CLI는 매니페스트(
default_target또는--target플래그)에서 대상을 읽습니다. SQL 명령의 경우 매니페스트 파일의 경로와 프로젝트 이름을 제공해야 합니다.Jinja 변수에 대해 정의된 값(선택 사항).
대상의 ``templating_config``는 구성 프로필을 자동으로 선택합니다. SQL 명령의 경우, USING CONFIGURATION 절을 사용하여 프로필을 지정합니다.
덮어쓸 구성 프로필의 하나 이상의 값(선택 사항).
다음은 PLAN 명령을 실행하는 방법의 예제입니다.
로컬 IDE 터미널에서 또는 Git 워크플로의 일부로 snow dcm plan 명령을 실행합니다.
로컬 디렉터리에서 DCM 프로젝트를 계획하는 CLI 명령의 예제는 다음과 같습니다.
Snowflake 스테이지 또는 Git 리포지토리 복제본에서 DCM 프로젝트를 계획하는 CLI 명령의 예제는 다음과 같습니다.
선택적 인자로 DCM 프로젝트를 계획하는 CLI 명령의 예제는 다음과 같습니다.
변수는 큰따옴표로 묶어야 하며, 문자열 값에는 작은따옴표가 추가되어야 합니다. 값 목록에는 대괄호가 필요합니다.
DCM 제어판의 상단에서 다음을 수행합니다.
현재 작업 공간에서 프로젝트 폴더를 선택합니다.
대상을 선택합니다(대상이 여러 개인 경우).
(선택 사항) 특정 매개 변수를 덮어씁니다.
Plan 를 클릭합니다.
Snowsight UI는 매니페스트 대상에 정의된 DCM project 오브젝트를 자동으로 사용합니다. 프로젝트 오브젝트가 아직 존재하지 않는 경우 UI에서 생성할 수 있습니다.
PLAN이 완료되면 출력이 새 탭에서 열립니다. 표시되지 않으면 :ui:`Plan`을 다시 클릭하여 탭을 엽니다.
계획이 이미 존재하면 정의를 변경한 경우 다시 계획하도록 선택할 수 있습니다.
계획 출력은 항상 프로젝트 하위 폴더 out/ 아래에 자동으로 생성됩니다.
SQL을 실행할 수 있는 Snowflake 내부 또는 Snowflake에 연결된 모든 위치에서 SQL로 DCM PLAN을 실행할 수 있습니다. PLAN 모드에서 EXECUTE DCM PROJECT 명령을 사용합니다.
작업 공간 경로에서 DCM 프로젝트를 계획하는 SQL 명령의 예제는 다음과 같습니다.
구성 프로필이 있지만 wh_size 및 ``teams``를 덮어쓰는 Jinja를 사용할 때 DCM 프로젝트를 계획하는 SQL 명령의 예제는 다음과 같습니다.
구성 프로필 없이 Jinja 템플릿을 사용할 때 DCM project 를 계획하는 SQL 명령의 예제는 다음과 같습니다.
정의 파일 경로¶
매니페스트 및 정의 파일의 위치를 참조하는 옵션은 다음과 같습니다.
작업 공간 경로에서
Snowsight 사용자 인터페이스에는 현재 작업 공간 내의 모든 DCM project 정의가 자동으로 나열됩니다. 이러한 경로 중 하나를 선택할 수 있으며, 작업 공간은 이를 사용하여 DCM 명령을 실행합니다.
작업 공간에서 SQL 명령을 수동으로 실행하려는 경우, 작업 공간 내에서 동일한 경로를 참조할 수도 있습니다.
팁: 작업 공간의 모든 파일 뒤에 있는 점 3개 메뉴를 사용하면 해당 파일의 전체 경로를 SQL 코드에 복사할 수 있습니다.
작업 공간 경로에서 DCM 프로젝트를 계획하는 SQL 명령의 예제는 다음과 같습니다.
디스크의 로컬 Git 리포지토리 복제본에서
로컬 IDE에서 CLI 명령을 실행하기 전에
manifest.yml파일이 포함된 디렉터리를 선택합니다. 또는 사용하려는 매니페스트와 정의가 포함된 다른 로컬 디렉터리를 지정할 수 있습니다.로컬 Git 리포지토리의 현재 디렉터리에서 DCM project 를 계획하는 CLI 명령의 예제는 다음과 같습니다.
로컬 Git 리포지토리 복제본의 다른 디렉터리에서 DCM project 를 계획하는 CLI 명령의 예제는 다음과 같습니다.
워크플로의 원격 리포지토리에서
DCM 명령이 CI/CD 워크플로에서 실행되는 경우 동일한 CLI 구문을 사용할 수 있습니다.
로컬 Git 리포지토리 복제본에서 DCM project 를 계획하는 CI/CD 워크플로의 예제는 다음과 같습니다.
Snowflake의 스테이지 또는 Git 리포지토리 복제본에서
DCM 명령을 실행하는 Snowflake 내에서 프로시저 또는 작업을 실행하려는 경우, 이 SQL 명령은 계정 내의 Snowflake 스테이지 또는 Git 리포지토리 복제본에 대한 절대 경로를 참조할 수 있습니다.
Git 리포지토리 복제본의 경우 최신 버전을 사용하려면 먼저 ALTER GIT REPOSITORY FETCH를 실행하는 것이 좋습니다.
'@...'경로는 DCM SQL 명령을 실행할 때만 사용할 수 있습니다.Snowflake의 스테이지 또는 Git 리포지토리 복제본에서 DCM 프로젝트를 계획하는 SQL 명령의 예제는 다음과 같습니다.
계획 출력¶
참고
미리 보기 단계에서는 정확한 출력 유형이 변경될 수 있습니다.
표준 계획 출력에는 JSON 형식의 계획 실행에 대한 다음 정보가 포함됩니다.
속성 |
설명 |
|---|---|
|
출력 형식의 스키마 버전입니다. 버전 2는 최신 버전이며 유일하게 지원되는 버전입니다. |
|
실행에 대한 컨텍스트 정보입니다. |
|
명령이 실행된 시점의 ISO 8601 타임스탬프입니다. |
|
이 계획을 생성한 쿼리의 고유 식별자입니다. |
|
DCM 프로젝트 오브젝트의 정규화된 이름입니다. |
|
명령을 실행한 사용자의 이름입니다. |
|
명령을 실행하는 데 사용되는 활성 역할입니다. |
|
실행된 명령입니다. |
|
변경 항목의 배열입니다. 각 항목은 생성, 변경 또는 삭제된 하나의 오브젝트를 나타냅니다. 빈 배열은 프로젝트 정의가 이미 계정과 동기화되어 있음을 나타냅니다. |
|
오브젝트에 대해 계획된 작업입니다. 가능한 값은 |
|
대상 오브젝트를 식별합니다. |
|
Snowflake 오브젝트 유형입니다. |
|
오브젝트의 이름입니다. |
|
오브젝트의 정규화된 이름입니다. |
|
오브젝트가 포함된 데이터베이스입니다. 계정 수준 오브젝트의 경우 생략됩니다. |
|
오브젝트가 포함된 스키마입니다. 데이터베이스 수준 및 계정 수준 오브젝트의 경우 생략됩니다. |
|
특정 특성 수정 사항을 자세히 설명하는 변경 설명자의 배열입니다. |
|
변경 유형입니다. 가능한 값: |
|
설정되거나 변경되는 특성의 이름입니다. |
|
특성의 새 값입니다. |
|
|
|
수정 중인 컬렉션의 이름(예: |
|
컬렉션 내의 항목을 식별하는 데 사용되는 레이블(예: |
|
컬렉션 항목 설명자의 중첩된 배열입니다. ``kind``가 ``collection``인 경우에만 표시됩니다. |
|
컬렉션 항목에 대한 변경 유형입니다. 가능한 값은 |
|
컬렉션 내의 항목을 식별합니다. 컬렉션 유형에 따라 문자열 또는 오브젝트일 수 있습니다. |
|
이 항목에 대한 추가 변경 설명자의 배열입니다. |
계획 출력의 예제:
DCM project 배포¶
DCM project 를 배포할 때 다음 작업이 수행됩니다.
정의되었지만 아직 존재하지 않는 오브젝트가 생성됩니다.
이미 존재하지만 현재 정의와 다른 오브젝트가 변경됩니다.
정의된 대로 이미 존재하는 오브젝트는 건너뜁니다.
이미 존재하지만 더 이상 정의되지 않은 오브젝트가 삭제됩니다.
프로젝트에 정의된 권한 부여 및 첨부된 데이터 품질 기대치에도 동일한 동작이 적용됩니다.
중요
의도하지 않은 데이터 손실을 방지하려면 항상 DEPLOY를 실행하기 전에 실행하고 **PLAN 출력을 검토**합니다.
DCM project 는 한 번에 하나의 인스턴스만 배포할 수 있습니다. 여러 구성 프로필을 함께 사용할 수 없습니다. 동일한 DCM project 로 구성 B를 배포하면 B에 정의되지 않은 다른 이전 구성의 모든 오브젝트가 삭제됩니다.
각 대상 환경에 대한 하나의 DCM project 를 생성합니다. 그러면 각 환경에 대한 DCM project 가 동일한 정의 파일을 가리키지만 ``suffix => ‘DEV_JS’``와 같은 각 변수에 대해 다른 값을 사용하여 독립적으로 배포할 수 있으므로, 동일한 Snowflake 계정에서 독립적으로 나란히 존재할 수 있습니다.
미리 정의된 프로필을 약간 변형하여 사용하려는 경우 런타임 시 선택한 변수의 값을 덮어쓸 수 있습니다.
예:
각 배포 시도(성공, 실패 또는 취소됨)에는 배포 번호가 있습니다(예: 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 명령을 실행하는 방법의 예제입니다.
구성 프로필이 있지만 wh_size 및 ``teams``를 덮어쓰는 Jinja를 사용할 때 DCM project 를 계획하는 SQL 명령의 예제는 다음과 같습니다.
로컬 IDE 터미널에서 또는 Git 워크플로의 일부로 :code:`snow dcm deploy`를 실행할 수 있습니다.
로컬 디렉터리에서 DCM project 를 배포하는 CLI 명령의 예제는 다음과 같습니다.
기본 환경이 아닌 환경을 대상으로 DCM project 를 배포하는 CLI 명령의 예제는 다음과 같습니다.
선택적 인자로 DCM project 를 배포하는 CLI 명령의 예제는 다음과 같습니다.
탐색 메뉴에서 Projects » Workspaces 를 선택합니다.
현재 작업 공간에서 프로젝트 폴더를 선택합니다.
대상을 선택합니다(대상이 여러 개인 경우).
Plan 를 클릭합니다.
UI는 매니페스트 대상에 정의된 DCM project 오브젝트를 자동으로 사용합니다. 프로젝트 오브젝트가 아직 존재하지 않는 경우 UI에서 생성할 수 있습니다.
PLAN이 완료되면 출력이 새 탭에서 열립니다. 표시되지 않으면 :ui:`Plan`을 다시 클릭하여 탭을 엽니다.
계획이 이미 존재하면 정의를 변경한 경우 다시 계획하도록 선택할 수 있습니다.
PLAN 출력을 검토하여 의도하지 않은 변경 사항이 포함되어 있는지 확인합니다.
:ui:`Deploy`를 클릭하여 PLAN의 동일한 대상 및 값으로 배포를 실행합니다.
표준 계획 출력 구조의 경우 계획 출력 섹션을 참조하세요.
DCM project 관리¶
DCM project 에서 관리하는 모든 오브젝트 표시¶
SHOW ENTITIES IN DCM PROJECT 명령을 사용하면 현재 특정 DCM project 에서 관리하는 모든 Snowflake 오브젝트의 목록을 볼 수 있습니다. 모든 오브젝트의 정규화된 이름 목록을 제공합니다. 결과를 확인하려면 사용자에게 DCM project 에 대한 READ 권한 및 관리 오브젝트 자체를 확인할 수 있는 권한이 모두 필요합니다.
참고
결과가 가장 최근 배포의 오브젝트와 반드시 일치하는 것은 아닙니다. 프로젝트에서 수동으로 삭제하거나 분리한 오브젝트는 결과에 나열되지 않습니다.
:code:`LIKE`를 사용하여 이름으로 검색하거나 흐름 연산자를 사용하여 결과 세트를 추가로 처리 또는 필터링할 수 있습니다.
마찬가지로, 이 프로젝트와 함께 정의되고 배포되는 SHOW GRANTS 및 SHOW FUTURE GRANTS 권한도 사용할 수 있습니다.
현재 DCM project 에서 관리하는 모든 오브젝트를 확인하는 예제는 다음과 같습니다.
탐색 메뉴에서 Catalog » Database Explorer 를 선택합니다.
DCM project 오브젝트가 포함된 스키마로 이동합니다.
DCM project 오브젝트를 선택하여 세부 정보를 확인합니다.
Objects 탭을 클릭하여 현재 이 프로젝트 오브젝트에서 관리하는 모든 Snowflake 오브젝트 목록을 확인합니다.
오브젝트의 이름을 클릭하여 새 탭에서 해당 오브젝트의 세부 정보 페이지를 엽니다.
DCM project 에서 오브젝트 분리¶
ALTER <오브젝트> 명령과 UNSET DCM PROJECT 절을 사용하면 배포된 후 현재 DCM project 에서 관리되는 오브젝트를 분리할 수 있습니다. 이 명령은 오브젝트를 삭제하지 않고 오브젝트와 DCM project 간의 연결을 제거합니다. 다른 DCM project 로 오브젝트 관리를 시작하려는 경우 이 명령을 사용할 수 있습니다.
다시 배포하기 전에 :ref:`프로젝트 정의 파일 <label-dcm_projects_definition_files>`에서 해당 DEFINE 문을 제거해야 합니다. 그렇지 않으면 오브젝트가 DCM project 에 다시 통합됩니다.
DCM project 에서 오브젝트를 분리하는 SQL 명령의 예제는 다음과 같습니다.
배포된 권한 부여 또는 실행은 DCM 프로젝트에서 분리할 수 없습니다.
DCM project 삭제¶
DCM project 오브젝트가 삭제되더라도 관리되는 모든 엔터티, 권한 부여 및 기대치는 “관리되지 않는” 상태로 유지됩니다.
중요
DCM project 오브젝트를 삭제하거나 바꾸면 오브젝트에 포함된 모든 배포 기록 아티팩트가 손실됩니다.
탐색 메뉴에서 Catalog » Database Explorer 를 선택합니다.
DCM project 가 포함된 스키마로 이동합니다.
DCM project 를 선택하여 해당 세부 정보 페이지를 확인합니다.
오른쪽 상단의 점 3개 메뉴를 클릭하고 :ui:`Drop`을 선택합니다.
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_identifier 및 project_owner 역할을 직접 읽으므로 환경별 구성은 중복된 GitHub 시크릿이 아닌 버전 제어되는 ``manifest.yml``에 저장됩니다. 서비스 사용자 자격 증명만 시크릿으로 저장됩니다.
샘플 워크플로: 연결 및 권한 유효성 검사¶
워크플로 구성 파일: DCM _0_Test_Connections.yml
트리거:
workflow_dispatch이벤트로 수동 실행
이 워크플로는 GitHub Actions 서비스 사용자가 매니페스트에 정의된 모든 대상 환경에 연결할 수 있는지 확인합니다. 새 리포지토리를 설정하거나, 새 계정을 온보딩하거나, 인증 문제를 디버깅할 때 사용합니다. 워크플로는 다음 단계를 수행합니다.
``manifest.yml``의 모든 대상 이름을 동적으로 구문 분석합니다.
GitHub Actions 매트릭스 전략을 사용하여 각 대상을 병렬로 테스트합니다.
각 대상에 대해, Snowflake 연결을 확인하고, 연결된 계정, 사용자, 역할을 보고하고, 연결된 역할이 DCM project 소유자와 일치하는지 확인합니다.
DCM project 오브젝트가 이미 존재하고 서비스 사용자에게 배포 권한이 있는지 여부를 보고합니다.
샘플 워크플로: 끌어오기 요청 시 변경 사항 미리 보기¶
워크플로 구성 파일: DCM_1_Test_PR_to_main.yml
트리거:
main분기에 대한 끌어오기 요청이 열렸거나, 동기화되거나, 다시 열렸습니다.
이 워크플로는 모든 끌어오기 요청에 대한 통합 테스트로 스테이징 및 프로덕션 대상 모두에 대해 PLAN을 실행합니다. 끌어오기 요청 시 계획된 변경 사항에 대한 요약을 검토자에게 직접 제공합니다. 워크플로는 다음 단계를 수행합니다.
샘플 워크플로: 스테이지 및 프로덕션에 변경 사항 배포¶
워크플로 구성 파일: DCM_2_Deploy_to_Stage_and_Prod.yml
트리거:
main분기로 푸시(일반적으로 병합된 끌어오기 요청)
이 워크플로는 순차적 승격 파이프라인을 구현합니다. 변경 사항은 먼저 스테이징에 배포되고 엔드투엔드 유효성을 검사한 후에만 프로덕션으로 승격됩니다. 스테이지가 실패하면 파이프라인이 중지되고 프로덕션에 영향을 주지 않습니다.
스테이지 배포 시퀀스:
계획: ``snow dcm plan``을 실행하고 변경 세트를 요약합니다.
데이터 삭제 감지: 계획 출력을 구문 분석하고 데이터베이스, 스키마, 테이블 또는 스테이지에 대한 DROP 작업이 포함된 경우 파이프라인을 차단합니다.
배포: ``snow dcm deploy``를 실행합니다.
게시 스크립트: ``snow sql``을 사용하여 Jinja 변수 삽입을 통해 선택적으로 SQL 후처리 스크립트를 실행합니다.
동적 테이블 새로 고침: ``snow dcm refresh``를 실행하여 새 변환 논리를 적용합니다.
테스트 기대치: ``snow dcm test``를 실행하여 데이터 품질 기대치를 검증합니다.
프로덕션 배포 시퀀스:
프로덕션 대상에 대해 동일한 6단계가 반복되지만, 모든 스테이징 작업이 통과된 후에만 수행됩니다.
모든 작업이 완료되면 워크플로는 원래 끌어오기 요청에 최종 상태 요약을 게시합니다.
참고
배포 워크플로는 ``snow cortex complete``을 사용하여 GitHub Actions 작업 요약에서 후처리 스크립트 결과 및 동적 테이블 새로 고침 출력에 대한 사람이 읽을 수 있는 요약을 생성합니다.
샘플 워크플로: 스테이지에서 기대치 테스트¶
워크플로 구성 파일: DCM_3_Test_STAGE_Expectations.yml
트리거:
workflow_dispatch이벤트로 수동 실행
이 워크플로는 전체 배포를 트리거하지 않고 스테이징 환경에서 데이터 품질을 검증하는 온디맨드 방식을 제공합니다. 수동 데이터 변경 또는 업스트림 데이터 새로 고침 후 기대치를 확인하거나 주기적인 품질 검사로 사용합니다. 워크플로는 다음 단계를 수행합니다.
스테이징 DCM project 에서 관리하는 모든 동적 테이블을 새로 고칩니다.
프로젝트의 테이블, 동적 테이블 및 뷰에 연결된 모든 데이터 품질 기대 테스트를 실행합니다.
위반된 기대치에 대한 세부 정보와 함께 성공 또는 실패 상태를 보고합니다.
자주 묻는 질문(FAQ)¶
- 기존 오브젝트의 이름을 바꾸려면 어떻게 해야 하나요?
DCM 프로젝트 외부에서 ALTER 명령을 실행합니다.
정의를 변경합니다.
PLAN을 실행하여 새 정의가 새 상태와 일치하는지 확인합니다(PLAN에서 변경 사항 없음).
DEPLOY를 실행하여 새 상태를 저장합니다.
- DEFINE 문에서 아직 지원하지 않는 오브젝트를 배포하려면 어떻게 해야 하나요?
DCM 프로젝트 계획 또는 배포를 실행한 후 별도의 SQL 스크립트에서 CREATE IF NOT EXISTS 또는 CREATE OR REPLACE 문을 실행할 수 있습니다.
두 옵션 모두 Jinja2 템플릿 및 테스트를 지원합니다(테스트는 Jinja 템플릿을 렌더링하지만 SQL 컴파일의 성공 여부는 확인하지 않음).
예: