Version control for custom flows

Version control for custom flows (사용자 정의 플로우용 버전 관리)

Openflow는 GitHub Registry Client를 포함한 Registry Client를 지원하며, Git 저장소를 사용해 사용자 정의 플로우 정의를 저장하고 버전 관리할 수 있어요. 이렇게 하면 분기, 풀 리퀘스트, 코드 검토, 환경 승격 같은 표준 소프트웨어 개발 수명 주기(SDLC) 관행을 사용할 수 있어요.

출처: Snowflake Documentation

본문

기능 — 일반 공개(Generally Available)

Openflow Snowflake Deployments는 AWS, Azure, GCP의 상업용 리전에 있는 모든 계정에서 사용할 수 있어요.

Openflow BYOC 배포는 AWS의 상업용 리전에 있는 모든 계정에서 사용할 수 있어요.

일반적인 워크플로는 다음과 같아요.

  • 프로덕션 플로우 정의를 나타내는 main 브랜치를 유지.
  • 새 개발을 위한 기능 브랜치 생성.
  • Openflow 캔버스에서 변경 사항을 개발·커밋.
  • 풀 리퀘스트를 열고 Flow Diff로 검토한 뒤 병합.

전제 조건

  • 플로우 정의를 저장할 GitHub 저장소.
  • repository 접근 권한이 있는 GitHub Personal Access Token.
  • Openflow 캔버스에 접근할 수 있는 Openflow 런타임.
  • 런타임 객체에 대한 적절한 execute-as 역할 권한.

Step 1: GitHub Registry Client 생성

  1. GitHub에 플로우 정의를 저장할 저장소를 만들어요.
  2. GitHub에서 저장소 접근 권한이 있는 Personal Access Token(PAT)을 생성해요.
  3. Openflow 캔버스에서 Controller Settings로 이동해 새 Registry Client를 만들어요.
  4. 유형으로 GitHub Registry Client를 선택해요.
  5. Registry Client를 다음으로 구성해요.
    • GitHub 저장소 URL.
    • GitHub 저장소 소유자.
    • 인증용 Personal Access Token.

Step 2: 새 플로우 생성 및 버전 관리

  1. Openflow 캔버스에서 플로우용 새 Process Group을 만들어요.
  2. 플로우를 구축해요: 프로세서 추가, 연결 구성, 데이터 파이프라인 설정.
  3. Process Group을 오른쪽 클릭하고 Start Version Control을 선택해요.
  4. Step 1에서 구성한 GitHub Registry Client를 선택해요.
  5. 플로우 이름과 초기 커밋 메시지를 제공해요.

저장 후 플로우 정의가 GitHub 저장소에 커밋돼요. GitHub에서 저장소를 확인해 검증할 수 있어요.

Step 3: 브랜치로 변경 관리

개발 브랜치 생성

GitHub 저장소에서 새 브랜치(예: dev 또는 feature/add-new-table 같은 기능 브랜치)를 만들어요.

브랜치에서 가져와 개발

  1. Openflow 캔버스에서 도구 모음의 Import from Registry 아이콘을 캔버스로 끌어다 놓아 GitHub Registry의 플로우를 새 Process Group으로 가져와요.
  2. 가져올 때 작업할 대상 브랜치(예: dev)를 선택해요.
  3. Process Group 안에서 플로우를 변경해요.
  4. Openflow에서 변경 사항을 커밋해요. 이렇게 하면 업데이트된 플로우 정의가 GitHub의 선택된 브랜치로 푸시돼요.

풀 리퀘스트로 검토 및 병합

  1. GitHub에서 개발 브랜치를 main으로 하는 풀 리퀘스트를 열어요.
  2. 변경 사항을 검토해요. 사람이 읽을 수 있는 diff에는 Snowflake Flow Diff GitHub Action을 사용해요(Step 4 참고).
  3. 승인 후 풀 리퀘스트를 병합해요.
  4. Openflow 캔버스로 돌아가 main Process Group을 업데이트해 main 브랜치에서 최신 버전을 가져와요.

Step 4: Snowflake Flow Diff 설정 (GitHub Action)

Snowflake Flow Diff는 파이프라인 변경 사항의 시각적 diff를 풀 리퀘스트 대화에 직접 렌더링해 플로우 변경을 사람이 읽을 수 있게 만드는 GitHub Action이에요.

워크플로 파일 설정

  1. GitHub 저장소에 .github/workflows/flowdiff.yml 파일을 만들어요.
  2. Snowflake Flow Diff 저장소에서 워크플로 구성을 복사해요(README의 Usage 섹션 참고).
  3. 워크플로 파일을 커밋하고 푸시해요.

플로우 변경 검토

  1. 풀 리퀘스트가 열리면 Flow Diff 액션이 자동으로 실행돼요.
  2. 풀 리퀘스트의 Conversations 탭으로 이동해 Flow Diff 분석이 나타날 때까지 기다려요.
  3. 분석은 원시 JSON diff 대신 플로우 변경의 시각적이고 사람이 읽을 수 있는 비교를 보여 줘요.

환경 간 파라미터 관리

Openflow는 Parameter(파라미터)를 사용해 다양한 런타임 간에 환경별 값(예: 연결 문자열, 자격 증명, 테이블 이름)을 관리해요.

다음 개념을 명심해요.

  • 파라미터는 Parameter Context로 그룹화되며, Parameter Context는 Process Group과 일대일 매핑돼요.
  • Parameter Context 상속을 통해 상위 컨텍스트에서 공유 파라미터를 정의하고 하위 컨텍스트에서 특정 값을 오버라이드할 수 있어요. 이는 dev, staging, production 환경 간 플로우 승격에 유용해요.
  • Parameter Context는 Secrets Manager와 통합해 플로우 정의에 저장하지 않고 민감한 자격 증명을 안전하게 처리할 수 있어요.

권장 SDLC 워크플로

  1. 개발 환경: 개발자가 기능 브랜치를 만들고, 플로우를 구축·수정하며, 기능 브랜치에 대해 Openflow 캔버스에 변경 사항을 커밋.
  2. 코드 검토: GitHub에서 풀 리퀘스트를 염. 읽기 쉬운 검토를 위해 Snowflake Flow Diff를 사용.
  3. main에 병합: 승인 후 풀 리퀘스트를 main 브랜치로 병합.
  4. 프로덕션 승격: 프로덕션 런타임에서 Process Group을 업데이트해 main에서 최신 버전을 가져옴.
  5. 파라미터화: Parameter Context를 사용해 플로우 정의 자체를 수정하지 않고 환경별 구성을 처리.

더 알아보기 (Learn more)