다음을 통해 공유

최상의 패브릭 CI/CD 워크플로 옵션 선택

  • 아티클

이 문서의 목표는 일반적인 고객 시나리오에 따라 Fabric에서 CI/CD 프로세스를 빌드하기 위한 다양한 옵션을 패브릭 개발자에게 제공하는 것입니다. 이 문서에서는 CI/CD 프로세스의 CD(연속 배포 )에 대해 자세히 알아봅니다. CI(연속 통합) 부분에 대한 자세한 내용은 Git 분기 관리를 참조하세요.

이 문서에서는 몇 가지 고유한 옵션을 간략하게 설명하지만 많은 조직에서 하이브리드 접근 방식을 사용합니다.

필수 조건

배포 파이프라인 기능에 액세스하려면 다음 조건을 충족해야 합니다.

개발 프로세스

개발 프로세스는 모든 배포 시나리오에서 동일하며 새 업데이트를 프로덕션으로 릴리스하는 방법과는 독립적입니다. 개발자가 소스 제어를 사용하는 경우 격리된 환경에서 작업해야 합니다. 패브릭에서 해당 환경은 로컬 컴퓨터(예: Power BI Desktop 또는 VS Code)의 IDE이거나 Fabric의 다른 작업 영역일 수 있습니다. Git 분기 관리에서 개발 프로세스에 대한 다양한 고려 사항에 대한 정보를 찾을 수 있습니다.

개발 프로세스의 작동 방식을 보여 주는 다이어그램

릴리스 프로세스

새 업데이트가 완료되고 PR(끌어오기 요청)이 팀의 공유 분기(예: Main, Dev 등)에 병합되면 릴리스 프로세스가 시작됩니다. 이 시점부터 Fabric에서 릴리스 프로세스를 빌드하는 다양한 옵션이 있습니다.

옵션 1 - Git 기반 배포

Git 기반 배포의 작동 방식을 보여 주는 다이어그램

이 옵션을 사용하면 모든 배포가 Git 리포지토리에서 시작됩니다. 릴리스 파이프라인의 각 단계에는 전용 기본 분기(다이어그램에서 이러한 단계는 개발, 테스트 및 Prod)가 있으며, 이 분기는 Fabric의 적절한 작업 영역을 공급합니다.

개발자 분기에 대한 PR이 승인되고 병합되면 다음을 수행합니다.

  1. 릴리스 파이프라인이 트리거되어 개발 작업 영역의 콘텐츠를 업데이트합니다. 이 프로세스에는 단위 테스트를 실행하는 빌드 파이프라인이 포함될 수도 있지만, 파일의 실제 업로드는 패브릭 Git API를 사용하여 리포지토리에서 작업 영역으로 직접 수행됩니다. 이 작업 영역에 대한 특정 구성을 설정하거나 데이터를 수집하는 배포 후 작업을 위해 다른 패브릭 API를 호출해야 할 수 있습니다.
  2. 그런 다음 PR이 테스트 분기에 만들어집니다. 대부분의 경우 PR은 콘텐츠를 선택하여 다음 단계로 이동할 수 있는 릴리스 분기를 사용하여 만들어집니다. PR에는 팀 또는 조직의 다른 프로세스와 동일한 검토 및 승인 프로세스가 포함되어야 합니다.
  3. 첫 번째 단계에서 설명한 것과 유사한 프로세스를 사용하여 테스트 작업 영역을 업데이트하기 위해 다른 빌드 및 릴리스 파이프라인이 트리거됩니다.
  4. PR은 2단계에서 설명한 것과 유사한 프로세스를 사용하여 Prod 분기에 만들어집니다.
  5. 첫 번째 단계에서 설명한 것과 유사한 프로세스를 사용하여 Prod 작업 영역을 업데이트하기 위해 다른 빌드 및 릴리스 파이프라인이 트리거됩니다.

옵션 #1 사용은 언제 고려해야 하나요?

  • Git 리포지토리를 단일 원본 및 모든 배포의 원본으로 사용하려는 경우
  • 팀이 여러 기본 분기를 포함하여 분기 전략으로 Gitflow 를 따르는 경우.
  • 배포 전에 파일을 변경하기 위해 빌드 환경이 필요하지 않으므로 리포지토리에서 업로드가 작업 영역으로 직접 이동합니다. API를 호출하거나 배포 후 작업 영역에서 항목을 실행하여 이를 변경할 수 있습니다.

옵션 2 - 빌드 환경을 사용하는 Git 기반 배포

빌드 환경을 사용하는 Git 기반 배포의 흐름을 보여 주는 다이어그램

이 옵션을 사용하면 모든 배포가 Git 리포지토리(기본)의 동일한 분기에서 시작됩니다. 릴리스 파이프라인의 각 단계에는 전용 빌드 및 릴리스 파이프라인이 있습니다. 이러한 파이프라인은 빌드 환경을 사용하여 작업 영역에 업로드되기 전에 항목의 일부 정의를 변경하는 단위 테스트 및 스크립트를 실행할 수 있습니다. 예를 들어 데이터 원본 연결, 작업 영역의 항목 간 연결 또는 매개 변수 값을 변경하여 올바른 단계에 대한 구성을 조정할 수 있습니다.

개발 분기에 대한 PR이 승인되고 병합되면 다음을 수행합니다.

  1. 빌드 파이프라인은 새 빌드 환경을 스핀업하고 개발 단계에 대한 단위 테스트를 실행하도록 트리거됩니다. 그런 다음 릴리스 파이프라인이 트리거되어 빌드 환경에 콘텐츠를 업로드하고, 스크립트를 실행하여 일부 구성을 변경하고, 구성을 개발 단계로 조정하고, Fabric의 업데이트 항목 정의 API를 사용하여 파일을 작업 영역에 업로드합니다.
  2. 릴리스 관리자의 데이터 수집 및 승인을 포함하여 이 프로세스가 완료되면 테스트 단계에 대한 다음 빌드 및 릴리스 파이프라인을 만들 수 있습니다. 이러한 단계는 첫 번째 단계에서 설명한 것과 유사한 프로세스로 만들어집니다. 테스트 단계의 경우 배포 후 다른 자동화 또는 수동 테스트가 필요할 수 있으며, 변경 내용을 Prod 스테이지로 릴리스할 준비가 되었음을 확인할 수 있습니다.
  3. 모든 자동화 및 수동 테스트가 완료되면 릴리스 관리자는 빌드 및 릴리스 파이프라인을 승인하고 Prod 스테이지로 시작할 수 있습니다. Prod 스테이지에는 일반적으로 테스트/개발 단계와 다른 구성이 있으므로 배포 후에 변경 내용을 테스트하는 것도 중요합니다. 또한 배포는 변경 내용에 따라 더 이상 데이터 수집을 트리거하여 소비자에게 잠재적인 비가용성을 최소화해야 합니다.

옵션 #2 사용은 언제 고려해야 하나요?

  • Git을 단일 진리 원본 및 모든 배포의 원본으로 사용하려는 경우
  • 팀이 트렁크 기반 워크플로를 분기 전략으로 따르는 경우
  • 배포하기 전에 connectionId 및 lakehouseId와 같은 작업 영역별 특성을 변경하려면 빌드 환경(사용자 지정 스크립트 포함)이 필요합니다.
  • git에서 항목 콘텐츠를 검색하고 수정된 패브릭 항목을 만들거나 업데이트하거나 삭제하기 위해 해당 패브릭 항목 API 를 호출하려면 릴리스 파이프라인(사용자 지정 스크립트)이 필요합니다.

옵션 3 - 패브릭 배포 파이프라인을 사용하여 배포

배포 파이프라인을 사용하는 Git 기반 배포의 흐름을 보여 주는 다이어그램

이 옵션을 사용하면 Git은 개발 단계까지만 연결됩니다. 개발 단계에서 배포는 패브릭 배포 파이프라인을 사용하여 Dev/Test/Prod의 작업 영역 간에 직접 수행됩니다. 도구 자체는 패브릭 내부이지만 개발자는 배포 파이프라인 API를 사용하여 Azure 릴리스 파이프라인 또는 GitHub 워크플로의 일부로 배포를 오케스트레이션할 수 있습니다. 이러한 API를 통해 팀은 자동화된 테스트(작업 영역 자체 또는 개발 단계 전에 수행할 수 있음), 승인 등을 사용하여 다른 옵션과 마찬가지로 유사한 빌드 및 릴리스 프로세스를 빌드할 수 있습니다.

주 분기에 대한 PR이 승인되고 병합되면 다음을 수행합니다.

  1. 패브릭 Git API를 사용하여 개발 단계에 변경 내용을 업로드하는 빌드 파이프라인이 트리거됩니다. 필요한 경우 파이프라인은 다른 API를 트리거하여 개발 단계에서 배포 후 작업/테스트를 시작할 수 있습니다.
  2. 개발 배포가 완료되면 릴리스 파이프라인이 시작되어 개발 단계에서 테스트 단계로 변경 내용을 배포합니다. 자동화된 수동 테스트는 프로덕션에 도달하기 전에 변경 내용이 잘 테스트되었는지 확인하기 위해 배포 후에 수행되어야 합니다.
  3. 테스트가 완료되고 릴리스 관리자가 Prod 스테이지에 대한 배포를 승인하면 Prod에 대한 릴리스가 시작되고 배포가 완료됩니다.

옵션 #3 사용은 언제 고려해야 하나요?

  • 개발 목적으로만 소스 제어를 사용하고 릴리스 파이프라인의 단계 간에 변경 내용을 직접 배포하는 것을 선호하는 경우
  • 배포 규칙의 경우 자동 바인딩 및 사용 가능한 다른 API는 릴리스 파이프라인의 단계 간의 구성을 관리하기에 충분합니다.
  • 패브릭 배포 파이프라인의 다른 기능(예: 패브릭의 변경 내용 보기, 배포 기록 등)을 사용하려는 경우
  • 또한 패브릭 배포 파이프라인의 배포에는 선형 구조가 있으며 파이프라인을 만들고 관리하기 위한 다른 권한이 필요합니다.

옵션 4 - 패브릭의 ISV용 CI/CD(여러 고객/솔루션 관리)

ISV에 대한 Git 기반 배포 흐름을 보여 주는 다이어그램

이 옵션은 다른 옵션과 다릅니다. 패브릭을 기반으로 고객을 위해 SaaS 애플리케이션을 빌드하는 ISV(Independent Software Vendor)와 가장 관련이 있습니다. ISV에는 일반적으로 각 고객에 대한 별도의 작업 영역이 있으며 수백 또는 수천 개의 작업 영역을 가질 수 있습니다. 각 고객에게 제공되는 분석 구조가 유사하고 기본 제공된 경우 Prod 단계에서만 각 고객에게 분할되는 중앙 집중식 개발 및 테스트 프로세스를 사용하는 것이 좋습니다.

이 옵션은 #2 옵션을 기반으로 합니다. PR에서 main으로의 PR이 승인되고 병합되면:

  1. 빌드 파이프라인은 새 빌드 환경을 스핀업하고 개발 단계에 대한 단위 테스트를 실행하도록 트리거됩니다. 테스트가 완료되면 릴리스 파이프라인이 트리거됩니다. 이 파이프라인은 빌드 환경에 콘텐츠를 업로드하고, 스크립트를 실행하여 일부 구성을 변경하고, 구성을 개발 단계로 조정한 다음, Fabric의 업데이트 항목 정의 API를 사용하여 파일을 작업 영역에 업로드할 수 있습니다.
  2. 릴리스 관리자의 데이터 수집 및 승인을 포함하여 이 프로세스가 완료되면 테스트 단계에 대한 다음 빌드 및 릴리스 파이프라인이 시작될 수 있습니다. 이 프로세스는 첫 번째 단계에서 설명한 프로세스와 비슷합니다. 테스트 단계의 경우 배포 후 다른 자동화 또는 수동 테스트가 필요할 수 있으며, 변경 내용이 고품질의 Prod 스테이지로 릴리스될 준비가 되었음을 확인할 수 있습니다.
  3. 모든 테스트가 통과되고 승인 프로세스가 완료되면 Prod 고객에게 배포를 시작할 수 있습니다. 각 고객에게는 고유한 매개 변수가 포함된 자체 릴리스가 있으므로 관련 고객의 작업 영역에서 특정 구성 및 데이터 연결이 수행될 수 있습니다. 구성 변경은 빌드 환경의 스크립트를 통해 또는 배포 후 API를 사용하여 발생할 수 있습니다. 모든 릴리스는 서로 관련되거나 종속되지 않으므로 병렬로 발생할 수 있습니다.

#4 옵션 사용은 언제 고려해야 하나요?

  • 패브릭을 기반으로 하는 ISV 빌드 애플리케이션입니다.
  • 각 고객에 대해 서로 다른 작업 영역을 사용하여 애플리케이션의 다중 테넌트 관리
  • 더 많은 분리를 위해 또는 다른 고객에 대한 특정 테스트의 경우 개발 또는 테스트의 이전 단계에서 다중 테넌티를 사용할 수 있습니다. 이 경우 다중 테넌트에서 필요한 작업 영역 수가 크게 증가하는 것을 고려합니다.

요약

이 문서에서는 Fabric에서 자동화된 CI/CD 프로세스를 빌드하려는 팀의 주요 CI/CD 옵션을 요약합니다. 네 가지 옵션을 간략하게 설명하지만 실제 제약 조건 및 솔루션 아키텍처는 하이브리드 옵션 또는 완전히 다른 옵션에 적용할 수 있습니다. 이 문서를 사용하여 다양한 옵션과 빌드 방법을 안내할 수 있지만 옵션 중 하나만 선택해야 하는 것은 아닙니다.

일부 시나리오 또는 특정 항목에는 이러한 시나리오를 채택하지 못하게 하는 제한 사항이 있을 수 있습니다.

도구도 마찬가지입니다. 여기서는 다양한 도구를 언급하지만 동일한 수준의 기능을 제공할 수 있는 다른 도구를 선택할 수 있습니다. 패브릭이 일부 도구와 더 잘 통합되어 있으므로 다른 도구를 선택하면 다른 해결 방법이 필요한 더 많은 제한 사항이 발생합니다.

관련 콘텐츠