Power BI 구현 계획: 콘텐츠 배포

이 문서는 콘텐츠 수명 주기 관리의 일부로 콘텐츠를 배포하는 데 도움이 됩니다. 주로 다음을 대상으로 합니다.

• 패브릭 관리자: 조직에서 패브릭 감독을 담당하는 관리자입니다. Fabric 관리자는 Microsoft 365 또는 Azure DevOps를 감독하는 관리자와 같은 다른 관리자와 협업해야 할 수도 있습니다.
• COE(우수성 센터) 및 BI 팀: 조직에서 Power BI의 감독을 담당하는 팀으로, 이러한 팀에는 Power BI 콘텐츠의 수명 주기를 관리하는 방법을 결정하는 의사 결정자가 포함됩니다. 또한 이러한 팀에는 콘텐츠 릴리스의 수명 주기를 처리하는 릴리스 관리자와 수명 주기 관리를 효과적으로 사용하고 지원하는 데 필요한 구성 요소를 만들고 관리하는 엔지니어가 포함될 수 있습니다.
• 콘텐츠 작성자 및 콘텐츠 소유자: 다른 사용자와 공유하기 위해 Fabric 포털에 게시하려는 콘텐츠를 만드는 사용자입니다. 이러한 개인은 자신이 만드는 Power BI 콘텐츠의 수명 주기를 관리할 책임이 있습니다.

수명 주기 관리는 콘텐츠 만들기부터 최종 사용 중지까지 콘텐츠를 처리하는 데 사용하는 프로세스 및 방식으로 구성됩니다. 수명 주기 관리의 세 번째 단계에서 콘텐츠 변경 내용의 유효성을 검사합니다. 여기에는 콘텐츠 작성자와 사용자 모두에 의해 수행되는 유효성 검사가 포함됩니다. 네 번째 단계에서는 소비자가 사용할 수 있도록 콘텐츠를 배포합니다.

소비자와 Power BI 콘텐츠를 공유하려면 먼저 Fabric 작업 영역에 콘텐츠를 게시(또는 배포)해야 합니다. 콘텐츠 배포에는 개발 작업 영역에서 테스트 작업 영역으로 배포하거나 테스트 작업 영역에서 프로덕션 작업 영역으로 배포하는 등의 환경 간에 해당 콘텐츠를 이동하는 작업도 포함됩니다.

다음 이미지는 콘텐츠를 배포하는 4단계를 강조 표시하면서 Power BI 콘텐츠의 수명 주기를 보여 줍니다.

콘텐츠 수명 주기 동안 두 가지 주요 시점에 콘텐츠를 배포합니다.

• 개발 작업 영역에 콘텐츠를 게시하는 경우입니다. 이 시점에서 변경 내용의 유효성을 검사하는 콘텐츠를 게시합니다.
• 두 작업 영역 간에 콘텐츠를 승격하는 경우입니다(예: 개발 작업 영역에서 테스트 작업 영역으로 콘텐츠 승격). 이 시점에서 콘텐츠가 다음 단계에 대해 준비되면(예: 새 콘텐츠를 테스트할 준비가 된 경우) 배포합니다.

다음 섹션에서는 콘텐츠를 게시하거나 승격하기 위해 수행할 수 있는 방법을 간략하게 설명합니다.

콘텐츠를 게시하는 방법 결정

로컬 머신에서 콘텐츠를 개발할 때 Fabric 포털의 개발 작업 영역에 해당 콘텐츠를 게시해야 합니다. 일반적으로 변경 내용의 유효성 검사를 수행하려는 경우 이 콘텐츠를 게시합니다.

다음 섹션에서는 콘텐츠를 게시하는 데 사용할 수 있는 다양한 방법을 설명합니다.

Power BI Desktop을 사용하여 게시

Power BI Desktop을 사용하면 사용자가 Fabric 포털의 작업 영역에 로컬 머신의 의미 체계 모델 및 보고서를 게시할 수 있습니다. 이 방법은 콘텐츠를 게시하는 가장 간단한 방법입니다. 그러나 자동화할 수는 없습니다.

다음과 같은 경우 이 방법을 사용하는 것이 좋습니다.

• 콘텐츠 작성자는 Fabric 포털에 대한 콘텐츠 게시를 수동으로 제어하는 것을 선호합니다.
• 콘텐츠 작성자는 Power BI Desktop을 사용하여 콘텐츠를 개발하고 관리합니다.
• 콘텐츠 작성자는 Azure DevOps 또는 Git에 익숙하지 않습니다.
• 콘텐츠는 의미 체계 모델 또는 보고서로만 구성됩니다.

타사 도구를 사용하여 게시

타사 도구를 사용하면 콘텐츠 작성자가 작업 영역 XMLA 읽기/쓰기 엔드포인트를 사용하여 의미 체계 모델을 게시할 수 있습니다. 예를 들어 콘텐츠 작성자는 테이블 형식 편집기를 사용하여 TMDL(테이블 형식 모델 정의 언어) 또는 .bim 파일과 같은 모델 메타데이터를 개발하고 관리합니다.

다음과 같은 경우 이 방법을 사용하는 것이 좋습니다.

• 콘텐츠 작성자는 Fabric 포털에 대한 콘텐츠 게시를 수동으로 제어하는 것을 선호합니다.
• 콘텐츠 작성자는 타사 도구를 사용하여 콘텐츠를 개발하고 관리합니다.
• 콘텐츠는 PPU(사용자 단위 Premium), 프리미엄 용량 또는 Fabric 용량 라이선스 모드를 사용하는 작업 영역에 게시됩니다.
• 콘텐츠 작성자는 Azure DevOps 또는 Git에 익숙하지 않습니다.
• 콘텐츠는 의미 체계 모델만 구성됩니다.

OneDrive 새로 고침을 사용하여 게시

OneDrive를 사용하면 셀프 서비스 콘텐츠 작성자가 OneDrive 새로 고침을 사용하여 Fabric 포털의 작업 영역에 의미 체계 모델 또는 보고서를 자동으로 게시할 수 있습니다. 콘텐츠 작성자는 Power BI Desktop(.pbix) 파일을 OneDrive의 공유 라이브러리에 저장할 수 있습니다. 공유 라이브러리는 SharePoint 또는 Microsoft Teams 문서 라이브러리일 수도 있습니다.

다음과 같은 경우 이 방법을 사용하는 것이 좋습니다.

• 콘텐츠 작성자는 Fabric 포털에 대한 콘텐츠 게시를 자동화하려고 합니다.
• 콘텐츠 작성자는 Azure DevOps 또는 Git에 익숙하지 않습니다.
• 콘텐츠 작성자는 OneDrive 또는 SharePoint를 사용하여 콘텐츠의 버전 제어를 수행합니다.
• 콘텐츠 작성자는 의미 체계 모델 및 보고서를 .pbix 파일로 저장합니다.
• 콘텐츠는 의미 체계 모델 또는 보고서로만 구성됩니다.

Fabric Git 통합을 사용하여 게시

패브릭 Git 통합은 콘텐츠 작성자가 원격 Git 리포지토리에서 Fabric 작업 영역으로 분기를 동기화할 수 있도록 하는 Fabric 용량 전용 기능입니다. Git 통합을 Azure DevOps와 함께 사용하여 Azure Repos의 콘텐츠를 동기화하거나 Azure Pipelines를 사용하여 콘텐츠를 배포할 수 있습니다(다음 섹션에서 설명).

요약하자면, 원격 리포지토리에 커밋되고 푸시된 콘텐츠는 이 동기화 프로세스를 통해 작업 영역에 자동으로 게시됩니다. 이 방법의 주요 이점은 소스 제어 관리 프로세스를 콘텐츠 게시와 결합할 수 있다는 것입니다. 예를 들어 변경 내용 또는 솔루션의 전체 버전을 더 쉽게 롤백할 수 있습니다.

다음과 같은 경우 이 방법을 사용하는 것이 좋습니다.

• 콘텐츠 작성자는 Azure DevOps 및 Git에 익숙합니다.
• 콘텐츠 작성자는 공동 작업 및 소스 제어에 Azure DevOps를 사용합니다.
• 콘텐츠 작성자는 의미 체계 모델 및 보고서를 Power BI 프로젝트(.pbip) 파일로 저장합니다.
• 콘텐츠는 Fabric 용량의 작업 영역에 게시됩니다.
• 콘텐츠는 Git 통합 기능에서 지원되는 항목 종류로 구성됩니다.
• 콘텐츠에 민감도 레이블이 없습니다.

Azure Pipelines를 사용하여 게시

Azure Pipelines는 프로그래밍 방식으로 콘텐츠 테스트, 관리, 배포를 자동화합니다. 파이프라인이 실행되면 파이프라인의 단계가 자동으로 실행됩니다. Azure Pipelines는 더 복잡하며 다른 접근 방식에 비해 설정하는 데 더 많은 시간과 노력이 필요하지만 배포 프로세스를 가장 제어하고 유연하게 오케스트레이션할 수 있습니다.

다음과 같은 경우 Azure Pipelines를 사용하여 콘텐츠 배포를 오케스트레이션하는 것이 좋습니다.

• 콘텐츠 작성자는 Azure DevOps 및 Fabric REST API에 익숙합니다.
• 콘텐츠 작성자는 공동 작업 및 소스 제어에 Azure DevOps를 사용합니다.
• 콘텐츠 작성자는 Fabric Git 통합을 사용하지 않습니다.

Azure Pipelines 및 기타 코드 기반 도구는 다음 API 또는 엔드포인트 중 하나 이상을 사용하여 프로그래밍 방식으로 콘텐츠를 배포할 수 있습니다.

• Power BI REST API: 콘텐츠를 배포하는 데 사용할 수 있는 다양한 Power BI REST API 엔드포인트가 있습니다. Power BI REST API는 Power BI 항목 종류만 지원합니다.
  • 가져오기: Power BI REST API를 사용하여 지원되는 항목을 게시하여 유효한 원본 파일을 작업 영역(예: .pbix 파일)으로 가져올 수 있습니다.
  • 배포: 지원되는 항목을 배포하여 배포 파이프라인의 단계인 경우 한 작업 영역에서 다른 작업 영역으로 승격할 수 있습니다.
• Fabric REST API: 콘텐츠를 배포하는 데 사용할 수 있는 다른 Fabric REST API 엔드포인트가 있습니다. Fabric REST API는 Power BI 및 Fabric 항목 종류를 모두 지원합니다.
  • 만들기: Fabric REST API를 유효한 항목 정의와 함께 사용하여 지원되는 항목을 만들 수 있습니다.
  • Git에서 업데이트: Git통합을 사용하여 연결된 원격 리포지토리의 콘텐츠로 작업 영역을 업데이트할 수 있습니다.
• XMLA 읽기/쓰기 엔드포인트: 유효한 model.bim 파일과 함께 XMLA 엔드포인트를 사용하여 의미 체계 모델을 만들거나 변경할 수 있습니다. XMLA 엔드포인트를 사용하면 전체 모델 대신 특정 모델 개체에 변경 내용을 배포할 수 있습니다. Azure Pipelines는 타사 도구(예: 테이블 형식 편집기 명령줄 인터페이스)를 사용하여 XMLA 엔드포인트를 사용하여 의미 체계 모델을 배포할 수 있습니다.

자동화된 테스트와 함께 Power BI와 Azure Pipelines를 통합하면 CI/CD(연속 통합 및 지속적인 배포)를 달성할 수 있습니다.

Azure Pipelines를 사용하는 경우 파이프라인 소유자는 배포 요구 사항에 맞게 트리거, 단계, 기능을 사용자 지정할 수 있습니다. 따라서 파이프라인의 수와 유형은 솔루션 요구 사항에 따라 달라집니다.

Power BI 솔루션을 테스트, 관리, 배포하기 위해 설정할 수 있는 세 가지 유형의 Azure Pipelines가 있습니다.

• 유효성 검사 파이프라인
• 빌드 파이프라인
• 릴리스 파이프라인

유효성 검사 파이프라인

유효성 검사 파이프라인은 개발 작업 영역에 게시되기 전에 데이터 모델의 기본 품질 검사를 수행합니다. 일반적으로 원격 리포지토리 분기의 변경 내용은 파이프라인을 트리거하여 자동화된 테스트를 통해 해당 변경 내용을 검증합니다.

자동화된 테스트의 예로는 BPA(모범 사례 분석기)를 사용하거나 게시된 의미 체계 모델에 대해 DAX 쿼리를 실행하여 데이터 모델에서 모범 사례 규칙 위반을 검색하는 것이 있습니다. 이러한 테스트 결과는 문서 및 감사 목적으로 원격 리포지토리에 저장됩니다. 유효성 검사에 실패한 데이터 모델은 게시하면 안 됩니다. 대신 파이프라인은 콘텐츠 작성자에게 문제를 알려야 합니다.

빌드 파이프라인

빌드 파이프라인은 Power BI 서비스에 게시할 데이터 모델을 준비합니다. 이러한 파이프라인은 직렬화된 모델 메타데이터를 나중에 릴리스 파이프라인에 의해 게시되는 단일 파일로 결합합니다. 또한 빌드 파이프라인은 매개 변수 값 수정과 같이 메타데이터에 변경 내용을 적용할 수도 있습니다. 빌드 파이프라인은 Power BI 서비스에 게시할 준비가 된 데이터 모델 메타데이터(데이터 모델용) 및 Power BI 프로젝트(.pbip)로 구성된 배포 아티팩트를 생성합니다.

릴리스 파이프라인

릴리스 파이프라인은 콘텐츠를 게시하거나 배포합니다. 게시 솔루션에는 일반적으로 대상 환경에 따라 여러 릴리스 파이프라인이 포함되어 있습니다.

• 개발 릴리스 파이프라인: 이 첫 번째 파이프라인은 자동으로 트리거됩니다. 빌드 및 유효성 검사 파이프라인이 성공한 후 개발 작업 영역에 콘텐츠를 게시합니다.
• 테스트 및 프로덕션 릴리스 파이프라인: 이러한 파이프라인은 자동으로 트리거되지 않습니다. 대신 요청 시 또는 승인 시 트리거됩니다. 테스트 및 프로덕션 릴리스 파이프라인은 릴리스 승인 후에 각각 테스트 또는 프로덕션 작업 영역에 콘텐츠를 배포합니다. 릴리스 승인은 콘텐츠가 준비되기 전에 테스트 또는 프로덕션 단계에 자동으로 배포되지 않도록 합니다. 이러한 승인은 테스트 및 프로덕션 환경에 대한 콘텐츠 릴리스를 계획하고 조정하는 책임을 맡은 릴리스 관리자가 제공합니다.

작업 영역 간에 콘텐츠를 승격하는 방법 결정

개발, 테스트, 프로덕션에 서로 다른 환경을 사용하는 경우 세 환경 모두에 콘텐츠를 배포해야 합니다. 특정 워크플로와 요구 사항에 따라 작업 영역 간에 콘텐츠를 승격하기 위해 수행할 수 있는 다양한 도구와 방법이 있습니다.

다음 섹션에서는 작업 영역 간에 콘텐츠를 승격하는 데 사용할 수 있는 방법을 설명합니다.

Fabric 배포 파이프라인을 사용하여 배포

배포 파이프라인을 사용하면 두 개 이상의 단계(예: 개발, 테스트 또는 프로덕션)를 설정하고 이러한 단계 간에 Fabric 콘텐츠를 배포할 수 있습니다. 파이프라인 관리자는 배포 파이프라인의 각 단계에 단일 Power BI 작업 영역을 할당합니다. 배포 파이프라인을 사용하는 방법은 작업 영역을 설정하고 사용하기로 결정한 방법에 따라 달라집니다.

다음과 같은 경우 배포 파이프라인을 사용하는 것이 좋습니다.

• 콘텐츠는 PPU, 프리미엄 용량 또는 Fabric 용량 라이선스 모드를 사용하여 작업 영역에 배포됩니다.
• 콘텐츠 항목 종류 및 시나리오는 배포 파이프라인에서 지원됩니다.

다음과 같은 경우 배포 파이프라인보다 다른 방법을 고려합니다.

• Azure Pipelines를 사용하는 등 원격 리포지토리에서 콘텐츠를 배포하는 것을 선호합니다.
• 콘텐츠를 배포하는 대신 Git 통합을 사용하여 원격 리포지토리의 여러 분기와 다른 단계를 동기화하려고 합니다.

배포 파이프라인을 사용하는 가장 간단한 방법은 모든 콘텐츠를 단일 작업 영역에 게시하고 단일 배포 파이프라인 내의 이후 단계로 승격하는 것입니다. 다음 다이어그램에서는 배포 파이프라인을 사용하여 콘텐츠를 배포하는 이 첫 번째 방법을 보여 줍니다.

요약하자면, 콘텐츠 작성자는 일반적으로 먼저 파이프라인의 초기 단계에 콘텐츠를 게시합니다. 그런 다음, 콘텐츠를 이후 단계로 승격하기 위해 파이프라인 관리자가 배포를 트리거합니다. 배포가 발생하면 배포 파이프라인은 한 작업 영역에서 다음 작업 영역으로 콘텐츠 메타데이터를 배포합니다.

다른 작업 영역의 항목 종류별로 콘텐츠를 구분하는 경우 별도의 배포 파이프라인을 사용하여 이 콘텐츠를 배포합니다. 자동 바인딩을 사용하여 여러 배포 파이프라인으로 작업 영역 간에 콘텐츠를 연결할 수 있습니다. 배포 파이프라인 간에 자동 바인딩을 수행하면 콘텐츠가 해당 단계의 적절한 항목에 연결된 상태로 유지됩니다. 예를 들어 개발 단계의 보고서는 다른 배포 파이프라인의 개발 단계에서 모델에 연결된 상태로 유지됩니다. 그러나 시나리오에서 다른 패턴으로 작업 영역 간에 콘텐츠를 연결해야 하는 경우 자동 바인딩 동작을 방지할 수도 있습니다.

다음 다이어그램에서는 여러 배포 파이프라인을 사용하여 콘텐츠를 배포하는 이 두 번째 방법을 보여 줍니다.

요약하자면, 여러 배포 파이프라인을 사용하여 콘텐츠를 배포하는 것은 단일 파이프라인을 사용하는 것과 비슷합니다. 주요 차이점은 선택적으로 자동 바인딩을 사용하여 작업 영역 및 배포 파이프라인 간에 연결된 콘텐츠를 연결할 수 있다는 것입니다. 그렇지 않으면 이는 첫 번째 방법과 동일합니다.

배포 파이프라인은 셀프 서비스 및 엔터프라이즈 시나리오 모두에 대한 콘텐츠 수명 주기 관리를 개선하는 데 적합한 유연하고 간단한 도구입니다.

배포를 수행하는 사용자에게는 작업 영역과 배포 파이프라인 모두에 대한 액세스가 필요합니다. 파이프라인 관리자가 배포 기록을 보고 콘텐츠를 비교할 수 있도록 배포 파이프라인 액세스를 계획하는 것이 좋습니다. 여러 콘텐츠 작성자와 공동 작업할 때 배포 및 릴리스 프로세스를 감독하는 데 가장 적합한 릴리스 관리자 또는 기술 소유자로 파이프라인 액세스를 제한하는 것이 좋습니다.

또한 배포 규칙을 사용하여 여러 단계의 항목에 대해 서로 다른 구성을 설정하는 것이 좋습니다. 예를 들어 개발 작업 영역의 의미 체계 모델은 개발 데이터베이스의 데이터를 원본으로 지정하고 프로덕션 작업 영역의 의미 체계 모델은 프로덕션 데이터베이스의 데이터를 원본으로 지정할 수 있습니다.

Power BI REST API를 사용하여 수동으로 또는 프로그래밍 방식으로 배포를 트리거할 수 있습니다. 두 경우 모두 각 단계로 콘텐츠를 승격하는 시기와 의도하지 않은 변경 내용을 롤백하는 방법에 대한 명확하고 강력한 프로세스를 정의해야 합니다.

수동으로 배포 수행

Fabric 배포 파이프라인을 사용하여 콘텐츠를 수동으로 배포할 수 있습니다. 모든 콘텐츠 배포를 선택하거나 항목을 선택할 수 있습니다. 선택적 배포는 일부 콘텐츠가 다음 단계로 이동할 준비가 되었지만 일부 항목은 아직 개발 또는 유효성 검사를 진행 중인 경우에 도움이 될 수 있습니다. 또한 콘텐츠 변경 내용이 이후 단계에 있지만 이전 단계에서는 없는 경우 이전 버전 배포를 수행할 수 있습니다.

수동 배포를 수행하는 경우 단계를 비교하여 변경 검토 창에서 콘텐츠 변경 내용을 식별할 수 있습니다. 이 방법은 소스 제어에 Git 원격 리포지토리를 사용하지 않는 경우에 특히 유용합니다.

Power BI REST API를 사용하여 배포 수행

Power BI REST API를 사용하여 배포 파이프라인을 사용하여 콘텐츠를 배포할 수 있습니다. REST API를 사용하는 이점은 배포를 자동화하고 Azure DevOps의 Azure Pipelines와 같은 다른 도구와 통합할 수 있다는 것입니다.

Azure Pipelines를 사용하여 배포

Azure Pipelines를 사용하면 모든 단계 간에 배포를 오케스트레이션할 수 있습니다. 이 방법을 사용하면 Fabric REST API를 사용하여 콘텐츠를 배포하고 관리하여 유효성 검사 및 릴리스 파이프라인과 같은 다양한 Azure Pipelines를 사용합니다.

다음과 같은 경우 Azure Pipelines를 사용하는 것이 좋습니다.

• Azure DevOps 내에서 배포 오케스트레이션을 중앙 집중화하려고 합니다.
• 콘텐츠 작성자는 Azure DevOps를 사용하여 공동 작업하고 소스 제어를 수행합니다.

다음과 같은 경우 Azure Pipelines가 아닌 다른 방법을 고려합니다.

• 콘텐츠 작성자는 Azure DevOps 또는 코드 기반 배포에 익숙하지 않습니다.
• 콘텐츠에는 대시보드와 같이 지원되는 정의 또는 원본 파일 형식이 없는 항목 종류가 포함됩니다.

Azure Pipelines를 사용하여 콘텐츠를 배포하는 방법에는 두 가지가 있습니다. 배포 파이프라인을 오케스트레이션하거나 배포 파이프라인 없이 작업 영역에 콘텐츠를 배포합니다.

Azure Pipelines를 사용하여 Fabric 배포 파이프라인 오케스트레이션

이 방법에서 릴리스 파이프라인은 배포 파이프라인을 사용하여 테스트 및 프로덕션 작업 영역에 콘텐츠 배포를 오케스트레이션합니다. 콘텐츠는 Fabric의 개발, 테스트, 프로덕션 작업 영역을 통해 승격됩니다.

다음 다이어그램은 Azure Pipelines에서 배포 파이프라인을 오케스트레이션하는 방법을 보여 줍니다.

요약하면 콘텐츠 작성자는 배포 파이프라인의 첫 번째 단계에서 작업 영역에 콘텐츠를 게시합니다. 그런 다음, 릴리스 관리자가 배포를 승인하여 Azure Pipeline을 트리거합니다. 이 파이프라인은 Power BI REST API를 사용하여 단계 간에 콘텐츠를 승격하여 메타데이터가 다른 작업 영역에 배포되도록 합니다. 이 방법의 한 가지 장점은 배포 파이프라인을 통해 여러 Fabric 항목 종류의 배포를 오케스트레이션할 수 있다는 것입니다. 일부 항목 유형은 Fabric 포털에서 개발되므로 Azure Pipelines에서만 배포할 수 없기 때문입니다.

Azure Pipelines만 사용하여 콘텐츠 배포

Azure Pipelines를 사용하여 Azure DevOps에서 작업 영역에 콘텐츠를 배포할 수도 있습니다. 이 방법은 배포 파이프라인을 사용하지 않습니다. 대신 릴리스 파이프라인을 사용하여 Fabric 또는 Power BI REST API 또는 XMLA 읽기/쓰기 엔드포인트를 사용하여 원본 파일 또는 메타데이터 파일을 배포합니다. 일반적으로 이러한 파일은 Azure Repos Git 리포지토리에 저장됩니다.

다음 다이어그램에서는 Azure Pipelines만 사용하여 콘텐츠를 배포하는 방법을 보여 줍니다.

요약하자면, 콘텐츠 작성자는 Azure Repos의 원격 Git 리포지토리에 콘텐츠 변경 내용을 커밋하고 푸시합니다. 이 콘텐츠는 배포를 위해 Azure Pipelines에서 사용됩니다. 릴리스 관리자가 특정 배포를 승인하면 Azure Pipeline은 Power BI REST API(즉, .pbix 파일의 경우), Fabric REST API(항목 정의의 경우) 또는 XMLA 엔드포인트(즉, model.bim 파일)를 사용하여 작업 영역에 콘텐츠를 배포합니다. 각 작업 영역에 대해 별도의 Azure Pipeline이 있습니다.

이 방법은 Power BI REST API를 사용하여 Power BI Desktop 파일만 게시하는 경우 Fabric 용량 또는 프리미엄 라이선스가 필요하지 않습니다. 그러나 Power BI 외부에서 배포를 관리해야 하므로 더 많은 설정 노력과 복잡성이 필요합니다. 이미 Power BI 외부의 데이터 솔루션에 DevOps를 사용하고 있는 개발 팀은 이 방법에 더 익숙할 수 있습니다. 이 방법을 사용하는 개발 팀은 Azure DevOps에서 데이터 솔루션 배포를 통합할 수 있습니다.

Fabric Git 통합을 사용하여 배포

Git 통합을 사용하는 경우 콘텐츠를 명시적으로 게시하거나 배포하는 대신 다른 분기를 다른 작업 영역에 동기화할 수 있습니다. 이렇게 하면 개발, 테스트, 프로덕션 작업 영역을 위한 별도의 분기를 가질 수 있습니다. 이 시나리오에서는 기본 분기가 프로덕션 작업 영역과 동기화됩니다. 그런 다음, 끌어오기 요청을 수행하여 개발 분기를 테스트 분기에 병합하거나(테스트 작업 영역에 배포) 테스트 분기를 기본 분기로 병합하여(프로덕션 작업 영역에 배포) 작업 영역 간에 콘텐츠를 배포합니다.

다음 다이어그램에서는 Fabric Git 통합을 사용하여 다른 작업 영역에 분기를 동기화하여 콘텐츠를 배포하는 방법을 보여 줍니다. 간단히 하기 위해 다이어그램에는 콘텐츠 분기 또는 병합에 대한 세부 정보가 포함되지 않습니다.

요약하자면, 콘텐츠 작성자는 Azure Repos의 원격 Git 리포지토리에 콘텐츠 변경 내용을 커밋하고 푸시합니다. 콘텐츠 작성자는 PR(끌어오기 요청)을 열어 변경 내용을 특정 분기에 병합하도록 요청합니다. 분기 전략에 따라 분기가 서로 다른 작업 영역에 연결됩니다. 변경 내용이 분기에 병합되면 콘텐츠 작성자는 작업 영역을 원격 Git 리포지토리와 동기화하여 해당 작업 영역의 콘텐츠에 대한 최신 변경 내용을 봅니다.

다음과 같은 경우 이 방법을 고려합니다.

• 분기 및 병합 전략을 사용하여 작업 영역 간의 배포를 오케스트레이션하려고 합니다.
• 테스트 및 프로덕션에 대한 배포를 오케스트레이션하는 데 Azure Pipelines 또는 Fabric 배포 파이프라인을 사용하지 않으려고 합니다.
• 작업 영역에 지원되지 않는 항목 또는 시나리오가 포함되어 있지 않습니다.
• 콘텐츠에 민감도 레이블이 없습니다.

배포 후 작업을 처리하는 방법 결정

배포 후에는 처리해야 하는 다양한 배포 후 활동이 있습니다. 이러한 활동의 대부분은 프로그래밍 방식으로 처리할 수 있습니다(예: Azure Pipeline 또는 Notebook, Power BI, Fabric REST API). 예를 들어 프로그래밍 방식으로 데이터 원본 자격 증명을 설정하고, 예약된 새로 고침을 관리하고, 메타데이터 배포 후 새로 고침을 트리거할 수 있습니다. 그러나 일부 작업에는 Power BI 앱을 처음 설치하거나 업데이트하는 등의 수동 작업이 필요합니다.

콘텐츠에 대한 모든 관련 배포 후 활동을 식별하고 처리 방법을 결정해야 합니다.

콘텐츠를 배포하는 방법을 계획한 후에는 콘텐츠를 지원하고 모니터링하는 방법을 고려해야 합니다.

검사 목록 - 콘텐츠를 배포하는 방법을 계획할 때 주요 결정 및 작업에는 다음이 포함됩니다.

관련 콘텐츠

이 시리즈의 다음 문서에서는 콘텐츠 수명 주기 관리의 일환으로 콘텐츠를 지원하고 모니터링하는 방법을 알아봅니다.