Power BI 사용 시나리오: 엔터프라이즈 콘텐츠 게시

  • 아티클

참고 항목

이 문서는 Power BI 구현 계획 시리즈의 일부를 구성합니다. 이 시리즈는 주로 Microsoft Fabric 내의 Power BI 워크로드에 중점을 둡니다. 시리즈에 대한 소개는 Power BI 구현 계획을 참조하세요.

콘텐츠 작성자가 조직에 중요한 분석 솔루션을 제공하기 위해 협업할 때는 소비자에게 콘텐츠를 적시에 안정적으로 제공할 수 있어야 합니다. 기술 팀은 DevOps라는 프로세스를 사용하여 이 문제를 해결합니다. DevOps를 사용하면 팀이 제공을 개선하고 가속화하는 방법을 채택하여 프로세스를 자동화하고 확장할 수 있습니다.

참고 항목

동일한 문제를 해결하는 데이터 팀은 DataOps를 실행할 수도 있습니다. DataOps는 DevOps 원칙을 기반으로 구축되지만 DataOps에는 데이터 품질 보증 및 거버넌스와 같은 데이터 관리와 관련된 추가 방법이 포함되어 있습니다. 이 문서에서는 DevOps를 언급하지만 기본 원칙은 DataOps에도 적용될 수 있습니다.

콘텐츠 작성자와 소비자는 DevOps 방법을 채택하여 Power BI 콘텐츠를 게시하는 경우 여러 가지 이점을 누릴 수 있습니다. 다음은 이 프로세스의 작동 방식에 대한 개요입니다.

  1. 콘텐츠를 개발하고 작업을 원격 리포지토리에 커밋: 콘텐츠 작성자는 자신의 컴퓨터에서 솔루션을 개발합니다. 개발 중에 정기적으로 작업을 원격 리포지토리에 커밋하고 저장합니다. 원격 리포지토리에는 솔루션의 최신 버전이 있으며 전체 개발 팀이 액세스할 수 있습니다.
  2. 버전 제어를 사용하여 콘텐츠 변경 협업 및 관리: 다른 콘텐츠 작성자는 분기를 만들어 솔루션을 수정할 수 있습니다. 분기는 원격 리포지토리의 복사본입니다. 이러한 수정 내용이 준비되고 승인되면 분기가 솔루션의 최신 버전과 병합됩니다. 솔루션에 대한 모든 수정 내용이 추적됩니다. 이 프로세스를 버전 제어(또는 소스 제어)라고 합니다.
  3. 파이프라인을 사용하여 콘텐츠 배포 및 승격:셀프 서비스 콘텐츠 게시 사용 시나리오에서는 Power BI 배포 파이프라인을 사용하여 개발, 테스트, 프로덕션 작업 영역을 통해 콘텐츠가 승격(또는 배포)됩니다. Power BI 배포 파이프라인은 사용자 인터페이스를 사용하여 수동으로 또는 REST API를 사용하여 프로그래밍 방식으로 Power BI Premium 작업 영역으로 콘텐츠를 승격할 수 있습니다. 반면 엔터프라이즈 콘텐츠 게시(이 사용 시나리오의 핵심)는 Azure Pipelines를 사용하여 콘텐츠를 승격합니다. Azure Pipelines는 일련의 사용자 지정된 프로그래밍 단계를 사용하여 콘텐츠의 테스트, 관리, 배포를 자동화하는 Azure DevOps 서비스입니다. 엔터프라이즈 콘텐츠 게시 사용 시나리오에서 이러한 파이프라인은 연속 통합 및 지속적인 배포(또는 CI/CD) 파이프라인이라고도 할 수 있습니다. 이러한 파이프라인은 변경 내용을 자주 자동으로 통합하고 콘텐츠 게시를 간소화합니다.

Important

때때로 이 문서는 Power BI Premium 또는 P SKU(용량 구독)를 참조합니다. Microsoft는 현재 구매 옵션을 통합하고 용량 SKU당 Power BI Premium을 사용 중지하고 있습니다. 신규 및 기존 고객은 F SKU(패브릭 용량 구독)를 대신 구매하는 것을 고려해야 합니다.

자세한 내용은 Power BI Premium 라이선스 및 Power BI Premium FAQ에 제공되는 중요 업데이트를 참조하세요.

DevOps는 콘텐츠 관리 및 게시에 대한 성숙하고 체계적인 방법을 지원합니다. 이를 통해 콘텐츠 작성자는 솔루션에 대해 협업할 수 있으며 소비자에게 콘텐츠를 빠르고 안정적으로 제공할 수 있습니다. DevOps 방법을 준수하면 워크플로가 간소화되고 오류가 줄어들며 콘텐츠 작성자와 콘텐츠 소비자를 위한 환경이 개선되는 이점을 누릴 수 있습니다.

Azure DevOps를 사용하여 Power BI 솔루션에 대한 DevOps 방법을 설정하고 관리합니다. 엔터프라이즈 시나리오에서는 세 가지 방법으로 Azure DevOps 및 Power BI REST API를 사용하여 콘텐츠 게시를 자동화할 수 있습니다.

  • Power BI 배포 파이프라인이 포함된 Power BI REST API: 콘텐츠를 개발 작업 영역으로 가져오고 배포 파이프라인을 사용하여 테스트 및 프로덕션 작업 영역을 통해 콘텐츠를 배포할 수 있습니다. 여전히 Azure DevOps에서 배포를 제어하고 Power BI REST API를 사용하여 개별 콘텐츠 항목 대신 배포 파이프라인을 관리합니다. 또한 Azure DevOps에서 Power BI Desktop 파일(.pbix) 대신 XMLA 엔드포인트를 사용하여 데이터 모델 메타데이터를 배포합니다. 이 메타데이터를 사용하면 버전 제어를 사용하여 개체 수준 변경 내용을 추적할 수 있습니다. 이 방법은 더 강력하고 유지 관리하기가 더 쉽지만 Power BI REST API를 사용하여 콘텐츠 가져오기와 배포를 설정하기 위한 프리미엄 라이선스와 보통 수준의 스크립팅 노력이 필요합니다. 배포 파이프라인을 사용하여 콘텐츠 수명 주기 관리를 간소화하고 프리미엄 라이선스가 있는 경우 이 방법을 사용합니다. XMLA 엔드포인트와 Power BI 배포 파이프라인은 프리미엄 기능입니다.
  • Power BI REST API: Azure DevOps와 Power BI REST API만 사용하여 개발, 테스트, 프로덕션 작업 영역으로 콘텐츠를 가져올 수도 있습니다. 이 방법에는 프리미엄 라이선싱이 필요하지 않지만 배포가 Power BI 외부에서 관리되므로 높은 수준의 스크립팅 노력과 설정이 필요합니다. Azure DevOps에서 Power BI 콘텐츠를 중앙에서 배포하려는 경우 또는 프리미엄 라이선스가 없는 경우 이 방법을 사용합니다. 처음 두 가지 방법을 시각적으로 비교하려면 릴리스 파이프라인 방법 흐름 다이어그램을 참조하세요.
  • Power BI 배포 파이프라인이 포함된 Power BI 자동화 도구: Power BI REST API 대신 Power BI 자동화 도구 Azure DevOps 확장을 사용하여 배포 파이프라인을 관리할 수 있습니다. 이 방법은 Power BI 배포 파이프라인과 함께 Power BI REST API를 사용하는 첫 번째 옵션의 대안입니다. Power BI 자동화 도구 확장은 오픈 소스 도구입니다. PowerShell 스크립트를 작성할 필요 없이 Azure DevOps에서 콘텐츠를 관리하고 게시하는 데 도움이 됩니다. 최소한의 스크립팅 노력으로 Azure DevOps에서 배포 파이프라인을 관리하려고 하고 프리미엄 용량이 있는 경우 이 방법을 사용합니다.

이 문서에서는 Power BI 배포 파이프라인과 함께 Power BI REST API를 사용하는 첫 번째 옵션에 중점을 둡니다. Azure DevOps를 사용하여 DevOps 방법을 설정하는 방법을 설명합니다. 또한 원격 리포지토리에 Azure Repos를 사용하고 Azure Pipelines를 통해 콘텐츠 테스트, 통합, 제공을 자동화하는 방법도 설명합니다. Azure DevOps는 엔터프라이즈 콘텐츠 게시를 설정하는 유일한 방법은 아니지만 Power BI와 간단하게 통합할 수 있으므로 좋은 선택입니다.

참고 항목

이 사용 시나리오는 콘텐츠 관리 및 배포 시나리오 중 하나입니다. 간단히 하기 위해 콘텐츠 협업 및 배달 시나리오 항목에 설명된 몇 가지 측면은 이 문서에서 다루지 않습니다. 전체 범위를 파악할 수 있도록 해당 문서를 먼저 읽어보세요.

팁

Microsoft Fabric은 Fabric Git 통합을 사용하여 엔터프라이즈 콘텐츠 게시를 위한 다른 옵션을 제공합니다. Git 통합을 사용하면 Azure Repos 원격 리포지토리 분기에 패브릭 작업 영역을 연결할 수 있습니다. 해당 분기에 저장된 콘텐츠는 해당 콘텐츠가 작업 영역에 게시된 것처럼 작업 영역에 자동으로 동기화됩니다. 반대로 콘텐츠 작성자는 패브릭 작업 영역의 변경 내용을 커밋하고 원격 리포지토리 푸시할 수 있습니다.

Git 통합은 공동 작업 및 콘텐츠 게시를 간소화할 수 있지만 패브릭 작업 영역을 사용하는 방법과 분기 전략이 무엇인지에 대한 더 많은 계획이 필요합니다. 패브릭 Git 통합을 설정하고 사용하는 방법에 대한 자세한 내용은 Git 통합 시작 또는 자습서: 종단 간 수명 주기 관리를 참조하세요.

시나리오 다이어그램

다음 다이어그램은 엔터프라이즈 콘텐츠 게시를 지원하는 가장 일반적인 사용자 작업과 Power BI 구성 요소에 대한 개요를 보여 줍니다. Azure DevOps를 사용하여 Power BI 서비스의 개발, 테스트, 프로덕션 작업 영역을 통해 대규모의 프로그래밍 방식으로 콘텐츠를 관리하고 게시하는 데 중점을 둡니다.

다이어그램은 Azure DevOps를 사용하여 공동 작업을 강화하고 대규모로 콘텐츠를 관리하는 엔터프라이즈 콘텐츠 게시를 보여 줍니다. 다이어그램의 항목은 표에 설명되어 있습니다.

팁

프레젠테이션, 설명서 또는 블로그 게시물에 포함하려는 경우 시나리오 다이어그램을 다운로드하거나 벽 포스터로 인쇄하는 것이 좋습니다. SVG(확장 가능한 벡터 그래픽) 이미지이므로 품질 손실 없이 확장하거나 축소할 수 있습니다.

시나리오 다이어그램은 다음과 같은 사용자 작업, 프로세스, 기능을 보여 줍니다.

Item 설명
항목 1. 콘텐츠 작성자는 Power BI Desktop 또는 테이블 형식 편집기를 사용하여 데이터 모델을 개발하고 Power BI Desktop을 사용하여 보고서를 개발합니다. 콘텐츠 작성자는 개발 중에 작업을 로컬 리포지토리에 저장합니다.
항목 2. 콘텐츠 작성자는 원격 리포지토리 복제하여 해당 콘텐츠의 로컬 복사본을 가져올 수 있습니다.
항목 3. 일부 데이터 원본에는 개인 조직 네트워크 내에 있는 것과 같이 데이터 새로 고침을 위해 온-프레미스 데이터 게이트웨이 또는 VNet 게이트웨이가 필요할 수 있습니다.
항목 4. 콘텐츠 작성자는 Visual Studio Code와 같은 Git 클라이언트를 사용하여 개발 중에 정기적으로 변경 내용을 원격 리포지토리에 커밋하고 푸시합니다. 다이어그램에서 원격 리포지토리 Azure Repos입니다.
항목 5. 다른 콘텐츠 작성자는 Azure Repos를 사용하여 버전 제어를 통해 변경 내용을 추적합니다. 변경 내용을 별도의 분기에 커밋하여 협업합니다.
항목 6. 원격 리포지토리의 콘텐츠를 변경하면 Azure Pipelines가 트리거됩니다. 유효성 검사 파이프라인은 트리거되는 첫 번째 파이프라인입니다. 유효성 검사 파이프라인은 자동화된 테스트를 수행하여 콘텐츠를 게시하기 전에 유효성을 검사합니다.
항목 7. 유효성 검사 파이프라인을 통과한 콘텐츠는 후속 빌드 파이프라인을 트리거합니다. 빌드 파이프라인은 Power BI 서비스에 게시할 콘텐츠를 준비합니다. 이 시점까지의 프로세스를 일반적으로 CI(연속 통합)라고 합니다.
항목 8. 콘텐츠는 릴리스 파이프라인을 사용하여 게시 및 배포됩니다. 릴리스 파이프라인은 Power BI REST API 또는 작업 영역 XMLA 엔드포인트를 사용하여 프로그래밍 방식으로 콘텐츠를 Power BI 서비스 가져옵니다. 릴리스 파이프라인을 사용한 배포는 일반적으로 CD(지속적인 배포)라고 합니다.
항목 9. 릴리스 관리자는 Azure Pipelines 릴리스 승인을 사용하여 테스트 및 프로덕션 작업 영역에 대한 배포를 제어합니다. 엔터프라이즈 콘텐츠 게시에서 릴리스 관리자는 일반적으로 테스트 및 프로덕션 환경에 대한 콘텐츠 릴리스를 계획하고 조정합니다. 콘텐츠 작성자, 관련자, 사용자와 조정하고 소통합니다.
항목 10. 릴리스 파이프라인은 개발 작업 영역에 콘텐츠를 게시하거나 개발에서 테스트 작업 영역으로 콘텐츠를 승격하거나 프로덕션 작업 영역으로 테스트합니다.
항목 11. 패브릭 용량 라이선스 모드가 있는 작업 영역에서 작업하는 콘텐츠 작성자는 Git 통합을 사용할 수 있습니다. Git 통합을 통해 콘텐츠 작성자는 개발 중에 프라이빗 작업 영역에서 작업할 수 있습니다. 콘텐츠 작성자는 Azure Repos에서 개인 작업 영역으로 원격 분기(일반적으로 특정 기능 분기 또는 버그 분기)를 동기화합니다. 콘텐츠 변경 내용은 Azure Repos의 원격 분기와 작업 영역 간에 동기화됩니다. 이 시나리오에서는 콘텐츠 작성자가 Azure Pipelines를 사용하여 콘텐츠를 게시할 필요가 없습니다. 콘텐츠 작성자는 게시 후 작업 영역에서 변경 내용을 정기적으로 커밋하고 푸시할 수도 있습니다. 준비가 되면 콘텐츠 작성자는 PR(끌어오기 요청)을 만들어 변경 내용을 기본 분기에 병합할 수 있습니다.
항목 12. Git 통합을 사용하는 경우 개발 작업 영역은 기본 분기와 동기화하여 최신 버전의 콘텐츠를 가져옵니다. 이 콘텐츠에는 릴리스 관리자가 검토, 승인 및 병합하는 끌어오기 요청의 모든 변경 내용이 포함됩니다.
항목 13. 작업 영역은 Power BI 배포 파이프라인 및 XMLA 읽기/쓰기 엔드포인트를 사용할 수 있도록 패브릭 용량, 프리미엄 용량, 사용자 단위 Premium 또는 Embedded라이선스 모드로 설정됩니다.
항목 14. 배포 파이프라인 관리자는 개발, 테스트 및 프로덕션의 세 단계로 Power BI 배포 파이프라인을 설정합니다. 각 단계는 Power BI 서비스의 별도 작업 영역에 맞춰집니다. 배포 파이프라인에 대한 배포 설정 및 액세스가 설정됩니다.
항목 15. 개발 작업 영역에는 승인된 모든 변경 내용과 병합된 변경 내용을 포함한 최신 버전의 콘텐츠가 포함되어 있습니다. 승인되면 릴리스 파이프라인은 개발에서 테스트 작업 영역으로 콘텐츠를 배포합니다.
항목 16. 테스트 작업 영역 내의 검토자는 콘텐츠에 대한 테스트 및 품질 보증을 수행합니다. 승인되면 릴리스 파이프라인은 테스트의 콘텐츠를 프로덕션 작업 영역으로 배포합니다. 배포 파이프라인과 Git 통합을 사용하는 경우 테스트 작업 영역은 분기와 동기화되지 않습니다.
항목 17. 배포 파이프라인이 배포를 완료하면 콘텐츠 작성자가 배포 후 작업을 수동으로 수행합니다. 작업에는 예약된 데이터 새로 고침 설정 또는 프로덕션 작업 영역에 대한 Power BI 앱 업데이트가 포함될 수 있습니다. 배포 파이프라인과 Git 통합을 사용하는 경우 프로덕션 작업 영역은 분기와 동기화되지 않습니다.
항목 18. 콘텐츠 뷰어는 프로덕션 작업 영역 또는 Power BI 앱을 사용하여 콘텐츠에 액세스합니다.

팁

또한 셀프 서비스 콘텐츠 게시 및 고급 데이터 모델 관리 사용 시나리오를 검토하는 것이 좋습니다. 엔터프라이즈 콘텐츠 게시 사용 시나리오는 이러한 시나리오에서 소개하는 개념을 기반으로 합니다.

핵심 내용

다음은 엔터프라이즈 콘텐츠 게시 시나리오에 대해 강조해야 할 몇 가지 핵심 사항입니다.

버전 제어

콘텐츠 수명 주기 동안 변경 내용을 추적하는 것은 소비자에게 콘텐츠를 안정적이고 일관되게 제공하는 데 중요합니다. 이 사용 시나리오에서는 콘텐츠 작성자와 소유자가 버전 제어를 사용하여 원격 리포지토리의 콘텐츠 변경 내용을 관리합니다. 버전 제어는 중앙 리포지토리에 있는 파일이나 코드의 변경 내용을 관리하는 방법입니다. 이 방법을 사용하면 협업을 개선하고 버전 기록을 효과적으로 관리할 수 있습니다. 버전 제어는 변경 내용을 롤백하거나 병합하는 기능을 포함하여 콘텐츠 작성자에게 이점을 제공합니다.

콘텐츠 작성자는 일반적으로 더 나은 버전 제어를 지원하기 위해 테이블 형식 편집기에서 데이터 모델을 개발합니다. Power BI Desktop에서 개발하는 데이터 모델과 달리 테이블 형식 편집기에서 개발된 데이터 모델은 사람이 읽을 수 있는 메타데이터 형식으로 저장됩니다. 이 형식을 사용하면 데이터 모델 개체 수준 버전 제어를 사용할 수 있습니다. 동일한 데이터 모델에서 여러 사람과 협업하는 경우 개체 수준 버전 제어를 사용해야 합니다. 자세한 내용은 고급 데이터 모델 관리 사용 시나리오를 참조하세요. 보고서 정의 또는 데이터 모델과 같은 Power BI Desktop 파일(.pbix)에서는 변경 내용을 볼 수 없습니다. 예를 들어 사용된 시각적 개체, 해당 위치, 필드 매핑 또는 서식과 같은 보고서 페이지의 변경 내용을 추적할 수 없습니다.

콘텐츠 작성자는 Azure Repos와 같은 중앙 원격 리포지토리에 데이터 모델 메타데이터 파일과 .pbix 파일을 저장합니다. 이러한 파일은 기술 소유자가 큐레이팅합니다. 콘텐츠 작성자가 솔루션을 개발하는 동안 기술 소유자는 솔루션을 관리하고 변경 내용을 검토하며 이를 단일 솔루션으로 병합하는 작업을 담당합니다. Azure Repos는 변경 내용을 추적하고 관리하기 위한 정교한 옵션을 제공합니다. 이 방법은 작성자가 버전 추적 기능이 있는 OneDrive 스토리지를 사용하는 셀프 서비스 콘텐츠 게시 사용 시나리오에 설명된 방법과 다릅니다. 잘 큐레이팅되고 문서화된 리포지토리를 유지 관리하는 것은 모든 콘텐츠와 협업의 기초이므로 매우 중요합니다.

버전 제어를 위한 원격 리포지토리를 설정하는 데 도움이 되는 몇 가지 주요 고려 사항은 다음과 같습니다.

  • 범위: 리포지토리의 범위를 명확하게 정의합니다. 이상적으로 리포지토리의 범위는 소비자에게 콘텐츠를 제공하는 데 사용하는 다운스트림 작업 영역 및 앱의 범위와 동일합니다.
  • 액세스:배포 파이프라인 권한 및 작업 영역 역할에 대해 설정한 것과 유사한 권한 모델을 사용하여 리포지토리에 대한 액세스를 설정해야 합니다. 콘텐츠 작성자는 리포지토리에 액세스해야 합니다.
  • 문서: 리포지토리에 텍스트 파일을 추가하여 리포지토리의 용도, 소유권, 액세스, 정의된 프로세스를 문서화합니다. 예를 들어 문서에서는 변경 내용을 준비하고 커밋하는 방법을 설명할 수 있습니다.
  • 도구: 변경 내용을 원격 리포지토리에 커밋하고 푸시하려면 콘텐츠 작성자에게 Visual Studio 또는 Visual Studio Code와 같은 Git 클라이언트가 필요합니다. Git은 파일의 변경 내용을 추적하는 분산 버전 제어 시스템입니다. Git 기본 사항을 알아보려면 Git이란?를 참조하세요.

참고 항목

Power BI Desktop 파일(.pbix)을 커밋하려는 경우 Git LFS(Large File Storage) 사용을 고려하세요. Git LFS는 .pbix 파일과 같이 변경 내용이 표시되지 않는 파일(확인할 수 없는 파일)을 관리하기 위한 고급 옵션을 제공합니다. 예를 들어 파일 잠금을 사용하여 개발 중에 Power BI 보고서가 동시에 변경되는 것을 방지할 수 있습니다. 그러나 Git LFS에는 자체 클라이언트와 구성이 있습니다.

Azure DevOps와의 협업

솔루션의 범위와 복잡성이 증가함에 따라 여러 콘텐츠 작성자와 소유자의 협업이 필요할 수 있습니다. 콘텐츠 작성자와 소유자는 Azure DevOps를 사용하여 중앙의 조직된 허브에서 소통하고 협업합니다.

Azure DevOps에서 협업하고 소통하려면 지원 서비스를 사용합니다.

  • Azure Boards: 콘텐츠 소유자는 보드를 사용하여 작업 항목을 추적합니다. 작업 항목은 각각 팀의 단일 개발자에게 할당되며 솔루션의 문제, 버그 또는 기능과 해당 관련자를 설명합니다.
  • Azure Wiki: 콘텐츠 작성자는 솔루션을 이해하고 기여하기 위해 팀과 정보를 공유합니다.
  • Azure Repos: 콘텐츠 작성자는 원격 리포지토리의 변경 내용을 추적하고 이를 단일 솔루션으로 병합합니다.
  • Azure Pipelines: 파이프라인 소유자는 프로그래밍 방식 논리를 설정하여 자동으로 또는 주문형으로 솔루션을 배포합니다.

협업 흐름 다이어그램

다음 다이어그램에서는 Azure DevOps가 엔터프라이즈 콘텐츠 게시 사용 시나리오에서 협업을 사용하도록 설정하는 방법의 한 가지 예에 대한 개략적인 개요를 보여 줍니다. 이 다이어그램의 초점은 Azure DevOps를 사용하여 구조화되고 문서화된 콘텐츠 게시 프로세스를 만드는 것입니다.

위 단락에 설명된 다이어그램입니다. 다이어그램의 항목은 아래 표에 설명되어 있습니다.

다이어그램은 다음과 같은 사용자 작업, 프로세스 및 기능을 보여 줍니다.

Item 설명
항목 1. 콘텐츠 작성자는 최신 버전의 콘텐츠가 포함된 기본 분기를 복제하여 수명이 짧은 새 분기를 만듭니다. 새 분기는 특정 기능을 개발하거나 특정 문제를 해결하는 데 사용되므로 기능 분기라고도 합니다.
항목 2. 콘텐츠 작성자는 개발 중에 변경 내용을 로컬 리포지토리에 커밋합니다.
항목 3. 콘텐츠 작성자는 변경 내용을 Azure Boards에서 관리되는 작업 항목에 연결합니다. 작업 항목은 해당 분기 범위의 특정 개발, 개선 또는 버그 수정을 설명합니다.
항목 4. 콘텐츠 작성자는 정기적으로 변경 내용을 커밋합니다. 준비가 되면 콘텐츠 작성자는 원격 리포지토리에 분기를 게시합니다.
항목 5. 변경 내용을 테스트하기 위해 콘텐츠 작성자는 개발을 위해 격리된 작업 영역에 솔루션을 배포합니다(이 다이어그램에 표시되지 않음). 콘텐츠 작성자는 패브릭 Git 통합을 사용하여 기능 분기 작업 영역에 동기화할 수도 있습니다.
항목 6. 콘텐츠 작성자와 콘텐츠 소유자는 전체 개발 팀이 사용할 수 있는 Azure Wiki에 솔루션과 해당 프로세스를 문서화합니다.
항목 7. 준비가 되면 콘텐츠 작성자가 끌어오기 요청을 열어 기능 분기 기본 분기에 병합합니다.
항목 8. 기술 소유자는 끌어오기 요청을 검토하고 변경 내용을 병합하는 작업을 담당합니다. 끌어오기 요청을 승인하면 기능 분기 기본 분기에 병합합니다.
항목 9. 성공적인 병합은 Azure Pipeline을 사용하여 개발 작업 영역에 솔루션을 배포하도록 트리거합니다(이 다이어그램에 표시되지 않음). Fabric Git 통합을 사용하는 경우 기본 분기는 개발 작업 영역과 동기화됩니다.
항목 10. 릴리스 관리자는 솔루션에 대한 최종 검토 및 승인을 수행합니다. 이 릴리스 승인은 솔루션이 준비되기 전에 게시되는 것을 방지합니다. 엔터프라이즈 콘텐츠 게시에서 릴리스 관리자는 일반적으로 콘텐츠 릴리스를 계획하고 조정하여 테스트 및 프로덕션 작업 영역을 만듭니다. 콘텐츠 작성자, 관련자, 사용자와 조정하고 소통합니다.
항목 11. 릴리스 관리자가 릴리스를 승인하면 Azure Pipelines는 자동으로 배포용 솔루션을 준비합니다. 또는 Azure Pipeline은 배포 파이프라인을 트리거하여 작업 영역 간에 콘텐츠를 승격할 수도 있습니다.
항목 12. 사용자는 테스트 작업 영역에서 콘텐츠를 테스트하고 유효성을 검사합니다. 배포에 Azure Pipelines와 Git 통합을 사용하는 경우 테스트 작업 영역은 분기와 동기화되지 않습니다.
항목 13. 사용자가 변경 내용을 수락하고 유효성을 검사한 후 릴리스 관리자는 솔루션에 대한 최종 검토 및 승인을 수행하여 프로덕션 작업 영역에 배포합니다.
항목 14. 사용자는 프로덕션 작업 영역에 게시된 콘텐츠를 봅니다. 배포에 Azure Pipelines와 Git 통합을 사용하는 경우 프로덕션 작업 영역은 분기와 동기화되지 않습니다.

좀 더 자세히 설명하자면 콘텐츠 작성자는 분기 전략을 사용하여 협업을 달성합니다. 분기 전략은 콘텐츠 작성자가 분기를 만들고, 사용하고, 병합하여 콘텐츠를 효과적으로 변경하고 관리하는 방법입니다. 개별 콘텐츠 작성자는 로컬 리포지토리에서 격리 상태로 작동합니다. 준비가 되면 원격 리포지토리에서 변경 내용을 단일 솔루션으로 결합합니다. 콘텐츠 작성자는 특정 개발, 개선 또는 버그 수정을 위한 작업 항목에 연결하여 작업 범위를 분기로 지정해야 합니다. 각 콘텐츠 작성자는 작업 범위에 대한 원격 리포지토리의 자체 분기를 만듭니다. 로컬 솔루션에서 수행된 작업은 커밋 메시지와 함께 원격 리포지토리의 분기 버전에 커밋되고 푸시됩니다. 커밋 메시지는 해당 커밋의 변경 내용을 설명합니다.

변경 내용을 병합하려면 콘텐츠 작성자가 끌어오기 요청을 엽니다. 끌어오기 요청은 수행된 작업을 단일 솔루션으로 병합할 수 있는 피어 검토를 위한 제출입니다. 병합하면 충돌이 발생할 수 있으며 이 문제는 분기를 병합하기 전에 해결해야 합니다. 끌어오기 요청 검토는 작성자가 개발, 품질, 규정 준수에 대한 조직의 표준 및 방법을 준수하도록 하는 데 중요합니다.

협업 권장 사항

콘텐츠 작성자가 어떻게 협업해야 하는지에 대한 구조화된 프로세스를 정의하는 것이 좋습니다. 다음을 확인합니다.

  • 작업 범위를 지정하는 방법 및 분기를 만들고 이름을 지정하고 사용하는 방법.
  • 작성자가 변경 내용을 그룹화하고 커밋 메시지로 설명하는 방법.
  • 끌어오기 요청 검토 및 승인 담당자.
  • 병합 충돌을 해결하는 방법.
  • 다른 분기에서 변경한 내용을 단일 분기로 병합하는 방법.
  • 콘텐츠를 테스트하는 방법과 콘텐츠가 배포되기 전에 테스트를 수행하는 담당자.
  • 변경 내용이 개발, 테스트, 프로덕션 작업 영역에 배포되는 방법 및 시기.
  • 배포된 변경 내용 또는 솔루션 버전을 롤백하는 방법과 시기.

Important

DevOps가 제공하는 가치는 그 사용을 정의하는 프로세스 준수 여부에 정비례합니다.

성공적인 협업은 잘 정의된 프로세스에 달려 있습니다. 엔드투엔드 개발 워크플로를 명확하게 설명하고 문서화하는 것이 중요합니다. 선택한 전략과 프로세스가 팀의 기존 방법과 일치하는지 확인하고, 그렇지 않은 경우 변경 관리 방법을 확인하세요. 또한 프로세스가 명확하고 모든 팀 멤버 및 관련자에게 전달되도록 합니다. 프로세스를 처음 접하는 팀 멤버와 관련자가 프로세스 채택 방법에 대한 교육을 받고 성공적인 DevOps 채택의 가치를 인식하도록 합니다.

Power BI REST API

Power BI REST API를 사용하여 Azure DevOps에서 콘텐츠를 가져오고 배포하는 프로그래밍 방식 논리를 개발합니다. 가져오기 작업을 사용하여 Power BI 파일(.pbix)을 작업 영역으로 가져옵니다. 파이프라인 작업을 통해 Power BI 배포 파이프라인을 사용하여 일부 콘텐츠 또는 모든 콘텐츠를 테스트 또는 프로덕션 작업 영역에 배포합니다. 프로그래밍 논리는 Azure Pipelines에 정의되어 있습니다.

파이프라인에서 Power BI REST API를 호출하려면 서비스 주체를 사용하는 것이 좋습니다. 서비스 주체는 자동화된 무인 작업을 위한 것이며 사용자 자격 증명에 의존하지 않습니다. 그러나 일부 항목 및 활동은 Power BI REST API에서 또는 데이터 흐름과 같은 서비스 주체를 사용할 때 지원되지 않습니다.

서비스 주체를 사용하는 경우 권한을 신중하게 관리해야 합니다. 목표는 최소 권한의 원칙을 따르는 것입니다. 권한을 오버프로비전하지 않고 서비스 주체에 대해 충분한 권한을 설정해야 합니다. Azure Key Vault 또는 서비스 주체 비밀과 자격 증명을 안전하게 저장하는 다른 서비스를 사용합니다.

주의

사람이 읽을 수 있는 메타데이터 형식으로 저장된 데이터 모델이 있는 경우 Power BI REST API를 사용하여 게시할 수 없습니다. 대신 XMLA 엔드포인트를 사용하여 게시해야 합니다. 테이블 형식 편집기 CLI(명령줄 인터페이스)와 같은 타사 도구를 사용하여 메타데이터 파일을 게시할 수 있습니다. 사용자 지정 .NET 개발을 사용하여 프로그래밍 방식으로 메타데이터 파일을 게시할 수도 있습니다. 사용자 지정 솔루션을 개발하려면 AMO(Analysis Management Object) 클라이언트 라이브러리의 Microsoft TOM(테이블 형식 개체 모델) 확장을 사용해야 하므로 더 많은 노력이 필요합니다.

Azure Pipelines

Azure Pipelines는 프로그래밍 방식으로 콘텐츠 테스트, 관리, 배포를 자동화합니다. 파이프라인이 실행되면 파이프라인의 단계가 자동으로 실행됩니다. 파이프라인 소유자는 배포 요구 사항에 맞게 트리거, 단계, 기능을 사용자 지정할 수 있습니다. 따라서 파이프라인의 수와 유형은 솔루션 요구 사항에 따라 달라집니다. 예를 들어 Azure Pipeline은 배포 전에 자동화된 테스트를 실행하거나 데이터 모델 매개 변수를 수정할 수 있습니다.

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

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

참고 항목

게시 솔루션에 이러한 세 가지 파이프라인을 모두 포함할 필요는 없습니다. 워크플로와 요구 사항에 따라 이 문서에 설명된 파이프라인 변형 중 하나 이상을 설정하여 콘텐츠 게시를 자동화할 수 있습니다. 파이프라인을 사용자 지정할 수 있는 기능은 기본 제공 Power BI 배포 파이프라인에 비해 Azure 파이프라인이 가진 장점입니다. 예를 들어 유효성 검사 파이프라인이 필요하지 않으며 빌드 및 릴리스 파이프라인만 사용할 수 있습니다.

유효성 검사 파이프라인

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

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

빌드 파이프라인

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

릴리스 파이프라인

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

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

테스트 및 릴리스 파이프라인을 사용하여 콘텐츠를 게시하는 방법에는 두 가지가 있습니다. Power BI 배포 파이프라인을 사용하여 콘텐츠를 승격하거나 Azure DevOps에서 Power BI 서비스에 콘텐츠를 게시합니다.

다음 다이어그램은 첫 번째 방법을 보여 줍니다. 이 방법에서 릴리스 파이프라인은 Power BI 배포 파이프라인을 사용하여 테스트 및 프로덕션 작업 영역에 콘텐츠 배포를 오케스트레이션합니다. 콘텐츠는 Power BI의 개발, 테스트, 프로덕션 작업 영역을 통해 승격됩니다. 이 방법은 더 강력하고 유지 관리가 더 간단하지만 프리미엄 라이선스가 필요합니다.

다이어그램은 위 단락에 설명된 대로 첫 번째 방법을 보여 줍니다. 다이어그램의 항목은 아래 표에 설명되어 있습니다.

다이어그램은 첫 번째 방법의 다음과 같은 사용자 작업, 프로세스, 기능을 보여 줍니다.

Item 설명
항목 1. 첫 번째 방법에서 릴리스 파이프라인은 Power BI 배포 파이프라인과 함께 XMLA 엔드포인트 및 Power BI REST API를 사용하여 콘텐츠를 게시합니다. 콘텐츠는 게시된 다음 개발, 테스트, 프로덕션 작업 영역을 통해 승격됩니다. Power BI 배포 파이프라인과 XMLA 읽기/쓰기 엔드포인트는 프리미엄 기능입니다.
항목 2. 성공적인 분기 병합 또는 업스트림 파이프라인 완료는 빌드 파이프라인을 트리거합니다. 그런 다음 빌드 파이프라인은 게시할 콘텐츠를 준비하고 개발 릴리스 파이프라인을 트리거합니다.
항목 3. 개발 릴리스 파이프라인은 XMLA 엔드포인트(데이터 모델 메타데이터용) 또는 Power BI REST API(데이터 모델 및 보고서를 포함할 수 있는 Power BI Desktop 파일용)를 사용하여 개발 작업 영역에 콘텐츠를 게시합니다. 개발 파이프라인은 테이블 형식 편집기 CLI(명령줄 인터페이스)를 사용하여 XMLA 엔트포인트를 통해 데이터 모델 메타데이터를 배포합니다.
항목 4. 릴리스 승인 또는 주문형 트리거는 테스트 릴리스 파이프라인을 활성화합니다.
항목 5. 테스트 릴리스 파이프라인은 Power BI 배포 파이프라인을 실행하는 Power BI REST API 배포 작업을 사용하여 콘텐츠를 배포합니다.
항목 6. Power BI 배포 파이프라인은 콘텐츠를 개발 작업 영역에서 테스트 작업 영역으로 승격합니다. 배포 후 릴리스 파이프라인은 Power BI REST API를 사용하여 배포 후 작업을 수행합니다(다이어그램에는 표시되지 않음).
항목 7. 릴리스 승인 또는 주문형 트리거는 프로덕션 릴리스 파이프라인을 활성화합니다.
항목 8. 프로덕션 릴리스 파이프라인은 Power BI 배포 파이프라인을 실행하는 Power BI REST API 배포 작업을 사용하여 콘텐츠를 배포합니다.
항목 9. Power BI 배포 파이프라인은 콘텐츠를 테스트 작업 영역에서 프로덕션 작업 영역으로 승격합니다. 배포 후 릴리스 파이프라인은 Power BI REST API를 사용하여 배포 후 작업을 수행합니다(다이어그램에는 표시되지 않음).

다음 다이어그램은 두 번째 방법을 보여 줍니다. 이 방법은 배포 파이프라인을 사용하지 않습니다. 대신 릴리스 파이프라인을 사용하여 Azure DevOps의 테스트 및 프로덕션 작업 영역에 콘텐츠를 게시합니다. 특히 이 두 번째 방법은 Power BI REST API를 사용하여 Power BI Desktop 파일만 게시하는 경우 프리미엄 라이선스가 필요하지 않습니다. Power BI 외부에서 배포를 관리해야 하므로 더 많은 설정 노력과 복잡성이 필요합니다. 이미 Power BI 외부의 데이터 솔루션에 DevOps를 사용하고 있는 개발 팀은 이 방법에 더 익숙할 수 있습니다. 이 방법을 사용하는 개발 팀은 Azure DevOps에서 데이터 솔루션 배포를 통합할 수 있습니다.

다이어그램은 위 단락에 설명된 대로 두 번째 방법을 보여 줍니다. 다이어그램의 항목은 아래 표에 설명되어 있습니다.

다이어그램은 두 번째 방법에서 다음과 같은 사용자 작업, 프로세스, 기능을 보여 줍니다.

Item 설명
항목 1. 두 번째 방법에서는 릴리스 파이프라인이 XMLA 엔드포인트와 Power BI REST API만 사용하여 콘텐츠를 게시합니다. 콘텐츠는 개발, 테스트, 프로덕션 작업 영역에 게시됩니다.
항목 2. 성공적인 분기 병합 또는 업스트림 파이프라인 완료는 빌드 파이프라인을 트리거합니다. 그런 다음 빌드 파이프라인은 게시할 콘텐츠를 준비하고 개발 릴리스 파이프라인을 트리거합니다.
항목 3. 개발 릴리스 파이프라인은 XMLA 엔드포인트(데이터 모델 메타데이터용) 또는 Power BI REST API(데이터 모델 및 보고서를 포함할 수 있는 Power BI Desktop 파일용)를 사용하여 개발 작업 영역에 콘텐츠를 게시합니다. 개발 파이프라인은 테이블 형식 편집기 CLI(명령줄 인터페이스)를 사용하여 XMLA 엔트포인트를 통해 데이터 모델 메타데이터를 배포합니다.
항목 4. 릴리스 승인 또는 주문형 트리거는 테스트 릴리스 파이프라인을 활성화합니다.
항목 5. 개발 릴리스 파이프라인은 XMLA 엔드포인트(데이터 모델 메타데이터용) 또는 Power BI REST API(데이터 모델 및 보고서를 포함할 수 있는 Power BI Desktop 파일용)를 사용하여 테스트 작업 영역에 콘텐츠를 게시합니다. 개발 파이프라인은 테이블 형식 편집기 CLI(명령줄 인터페이스)를 사용하여 XMLA 엔트포인트를 통해 데이터 모델 메타데이터를 배포합니다. 배포 후 릴리스 파이프라인은 Power BI REST API를 사용하여 배포 후 작업을 수행합니다(다이어그램에는 표시되지 않음).
항목 6. 릴리스 승인 또는 주문형 트리거는 프로덕션 릴리스 파이프라인을 활성화합니다.
항목 7. 개발 릴리스 파이프라인은 XMLA 엔드포인트(데이터 모델 메타데이터용) 또는 Power BI REST API(데이터 모델 및 보고서를 포함할 수 있는 Power BI Desktop 파일용)를 사용하여 프로덕션 작업 영역에 콘텐츠를 게시합니다. 개발 파이프라인은 테이블 형식 편집기 CLI(명령줄 인터페이스)를 사용하여 XMLA 엔트포인트를 통해 데이터 모델 메타데이터를 배포합니다. 배포 후 릴리스 파이프라인은 Power BI REST API를 사용하여 배포 후 작업을 수행합니다(다이어그램에는 표시되지 않음).

릴리스 파이프라인은 배포 후 작업을 관리해야 합니다. 이러한 작업에는 의미 체계 모델 자격 증명 설정 또는 테스트 및 프로덕션 작업 영역을 위한 Power BI 앱 업데이트가 포함될 수 있습니다. 관련 사용자에게 배포 작업에 대해 알리려면 알림을 설정하는 것이 좋습니다.

팁

버전 제어를 위해 리포지토리를 사용하면 콘텐츠 작성자가 롤백 프로세스를 만들 수 있습니다. 롤백 프로세스는 이전 버전을 복원하여 마지막 배포를 되돌릴 수 있습니다. 프로덕션 변경 내용을 롤백하기 위해 트리거할 수 있는 별도의 Azure Pipelines 세트를 만드는 것이 좋습니다. 롤백을 시작하려면 어떤 프로세스와 승인이 필요한지 신중하게 생각해 보세요. 이러한 프로세스를 문서화해야 합니다.

Power BI 배포 파이프라인

Power BI 배포 파이프라인은 개발, 테스트, 프로덕션의 세 단계로 구성됩니다. 배포 파이프라인의 각 단계에 단일 Power BI 작업 영역을 할당합니다. 배포가 발생하면 배포 파이프라인은 Power BI 항목을 한 작업 영역에서 다른 작업 영역으로 승격합니다.

Azure Pipelines 릴리스 파이프라인은 Power BI REST API를 통해 Power BI 배포 파이프라인을 사용하여 콘텐츠를 배포합니다. 배포를 수행하는 사용자에게는 작업 영역과 배포 파이프라인 모두에 대한 액세스가 필요합니다. 파이프라인 사용자가 배포 기록을 보고 콘텐츠를 비교할 수 있도록 배포 파이프라인 액세스를 계획하는 것이 좋습니다.

팁

데이터 작업 영역과 보고 작업 영역을 분리하는 경우 Azure 파이프라인을 사용하여 여러 Power BI 배포 파이프라인으로 콘텐츠 게시를 오케스트레이션하는 것을 고려하세요. 의미 체계 모델이 먼저 배포된 다음 새로 고쳐집니다. 마지막으로 보고서가 배포됩니다. 이 방법은 배포를 간소화하는 데 도움이 됩니다.

프리미엄 라이선싱

Power BI 배포 파이프라인과 XMLA 읽기/쓰기 엔드포인트는 프리미엄 기능입니다. 이러한 기능은 Power BI Premium 용량 및 Power BI PPU(사용자 단위 Premium)에서 사용할 수 있습니다.

PPU는 일반적으로 사용자 수가 적은 개발 및 테스트 작업 영역을 위한 엔터프라이즈 콘텐츠 게시를 관리하는 비용 효과적인 방법입니다. 이 방법은 프로덕션 워크로드에서 개발 및 테스트 워크로드를 격리하는 추가적인 이점이 있습니다.

참고 항목

릴리스 파이프라인 섹션의 두 번째 방법에 설명된 대로 프리미엄 라이선스가 없어도 엔터프라이즈 콘텐츠 게시를 설정할 수 있습니다. 두 번째 방법은 Azure Pipelines를 사용하여 개발, 테스트, 프로덕션 작업 영역에 대한 Power BI Desktop 파일 배포를 관리합니다. 그러나 Power BI REST API를 사용하여 메타데이터 형식 의미 체계 모델을 게시할 수 없으므로 XMLA 엔드포인트를 사용하여 모델 메타데이터를 배포할 수 없습니다. 또한 프리미엄 라이선스가 없는 배포 파이프라인이 있는 환경을 통해 콘텐츠를 승격할 수 없습니다.

게이트웨이 설정

일반적으로 프라이빗 조직 네트워크 또는 가상 네트워크 내에 있는 데이터 원본에 액세스할 경우 데이터 게이트웨이가 필요합니다. 게이트웨이의 두 가지 목적은 가져온 데이터를 새로 고치고 실시간 연결 또는 DirectQuery 의미 체계 모델을 쿼리하는 보고서를 보는 것입니다(시나리오 다이어그램에 표시되지 않음).

여러 환경에서 작업하는 경우 다양한 원본 시스템에 대한 개발, 테스트, 프로덕션 연결을 설정하는 것이 일반적입니다. 이 경우 데이터 원본 규칙 및 매개 변수 규칙을 사용하여 환경 간에 다른 값을 관리합니다. Azure Pipelines를 사용하면 Power BI REST API의 게이트웨이 작업을 통해 게이트웨이를 관리할 수 있습니다.

참고 항목

표준 모드의 중앙 집중식 데이터 게이트웨이는 개인 모드의 게이트웨이보다 강력하게 권장됩니다. 표준 모드에서 데이터 게이트웨이는 라이브 연결 및 DirectQuery 작업(예약된 데이터 새로 고침 작업 외에도)을 지원합니다.

시스템 감독

활동 로그는 Power BI 서비스에서 발생하는 이벤트를 기록합니다. Power BI 관리자는 활동 로그를 사용하여 배포 작업을 감사할 수 있습니다.

Power BI 메타데이터 검사 API를 사용하여 테넌트 인벤토리를 만들 수 있습니다. API 결과는 각 작업 영역에 배포된 항목을 확인하고, 계보를 확인하고, 보안 설정을 검증하는 데 도움이 됩니다.

Power BI 서비스 외부에 있는 Azure DevOps 내에 감사 로그도 있습니다. Azure DevOps 관리자는 감사 로그를 사용하여 원격 리포지토리 및 파이프라인의 작업을 검토할 수 있습니다.

관련 콘텐츠

Power BI 구현 결정에 도움이 되는 다른 유용한 시나리오는 Power BI 사용 시나리오 문서를 참조하세요.