Power BI 구현 계획: 콘텐츠 개발 및 변경 콘텐츠 관리

참고 항목

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

이 문서는 콘텐츠 수명 주기 관리의 일환으로 콘텐츠를 개발하고 변경 콘텐츠를 관리하는 데 도움이 됩니다. 주로 다음을 대상으로 합니다.

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

수명 주기 관리는 콘텐츠 만들기부터 최종 사용 중지까지 콘텐츠를 처리하는 데 사용하는 프로세스 및 방식입니다. 수명 주기 관리의 첫 번째 단계에서는 솔루션 계획과 수명 주기 관리 방식에 영향을 미치는 주요 결정을 포함하는 콘텐츠를 계획하고 설계합니다. 두 번째 단계에서는 콘텐츠를 개발하고 변경 콘텐츠를 관리합니다.

콘텐츠 작성자 간의 효과적인 협업과 소비자에게 콘텐츠의 안정적이고 일관적인 배달을 보장하려면 수명 주기 동안 콘텐츠 변경을 관리해야 합니다.

다음 이미지는 콘텐츠를 개발하고 변경 콘텐츠를 관리하는 2단계를 강조 표시하면서 Power BI 콘텐츠의 수명 주기를 보여 줍니다.

참고 항목

콘텐츠 수명 주기 관리에 대한 개요는 이 시리즈의 첫 번째 문서를 참조하세요.

팁

이 문서에서는 콘텐츠를 개발하고 수명 주기 전반에 걸쳐 변경 콘텐츠를 관리하는 데 도움이 되는 주요 결정 및 고려 사항에 중점을 둡니다. 콘텐츠를 개발하고 변경 콘텐츠를 관리하는 방법에 대한 자세한 지침은 다음을 참조하세요.

• Microsoft Fabric의 수명 주기 관리란?: 이 문서에서는 Fabric Git 통합 및 배포 파이프라인에 대한 기술 소개와 자습서를 제공합니다.
• 수명 주기 관리 모범 사례: 이 문서에는 Fabric 및 Power BI의 수명 주기 관리 기능을 사용하여 콘텐츠를 개발하고 변경 콘텐츠를 관리하는 데 대한 실용적인 팁과 지침이 포함되어 있습니다.
• Power BI Desktop OneDrive 및 SharePoint 통합: 이 문서에는 .pbix 파일로 버전 제어를 수행할 때 회사 및 학교용 OneDrive 또는 SharePoint에 저장된 파일을 사용하고 저장하는 옵션에 대한 개요가 포함되어 있습니다.
• Azure Repos에서 Git 시작: 이 문서 시리즈에는 Azure Repos에서 Git 리포지토리를 사용하여 소스 제어를 수행하기 위한 실용적인 팁, 자습서 및 지침이 포함되어 있습니다.

콘텐츠 작성자와 소유자는 버전 제어를 사용하여 콘텐츠 변경 콘텐츠를 관리해야 합니다. 버전 제어는 중앙 리포지토리에 있는 파일이나 코드의 변경 내용을 관리하는 방법입니다. 이 방법을 사용하면 보다 효과적인 협업과 콘텐츠 관리가 가능해집니다.

버전 제어의 다른 이점은 다음과 같습니다.

• 여러 콘텐츠 작성자의 변경 콘텐츠를 병합하고 병합 충돌을 처리합니다.
• 변경된 콘텐츠와 해당 콘텐츠에서 변경된 콘텐츠를 식별합니다.
• 콘텐츠 변경 사항을 특정 작업 항목에 연결합니다.
• 버전 기록을 통해 변경 내용을 별도의 릴리스로 그룹화합니다.
• 콘텐츠의 변경 콘텐츠이나 전체 버전을 롤백합니다.

팁

가능하다면 만드는 모든 콘텐츠에 대해 버전 제어를 사용하는 것이 좋습니다. 버전 제어를 사용하면 콘텐츠 작성자와 소비자 모두에게 상당한 이점이 있으며 파일 손실이나 변경 콘텐츠 롤백 불가로 인한 중단 위험을 줄일 수 있습니다.

버전 제어를 설정하는 첫 번째 단계는 콘텐츠 개발 방법을 결정하는 것입니다.

콘텐츠 개발 방법 결정

콘텐츠를 작성하는 방법에 따라 콘텐츠 관리 방법에 대한 결정이 달라집니다. 예를 들어, Power BI 보고서 및 의미 체계 모델의 경우 Power BI Desktop(.pbix) 파일은 Power BI Desktop 프로젝트(.pbip) 형식에 비해 버전 제어 옵션이 더 적습니다. .pbix 파일은 이진 형식인 반면 .pbip 형식에는 인간이 읽을 수 있는 텍스트 기반 콘텐츠와 메타데이터가 포함되어 있기 때문입니다. 인간이 읽을 수 있는 콘텐츠와 메타데이터가 있으면 소스 제어를 사용하여 모델을 더 쉽게 추적하고 변경 콘텐츠를 보고할 수 있습니다. 소스 제어는 콘텐츠 내 코드 및 메타데이터에 대한 변경 콘텐츠를 보고 관리하는 것입니다.

팁

Power BI Desktop을 사용하여 의미 체계 모델 및 보고서를 개발하는 경우 .pbix 파일 대신 .pbip 파일을 사용하는 것이 좋습니다. XMLA 도구를 사용하여 의미 체계 모델을 개발할 때 .bim 파일 대신 TMDL(Tabular Model Definition Language) 형식을 사용하는 것이 좋습니다.

.pbip 및 TMDL 형식은 개체 수준 변경 내용을 더 쉽게 추적하고 병합할 수 있도록 지원합니다. 즉, DAX 측정값이나 테이블과 같은 개별 개체에 대한 변경 내용을 보고 관리할 수 있습니다.

Power BI Desktop

Power BI Desktop을 사용하여 .pbix 또는 .pbip 파일로 저장할 수 있는 의미 체계 모델 또는 보고서를 만들 수 있습니다. Power BI Desktop을 사용할 때 사용할 수도 있는 추가 사용자 지정 콘텐츠 파일이 있습니다. Power BI Desktop을 사용하여 콘텐츠를 만들 때 내려야 할 몇 가지 주요 결정은 다음과 같습니다.

• 사용할 파일 형식: 콘텐츠를 .pbix 또는 .pbip 파일로 저장할 수 있습니다. 예를 들어, Git 통합을 위해서는 .pbip 파일을 사용해야 하며, 셀프 서비스 작성자는 Teams, SharePoint 또는 OneDrive에서 .pbix 파일을 더 쉽게 관리하고 유지 관리할 수 있습니다.
• 사용자 지정 콘텐츠 관리 방법: Power BI Desktop 파일에 테마, 사용자 지정 시각적 개체 또는 이미지를 추가할 수 있으며, 이를 위해서는 수명 주기 관리에 대해 별도의 고려 사항이 필요할 수 있습니다. 예를 들어, 콘텐츠 작성자가 자신만의 사용자 지정 시각적 개체를 만들 때 시각적 정의를 별도의 파일에 저장하고 관리해야 합니다.
• 미리 보기 기능 관리 방법: Power BI Desktop에서 콘텐츠와 사용 방법을 변경하는 기능이나 설정을 미리 보기하도록 옵트인할 수 있습니다. 예를 들어, 미리 보기 기능을 사용하는 콘텐츠의 유효성을 검사하기 위해 추가 단계를 수행할 수 있습니다.

웹 작성

데이터 흐름, 대시보드, 성과 기록표와 같은 특정 콘텐츠는 Fabric 포털에서만 만들 수 있습니다. 또한 Fabric 포털이나 로컬 도구를 사용하여 의미 체계 모델, 보고서, 페이지를 매긴 보고서 등 일부 콘텐츠를 만들거나 수정할 수도 있습니다. 웹 작성을 사용하여 콘텐츠를 만들 때 내려야 할 몇 가지 주요 결정은 다음과 같습니다.

• 변경 내용 관리 방법: 웹 작성을 사용하여 다양한 항목 종류를 변경할 수 있지만 이러한 변경 내용은 즉시 저장되어 이전 버전을 덮어쓸 수 있습니다. 예를 들어, 다른 사람과 협업하는 경우 공유 항목에 대한 웹 작성을 피하고 대신 고유의 복사본에서 작업할 수 있습니다.
• 콘텐츠 백업을 검색하는 방법: 웹 작성을 사용하여 보고서나 의미 체계 모델과 같은 콘텐츠를 만들 수 있지만 이러한 항목은 로컬 .pbix 파일에 다운로드할 수 없습니다. 예를 들어, 메타데이터를 검색하고 저장하여 이 콘텐츠를 백업하도록 선택할 수 있습니다.

팁

데이터 흐름 및 성과 기록표를 개발할 때 항목 정의를 검색하여 변경 내용을 관리하고 백업을 저장하는 것이 좋습니다. Fabric REST API를 사용하여 데이터 흐름 및 성과 기록표 검색을 자동화할 수 있습니다. 특히 데이터 흐름 가져오기 및 성과 기록표 가져오기 엔드포인트를 각각 사용할 수 있습니다.

주의

대시보드와 같은 일부 콘텐츠에는 정의를 검색하는 옵션이 없습니다. 이 콘텐츠의 경우 변경 콘텐츠를 쉽게 추적하거나 백업을 검색할 수 없습니다.

기타 도구

다른 도구를 사용하여 특정 형식의 콘텐츠를 만들거나 관리할 수 있습니다. 이러한 도구는 추가적인 이점을 제공하거나 워크플로에 더 적합하거나 특정 기능이나 콘텐츠 형식을 관리하는 데 필요할 수 있습니다. 다른 Microsoft 도구나 타사 도구를 모두 사용하여 콘텐츠를 만들고 관리할 수 있습니다. 콘텐츠를 만들거나 관리하는 데 사용할 수 있는 다른 도구는 다음과 같습니다.

• Visual Studio 또는 Visual Studio Code: 개발자가 의미 체계 모델 또는 Fabric Notebook을 만들고 관리할 수 있는 통합 개발 환경입니다. 개발자는 Visual Studio와 Visual Studio Code를 모두 사용하여 로컬 변경 내용을 원격 리포지토리에 커밋하고 푸시하여 SCM(소스 제어 관리)을 수행할 수도 있습니다.
• 테이블 형식 편집기: 의미 체계 모델을 개발하고 관리하기 위한 타사 도구입니다.
• Excel: 의미 체계 모델과 함께 작동하는 피벗 테이블 및 실시간 연결 테이블용 클라이언트 도구입니다.
• Power BI Report Builder: 페이지를 매긴 보고서(.rdl) 파일을 만들기 위한 데스크톱 애플리케이션입니다.

다른 도구를 사용하여 콘텐츠를 만들 때 내려야 할 몇 가지 주요 결정은 다음과 같습니다.

• 라이선스 관리 방법: 다른 도구에는 관리해야 하는 추가 라이선스가 필요할 수 있습니다.
• 콘텐츠 게시 방법: 콘텐츠를 게시하려면 XMLA 엔드포인트 또는 Power BI REST API를 사용하는 등의 추가 단계가 필요한 다른 도구도 있습니다.

콘텐츠 만들기 방법을 결정한 후에는 콘텐츠를 개발하는 동안 콘텐츠를 게시하고 테스트할 위치를 선택해야 합니다.

작업 영역을 설정하고 사용하는 방법 결정

콘텐츠를 개발할 때 여러 작업 영역(또는 단계)을 사용하여 조직에서 사용하는 프로덕션 콘텐츠를 개발 또는 유효성 검사 중인 콘텐츠와 분리해야 합니다. 콘텐츠에 대해 별도의 작업 영역을 사용하면 다음과 같은 몇 가지 이점이 있습니다.

• 현재 사용 중인 콘텐츠에 영향을 주지 않고 콘텐츠를 개발하고 테스트할 수 있습니다. 이렇게 하면 프로덕션 콘텐츠에 의도하지 않은 중단을 일으킬 수 있는 변경을 방지할 수 있습니다.
• 별도의 데이터 게이트웨이 또는 Fabric 용량을 사용하는 등 콘텐츠 개발 및 테스트를 위해 별도의 리소스를 사용할 수 있습니다. 이렇게 하면 개발 및 테스트에 사용되는 리소스로 인해 프로덕션 워크로드가 중단되어 데이터 새로 고침이나 보고서가 느려지는 것을 방지할 수 있습니다.
• 각 단계에 대해 별도의 환경을 가짐으로써 콘텐츠를 개발, 테스트 및 릴리스하는 보다 구조화된 프로세스를 만들 수 있습니다. 이는 생산성을 개선하는 데 도움이 됩니다.

Fabric 및 Power BI에서는 테넌트 수준 및 작업 영역 수준 계획 문서에 설명된 대로 별도의 Fabric 작업 영역을 사용하는 것이 좋습니다.

Important

별도의 환경을 사용하는 것은 콘텐츠 수명 주기 관리 방식의 성공을 보장하는 필수 단계입니다.

Fabric 작업 영역을 사용하여 환경을 분리하는 방법에는 여러 가지가 있습니다. 일반적으로 로컬 환경 외에도 두 개 이상의 작업 영역을 사용하여 수명 주기 동안 콘텐츠를 관리합니다.

이 콘텐츠의 수명 주기 전반에 걸쳐 별도의 작업 영역을 사용할 방법을 계획할 때 다음 질문에 답합니다.

• 얼마나 많은 작업 영역이 필요하나요?
• 항목 종류별로 작업 영역을 분리하려고 하나요?
• 각 작업 영역에는 누가 액세스할 수 있나요?
• 작업 영역은 Fabric 배포 파이프라인에 속하나요, 아니면 Azure Pipelines 사용과 같은 다른 방식을 사용하여 배포를 오케스트레이션하나요?
• 교차 작업 영역 게시를 어떻게 관리하려고 하나요? 예를 들어, 보고서용 테스트 작업 영역의 보고서가 데이터 항목용 별도 테스트 작업 영역의 의미 체계 모델에 연결되는지 확인해야 하나요?
• 별도의 온-프레미스 데이터 게이트웨이 클러스터와 같이 프로덕션 작업 영역의 항목에 대해 별도의 지원 리소스도 사용해야 하나요?

다음 섹션에서는 수명 주기 관리를 용이하게 하기 위해 별도의 작업 영역에 취할 수 있는 다양한 방식에 대한 개략적인 개요를 제공합니다.

참고 항목

다음 섹션에서는 별도의 작업 영역을 설정하고 사용하는 방법에 중점을 둡니다. 다음 네 가지 방식 중 하나를 사용하여 이러한 작업 영역에 콘텐츠를 배포할 수 있습니다.

• Power BI Desktop에서 게시.
• Fabric 배포 파이프라인을 사용하여 다른 작업 영역에서 콘텐츠 배포.
• Git 통합을 사용하여 원격 Git 리포지토리의 콘텐츠 동기화.
• Fabric REST API, Power BI REST API 또는 XMLA 엔드포인트를 사용하여 프로그래밍 방식으로 콘텐츠 배포.

콘텐츠 배포를 위한 이러한 방식에 대한 자세한 내용은 이 시리즈 뒷부분의 4단계: 콘텐츠 배포를 참조하세요.

테스트 및 프로덕션 작업 영역

조직에 중요하지 않은 단순한 콘텐츠를 제공하는 경우 작업 영역 두 개로 충분할 수 있는 경우가 많습니다. 이 시나리오에서 콘텐츠 작성자는 일반적으로 동일한 항목에 대해 제한된 협업을 수행하고 로컬에서 콘텐츠를 개발합니다.

다음 다이어그램은 테스트 및 프로덕션 작업 영역만 있는 별도의 환경을 사용하는 방법에 대한 개략적인 예를 보여 줍니다.

다이어그램은 이 방식에서 작업 영역을 분리하기 위한 다음 프로세스와 구성 요소를 보여 줍니다.

항목	설명
	콘텐츠 작성자는 로컬 환경에서 콘텐츠를 개발합니다.
	준비가 되면 콘텐츠 작성자는 테스트 작업 영역에 콘텐츠를 게시합니다. 콘텐츠 작성자는 웹 생성을 통해서만 제작할 수 있는 콘텐츠를 개발하고 테스트 작업 영역에서 콘텐츠 유효성 검사를 수행할 수 있습니다.
	준비가 되면 콘텐츠 작성자는 프로덕션 작업 영역에 콘텐츠를 배포합니다. 프로덕션 작업 영역에서 콘텐츠 작성자는 Power BI 앱을 게시하거나 작업 영역에서 콘텐츠를 공유하여 콘텐츠를 배포합니다.

참고 항목

별도의 작업 영역을 설정 및 사용하고 이러한 작업 영역 간에 콘텐츠를 배포하는 방법에는 여러 가지가 있습니다. 그러나 로컬 개발을 수행하지 않고 콘텐츠를 프로덕션 작업 영역에 직접 게시하는 것이 좋습니다. 이로 인해 예방 가능한 중단과 오류가 발생할 수 있습니다.

개발, 테스트 및 프로덕션 작업 영역

비즈니스에 중요한 콘텐츠를 제공할 때 일반적으로 3개 이상의 별도 작업 영역을 사용합니다. 이 시나리오에서 콘텐츠 작성자는 최신 버전의 솔루션이 포함된 추가 개발 작업 영역에서 협업하는 경우가 많습니다.

다음 다이어그램은 개발, 테스트 및 프로덕션 작업 영역이 포함된 별도의 환경을 사용하는 방법에 대한 개략적인 예를 보여 줍니다.

다이어그램은 이 방식에서 작업 영역을 분리하기 위한 다음 프로세스와 구성 요소를 보여 줍니다.

항목	설명
	콘텐츠 작성자는 로컬 환경에서 콘텐츠를 개발합니다.
	준비가 되면 콘텐츠 작성자는 개발 작업 영역에 콘텐츠를 게시합니다. 개발 작업 영역에서는 콘텐츠 작성자가 웹 작성을 통해서만 제작할 수 있는 콘텐츠를 개발할 수 있습니다. 콘텐츠 작성자는 개발 작업 영역에서 콘텐츠의 유효성을 검사할 수도 있습니다.
	준비가 되면 콘텐츠 작성자는 테스트 작업 영역에 콘텐츠를 배포합니다. 테스트 작업 영역에서 사용자는 작업 영역이나 앱에서 콘텐츠의 유효성을 검사합니다.
	준비가 되면 콘텐츠 작성자는 프로덕션 작업 영역에 콘텐츠를 배포합니다. 프로덕션 작업 영역에서 콘텐츠 작성자는 Power BI 앱을 게시하거나 작업 영역에서 콘텐츠를 공유하여 콘텐츠를 배포합니다.

참고 항목

배포 파이프라인을 통해 최대 10개의 서로 다른 환경을 사용할 수 있습니다. 예를 들어, 성능 테스트와 같은 특별한 형식의 유효성 검사를 위해 특별히 테스트와 프로덕션 사이에 사전 프로덕션 환경을 갖고 싶을 수 있습니다.

Git 통합을 갖춘 프라이빗 작업 영역

비즈니스에 중요한 콘텐츠를 제공할 때 각 개발자는 자신만의 개발용 프라이빗 작업 영역을 사용할 수도 있습니다. 이 시나리오에서는 프라이빗 작업 영역을 통해 콘텐츠 작성자가 Fabric 포털에서 콘텐츠를 테스트하거나 개발팀의 다른 사람들에게 중단을 주지 않고 예약된 새로 고침과 같은 기능을 사용할 수 있습니다. 콘텐츠 작성자는 여기의 Fabric 포털에서 데이터 흐름과 같은 콘텐츠를 개발할 수도 있습니다. Azure DevOps와 함께 Git 통합을 사용하여 콘텐츠 변경 콘텐츠를 관리할 때 프라이빗 작업 영역을 선택하는 것이 좋습니다.

참고 항목

Azure DevOps는 Power BI 및 Fabric과 통합되어 콘텐츠 수명 주기 관리를 계획하고 오케스트레이션하는 데 도움이 되는 서비스 도구 모음입니다. 이러한 방식으로 Azure DevOps를 사용하는 경우 일반적으로 다음 서비스를 활용합니다.

• Azure Repos: 콘텐츠 변경 콘텐츠를 추적하고 관리하는 데 사용하는 원격 스토리지 위치인 원격 Git 리포지토리를 만들고 사용할 수 있습니다.
• Azure Pipelines: 원격 리포지토리의 콘텐츠를 작업 영역으로 처리, 테스트 및 배포하는 자동화된 작업 집합을 만들고 사용할 수 있습니다.
• Azure Test Plans: Azure Pipelines와 함께 솔루션의 유효성을 검사하고 품질 제어를 자동화하는 테스트를 설계할 수 있습니다.
• Azure Boards: Boards를 사용하여 작업 및 계획을 작업 항목으로 추적하고 다른 Azure DevOps 서비스의 작업 항목을 연결하거나 참조할 수 있습니다.
• Azure Wiki: 팀과 정보를 공유하여 콘텐츠를 이해하고 기여할 수 있습니다.

다음 다이어그램은 Git 통합과 함께 프라이빗 작업 영역을 사용하여 별도의 환경을 사용할 수 있는 방법에 대한 개략적인 예를 보여 줍니다.

참고 항목

이 다이어그램은 변경 내용을 기본 분기에 병합하기 전에 별도의 솔루션 분기(분기 1과 분기 2)에서 작업하는 별도의 개발자를 보여 줍니다. 이는 개발자가 변경 내용을 원격 Git 리포지토리와 통합하고 Fabric에서 Git 통합을 통해 이점을 얻을 수 있는 방법을 보여 주기 위해 Git 분기 전략을 간략하게 설명합니다.

다이어그램은 이 방식에서 작업 영역을 분리하기 위한 다음 프로세스와 구성 요소를 보여 줍니다.

항목	설명
	각 콘텐츠 작성자는 자신의 로컬 환경에서 콘텐츠를 개발합니다.
	준비가 되면 콘텐츠 작성자는 Azure Repos Git 리포지토리와 같은 원격 리포지토리에 변경 콘텐츠를 커밋하고 푸시합니다.
	원격 Git 리포지토리에서 콘텐츠 작성자는 소스 제어를 사용하여 콘텐츠 변경 콘텐츠를 추적 및 관리하고 콘텐츠를 분기 및 병합하여 협업을 지원합니다.
	콘텐츠 작성자는 원격 리포지토리의 분기를 프라이빗 작업 영역과 동기화합니다. 동기화 후 작성자가 커밋하고 분기에 푸시한 최신 변경 내용이 해당 프라이빗 작업 영역에 표시됩니다. 다양한 콘텐츠 작성자가 변경 콘텐츠를 적용할 때 자체적으로 별도의 분기로 작업합니다.
	프라이빗 작업 영역에서 콘텐츠 작성자는 웹 작성을 사용하여 콘텐츠를 개발하고 자신의 변경 콘텐츠의 유효성을 검사할 수 있습니다. 웹 작성을 통해 변경된 콘텐츠는 콘텐츠 작성자가 작업 영역에서 이러한 변경 콘텐츠를 커밋하고 푸시할 때 Git 리포지토리의 분기와 동기화될 수 있습니다. 다양한 콘텐츠 작성자가 자신만의 별도의 프라이빗 작업 영역에서 작업합니다.
	준비가 되면 콘텐츠 작성자는 끌어오기 요청을 수행하여 변경 콘텐츠를 솔루션의 기본 분기에 병합합니다.
	변경 내용을 병합한 후 기본 분기는 개발 작업 영역과 동기화됩니다.
	개발 작업 영역에서 콘텐츠 작성자는 대시보드와 같이 Fabric Git 통합에서 지원되지 않는 콘텐츠를 개발할 수 있습니다. 콘텐츠 작성자는 최신 변경 콘텐츠가 모두 포함된 통합 솔루션도 유효성 검사합니다.
	준비가 되면 콘텐츠 작성자는 테스트 작업 영역에 콘텐츠를 배포합니다. 테스트 작업 영역에서 사용자는 콘텐츠에 대한 사용자 승인 테스트를 수행합니다.
	준비가 되면 콘텐츠 작성자는 프로덕션 작업 영역에 콘텐츠를 배포합니다. 프로덕션 작업 영역에서 콘텐츠 작성자는 Power BI 앱을 게시하거나 작업 영역에서 콘텐츠를 공유하여 콘텐츠를 배포합니다.

작업 영역을 위한 지원 리소스

별도의 환경을 사용하는 경우 이러한 환경에서 사용하는 다양한 지원 리소스에 어떤 영향을 미칠지 고려해야 합니다. 이러한 지원 리소스의 경우 동일한 수의 단계로 분리해야 하는지 또는 이러한 환경에서 사용을 조정하는 방법도 고려합니다.

• 게이트웨이: 프로덕션 워크로드에 대해 별도의 온-프레미스 데이터 게이트웨이 클러스터 및 VNet 게이트웨이 사용을 고려합니다. 이는 중단을 방지하는 동시에 게이트웨이를 업데이트해야 할 때 작동 시간을 보장하는 데도 도움이 됩니다.
• 앱: 테스트 및 프로덕션 작업 영역용으로 별도의 앱을 사용하는 것이 좋습니다. 단계 간에 앱을 배포하거나 복사할 수 없습니다. 테스트 작업 영역의 앱은 프로덕션 작업 영역에 변경 콘텐츠를 배포하기 전에 콘텐츠와 앱 환경을 테스트하는 데 도움을 주기 위한 것입니다. 프로덕션 작업 영역의 앱은 구조화된 환경으로 최종 사용자에게 콘텐츠를 제공하기 위한 것입니다.
• Azure DevOps: Azure DevOps를 사용하여 소스 제어 및 배포를 협업하고 오케스트레이션하려는 경우 분기 및 Azure Pipelines를 사용하여 이러한 환경 간에 콘텐츠를 배포하는 방법을 고려합니다. Azure Pipelines를 사용하여 콘텐츠를 배포하는 방법에 대한 자세한 내용은 4단계: 콘텐츠 배포를 참조하세요.

작업 영역을 설정하고 사용하는 방법을 결정한 후 다음 단계는 콘텐츠 변경 콘텐츠를 추적하고 관리하기 위해 버전 제어를 수행하는 방법을 결정하는 것입니다.

버전 제어 사용 방법 결정

Power BI에서는 SharePoint/OneDrive를 사용하거나 Azure DevOps의 구성 요소인 Azure Repos와 같은 원격 Git 리포지토리를 사용하여 버전 제어를 수행할 수 있습니다. 두 방식 모두 로컬 콘텐츠 파일을 원격 스토리지 위치에 추가하여 변경 콘텐츠를 추적하고 관리하는 데 도움이 됩니다. 더 크고 복잡한 시나리오를 지원하는 기능과 견고성이 부족하기 때문에 더 작고 단순한 프로젝트에만 SharePoint 또는 OneDrive를 사용하는 것이 좋습니다.

버전 제어를 설정하고 사용하는 데 도움이 되는 몇 가지 일반적인 고려 사항은 다음과 같습니다.

• 경고: 다른 사람이 중요한 파일을 추가, 제거 또는 수정할 때 경고를 설정해야 합니다.
• 범위: 원격 스토리지 위치의 범위를 명확하게 정의합니다. 이상적으로 원격 스토리지 위치의 범위는 소비자에게 콘텐츠를 배달하는 데 사용하는 다운스트림 작업 영역 및 앱의 범위와 동일합니다.
• 액세스: 배포 파이프라인 권한 및 작업 영역 역할에 대해 설정한 것과 유사한 권한 모델을 사용하여 원격 스토리지 위치에 대한 액세스를 설정해야 합니다. 콘텐츠 작성자는 원격 스토리지 위치에 액세스해야 합니다.
• 설명서: 원격 스토리지 위치와 해당 목적, 소유권, 액세스 및 정의 프로세스를 설명하는 텍스트 파일을 원격 스토리지 위치에 추가합니다.

다음 섹션에서는 각 방식과 사용해야 할 방식을 결정하기 위한 주요 고려 사항을 설명합니다.

SharePoint 또는 회사 및 학교용 OneDrive를 사용하여 버전 제어

SharePoint에는 파일에 대한 버전 제어 기능이 기본 제공되어 있습니다. 콘텐츠 작성자는 로컬에서 의미 체계 모델이나 보고서를 개발할 수 있으며 해당 변경 콘텐츠는 SharePoint 또는 회사 및 학교용 OneDrive 문서 라이브러리에 동기화됩니다.

팁

셀프 서비스 콘텐츠 게시와 같이 더 간단하고 소규모의 시나리오에서는 버전 제어용으로만 SharePoint 또는 OneDrive를 사용합니다. 더 크거나 복잡한 시나리오의 경우 원격 Git 리포지토리를 사용하여 소스 제어를 수행하는 것을 고려해야 합니다.

다음 다이어그램은 SharePoint 또는 OneDrive를 사용하여 버전 제어를 수행하는 방법에 대한 개략적인 개요를 보여 줍니다.

다이어그램은 다음 프로세스와 구성 요소를 설명합니다.

항목	설명
	콘텐츠 작성자는 로컬 환경에서 의미 체계 모델과 보고서를 개발하고 이러한 모델과 보고서를 .pbix 파일로 저장합니다.
	준비가 되면 콘텐츠 작성자는 변경 콘텐츠를 저장하고 이를 원격 SharePoint 또는 회사 및 학교용 OneDrive 라이브러리에 동기화합니다.
	원격 라이브러리에서 콘텐츠 작성자는 파일 수준 변경 콘텐츠를 추적하여 버전 제어를 용이하게 합니다.
	콘텐츠 작성자는 게시된 의미 체계 모델을 연결하거나 .pbix 파일에 보고서를 연결하여 OneDrive 새로 고침을 용이하게 할 수 있습니다. OneDrive 새로 고침은 매시간 콘텐츠 변경 콘텐츠를 자동으로 게시합니다.
	Fabric 작업 영역에서 콘텐츠 작성자는 OneDrive 새로 고침이 완료된 후 Power BI 콘텐츠의 변경 콘텐츠를 확인합니다.

Important

의미 체계 모델 또는 보고서가 포함된 Power BI Desktop 파일용 SharePoint 또는 OneDrive를 사용해야만 버전 제어를 수행할 수 있습니다. 데이터 흐름과 같은 다른 Power BI 항목 종류나 Notebook과 같은 Fabric 항목 종류에 대해 SharePoint 또는 OneDrive를 사용하면 버전 제어를 쉽게 수행할 수 없습니다. 이러한 다른 항목 종류의 경우 Azure Repos와 같은 원격 Git 리포지토리를 사용하여 버전 제어를 수행해야 합니다.

요약하자면, 콘텐츠 작성자는 게시된 의미 체계 모델을 연결하거나 SharePoint 또는 회사 및 학교용 OneDrive 라이브러리에 저장된 .pbix 파일에 보고할 수 있습니다. 이 방식을 사용하면 콘텐츠 작성자는 더 이상 변경 콘텐츠를 확인하기 위해 의미 체계 모델을 게시할 필요가 없습니다. 대신 매시간 발생하는 자동 OneDrive 새로 고침 후에 변경 내용이 표시됩니다. 이 방식은 편리하기는 하지만 몇 가지 고려 사항이 따르며 쉽게 되돌릴 수 없습니다.

설정 및 관리는 쉽지만 SharePoint 또는 OneDrive를 사용한 버전 제어에는 더 많은 제한 사항이 있습니다. 예를 들어, 콘텐츠 내 변경 콘텐츠를 볼 수 없으며 버전을 비교할 수도 없습니다. 또한 이러한 변경 내용(예: 분기 또는 끌어오기 요청, 이 문서 뒷부분에서 설명)을 관리하기 위해 보다 정교한 프로세스를 설정하는 것도 불가능합니다.

다음 시나리오에서는 SharePoint 또는 OneDrive를 사용하여 변경 내용을 추적하고 관리하는 것이 좋습니다.

• 콘텐츠는 .pbix 파일로 저장된 의미 체계 모델 또는 보고서로만 구성됩니다.
• 셀프 서비스 사용자는 콘텐츠를 만들고 관리합니다.
• 콘텐츠 작성자는 Microsoft Teams를 사용하여 협업합니다.
• 콘텐츠 작성자는 Git 및 소스 제어 관리 환경이 없습니다.
• 콘텐츠 작성자는 복잡성과 협업이 제한된 단일 항목을 관리합니다.
• .pbix 파일에는 콘텐츠를 암호화하는 민감도 레이블이 적용되어 있습니다.

참고 항목

OneDrive 및 SharePoint는 일부 제한된 시나리오를 제외하고 민감도 레이블이 적용된 콘텐츠를 지원합니다. 반면 Fabric Git 통합은 민감도 레이블을 지원하지 않습니다.

다음 시나리오에서는 변경 내용을 추적하고 관리하기 위해 SharePoint 또는 OneDrive를 사용하지 마세요.

• 콘텐츠는 의미 체계 모델 및 보고서 이외의 항목 종류로 구성됩니다.
• 콘텐츠가 복잡하거나 범위가 넓습니다.
• 콘텐츠 작성자는 동일한 항목에 대해 동시에 공동으로 작업해야 합니다.

다음 섹션에서는 Power BI와 함께 SharePoint 또는 OneDrive를 사용하여 버전 제어를 효과적으로 사용하기 위한 추가 고려 사항을 설명합니다.

Microsoft Teams 통합

콘텐츠 작성자가 협업에 Microsoft Teams를 사용하는 경우 Microsoft Teams의 문서 라이브러리를 사용할 수 있습니다. 문서 라이브러리는 SharePoint 사이트이며, 별도의 SharePoint 사이트 또는 OneDrive 폴더 대신 문서 라이브러리를 사용하면 콘텐츠, 파일 및 협업을 중앙 집중화할 수 있습니다.

체크 인 및 체크 아웃 파일

변경 충돌 가능성을 방지하려면 작업 중인 파일을 체크 아웃해야 합니다. 변경이 완료되면 변경 내용을 설명하는 설명이 포함된 파일을 체크 인합니다. 파일 체크 인 및 체크 아웃은 버전 제어를 위해 SharePoint 또는 회사 및 학교용 OneDrive를 사용할 때 콘텐츠 작성자 간의 협업을 개선하는 데 도움이 됩니다. 여러 콘텐츠 작성자와 함께 파일을 체크 인 및 체크 아웃하는 경우 SharePoint 사이트 라이브러리를 수정하여 마지막 업데이트와 마지막 체크 인에 대한 설명을 볼 수 있습니다.

버전 기록

SharePoint 사이트 문서 라이브러리가 예기치 않게 중단되는 경우 콘텐츠를 별도의 위치에 백업해야 합니다. 또한 SharePoint 사이트에 보관되는 버전 수에 제한을 설정하고 이전 버전을 삭제해야 합니다. 이렇게 하면 버전 기록이 의미 있게 유지되고 너무 많은 공간을 차지하지 않게 됩니다.

보다 정교한 버전 제어를 위해 Azure Repos와 같은 원격 리포지토리에 파일을 저장하고 소스 제어를 사용하여 변경 내용을 관리할 수 있습니다.

원격 Git 리포지토리를 사용하여 소스 제어

원격 Git 리포지토리는 파일의 소스 제어를 용이하게 하여 콘텐츠 작성자가 변경 콘텐츠를 추적하고 관리할 수 있는 더 많은 옵션을 허용합니다. 간단히 말해서, 콘텐츠 작성자는 로컬로 또는 Power BI 서비스에서 콘텐츠를 개발한 다음 해당 변경 콘텐츠를 Azure Repos와 같은 원격 Git 리포지토리에 커밋하고 푸시할 수 있습니다.

참고 항목

Git 통합을 사용하지 않고도 콘텐츠의 소스 제어를 수행할 수도 있습니다. 이 시나리오에서는 원격 Git 리포지토리의 콘텐츠 변경 사항을 계속 추적하고 관리하지만 REST API 또는 XMLA 읽기/쓰기 엔드포인트를 사용하여 콘텐츠를 배포합니다. 콘텐츠 배포 방법에 대한 자세한 내용은 4단계: 콘텐츠 배포를 참조하세요.

다음 다이어그램은 소스 제어를 수행하는 방법에 대한 개략적인 개요를 보여 줍니다.

다이어그램은 다음 프로세스와 구성 요소를 설명합니다.

항목	설명
	콘텐츠 작성자는 로컬 환경에서 의미 체계 모델과 보고서를 개발하고 이러한 모델과 보고서를 .pbip 파일로 저장합니다. 콘텐츠 작성자는 의미 체계 모델을 개발하고 모델 메타데이터를 저장할 수도 있습니다.
	준비가 되면 콘텐츠 작성자는 변경 콘텐츠를 저장하고 정기적으로 원격 Git 리포지토리에 커밋하고 푸시합니다.
	원격 Git 리포지토리에서 콘텐츠 작성자는 개체 수준 변경 콘텐츠를 추적하여 버전 제어를 용이하게 합니다. 콘텐츠 작성자는 콘텐츠 작업을 위한 분기를 만들고 끌어오기 요청을 사용하여 변경 콘텐츠를 단일 분기로 병합할 수도 있습니다.
	콘텐츠 작성자는 Git 통합을 사용하여 원격 리포지토리의 콘텐츠를 동기화할 수 있습니다. 또한 REST API와 함께 Azure Pipelines와 같은 다른 방식을 사용하여 콘텐츠를 배포할 수도 있습니다.
	Fabric 작업 영역에서 콘텐츠 작성자는 동기화 또는 배포가 완료된 후 Power BI 콘텐츠의 변경 콘텐츠를 확인합니다. 콘텐츠 작성자는 작업 영역에서 데이터 흐름이나 Notebook과 같은 콘텐츠를 작성할 수 있습니다. Git 통합을 사용하는 경우 콘텐츠 작성자는 이 작업 영역을 원격 리포지토리의 특정 분기에 연결합니다.
	콘텐츠 작성자는 Git 통합을 사용하여 작업 영역에서 원격 리포지토리로 변경 콘텐츠를 커밋하고 푸시할 수 있습니다. 이러한 변경 콘텐츠는 데이터 흐름 및 Notebook과 같이 작업 영역에서 작성된 지원 콘텐츠에 대한 항목 정의를 가져올 수 있습니다.

요약하면 콘텐츠 작성자는 .pbip 파일, 메타데이터 파일 및 설명서를 중앙 Azure Repos 원격 리포지토리에 저장합니다. 이러한 파일은 기술 소유자가 큐레이팅합니다. 콘텐츠 작성자가 솔루션을 개발하는 동안 기술 소유자는 솔루션을 관리하고 변경 내용을 검토하며 이를 단일 솔루션으로 병합하는 작업을 담당합니다. Azure Repos는 SharePoint 및 OneDrive에 비해 변경 내용을 추적하고 관리하기 위한 보다 정교한 옵션을 제공합니다. 잘 큐레이팅되고 문서화된 리포지토리를 유지 관리하는 것은 모든 콘텐츠와 협업의 기초이므로 매우 중요합니다.

다음 시나리오에서는 소스 제어를 사용하여 변경 내용을 추적하고 관리하는 것이 좋습니다.

• 중앙 집중식 또는 탈중앙화식 팀이 콘텐츠를 만들고 관리합니다.
• 콘텐츠 작성자는 Azure DevOps를 사용하여 협업합니다.
• 콘텐츠 작성자는 Git, 소스 제어 관리 또는 DataOps 원칙에 익숙합니다.
• 콘텐츠 작성자는 복잡하거나 중요한 콘텐츠를 관리하거나 콘텐츠의 복잡성과 중요도가 크기 조정되고 증가할 것으로 기대합니다.

Azure DevOps에서 소스 제어를 효과적으로 사용하는 데 도움이 되는 몇 가지 필수 구성 요소와 고려 사항은 다음과 같습니다.

• Git: 변경 콘텐츠를 원격 리포지토리에 커밋하고 푸시하려면 콘텐츠 작성자가 다운로드하고 Git을 설치해야 합니다. Git은 파일의 변경 내용을 추적하는 분산 버전 제어 시스템입니다. Git 기본 사항을 알아보려면 Git이란?를 참조하세요.
• 도구: Git을 사용하려면 콘텐츠 작성자는 CLI(명령줄 인터페이스) 또는 Visual Studio 또는 Visual Studio Code와 같은 SCM용 GUI(그래픽 사용자 인터페이스) 클라이언트를 사용해야 합니다.
• 라이선스 및 권한: Azure Repos Git 리포지토리를 만들고 사용하려면 콘텐츠 작성자에게 다음이 있어야 합니다.
  • 액세스 수준이 기본(관련자와 반대)으로 설정되었습니다.
  • 조직 및 프로젝트에 속합니다.
  • 적절한 리포지토리 권한.
• Fabric Git 통합: 원격 리포지토리의 콘텐츠를 Microsoft Fabric 작업 영역과 동기화하기 위해 콘텐츠 작성자는 Fabric Git 통합을 사용합니다. 이는 데이터 흐름과 같이 Fabric 포털에서 만들어진 콘텐츠에 대한 변경 콘텐츠를 추적하고 관리하는 데 중요합니다.

팁

로컬 개발을 통해 소스 제어를 용이하게 하려면 Visual Studio Code와 같은 클라이언트 애플리케이션을 사용하는 것이 좋습니다. Power BI Desktop을 사용하여 콘텐츠를 개발한 다음 Visual Studio Code를 사용하여 원격 리포지토리에 대한 변경 콘텐츠를 준비, 커밋 및 푸시하여 해당 콘텐츠의 소스 제어 관리를 수행할 수 있습니다.

Warning

Fabric Git 통합에는 지원되는 항목 및 시나리오에 대한 몇 가지 제한 사항이 있습니다. 먼저 Fabric Git 통합이 특정 시나리오에 가장 적합한지 또는 소스 제어를 구현하기 위해 다른 방식을 취해야 하는지 유효성을 검사합니다.

또한 Fabric Git 통합에서는 민감도 레이블이 지원되지 않으며 민감도 레이블이 있는 항목 내보내기가 사용하지 않도록 설정될 수 있습니다. 콘텐츠에 민감도 레이블이 있는 경우 데이터 손실 방지 정책을 준수하면서 버전 제어를 달성할 수 있는 방법을 계획해야 합니다.

Azure Repos에서 소스 제어를 사용하는 주요 이점은 콘텐츠 작성자 간의 협업이 개선되고 콘텐츠 변경 및 배포에 대한 사용자 지정 및 감독이 강화된다는 것입니다.

다음 다이어그램은 Azure DevOps가 소스 제어와의 협업을 지원하는 방법에 대한 개략적인 개요를 보여 줍니다.

참고 항목

이전 다이어그램은 Azure DevOps를 사용하여 협업하는 방법의 한 예를 보여 줍니다. 팀의 요구 사항과 작업 방식에 가장 적합한 방식을 선택합니다.

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

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

다음 섹션에서는 Azure DevOps 및 Power BI를 사용하여 소스 제어를 효과적으로 사용하기 위한 추가 고려 사항을 설명합니다.

Important

Power BI 콘텐츠의 수명 주기를 관리할 때 소스 제어의 이점을 최대한 활용하려면 분기, 커밋, 끌어오기 요청 및 병합을 효과적으로 사용하는 것이 필수적입니다.

분기 사용

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

Fabric 콘텐츠를 관리하기 위해 분기 전략을 사용할 때 다음 요소를 고려합니다.

• 자신의 작업을 위해 콘텐츠 작성자가 복제해야 하는 분기. 예를 들어, 이러한 분기가 기본 분기의 복제본(트렁크 기반 개발이라고 함)이거나 계획된 특정 버전의 콘텐츠에 대한 릴리스 분기와 같은 다른 분기인 경우입니다.
• 릴리스 분기를 사용하여 특정 작업의 범위를 별도의 콘텐츠 릴리스로 지정할지 여부.
• Fabric Git 통합을 사용할 때 어떤 분기가 어떤 작업 영역에 연결되는지.

팁

협업을 효과적으로 지원하기 위해 분기 전략을 가장 효과적으로 사용하는 방법에 대한 구체적인 지침과 권장 사항은 Git 분기 전략 채택을 참조하세요.

커밋의 일괄 처리 변경 내용

콘텐츠를 개발하는 동안 작성자는 정기적으로 변경 콘텐츠를 일괄 처리(또는 그룹)로 단계화해야 합니다. 이러한 변경 내용은 솔루션의 특정 작업 항목(예: 기능 또는 문제)을 해결해야 합니다. 준비가 되면 콘텐츠 작성자는 이러한 스테이징된 변경 사항을 커밋합니다.

이러한 방식으로 변경 내용을 일괄 처리하면 여러 가지 이점이 있습니다.

• 이는 구조 개발에 도움이 되며 콘텐츠 작성자가 그룹화한 변경 콘텐츠를 검토하고 문서화할 수 있는 기회를 제공합니다.
• 계획과 개발 간의 맞춤이 개선되어 기능과 문제를 더 쉽게 연결하고 작업 진행 방식에 대한 투명성을 가져올 수 있습니다.
• 변경 콘텐츠가 적절하게 일괄 처리되고 명확한 커밋 메시지가 있는 경우 기술 소유자는 콘텐츠 작성자의 끌어오기 요청을 더 쉽게 검토할 수 있습니다.

Power BI 콘텐츠에 대한 변경 콘텐츠를 준비하고 커밋할 때 다음 요소를 고려합니다.

• 로컬 리포지토리 또는 Fabric 작업 영역에서 변경 내용을 스테이징하고 커밋할지 여부.
• 단일 리포지토리에 여러 모델이나 보고서를 저장할 때 .pbip 파일을 최상위 폴더에 저장합니다. 이렇게 하면 변경 내용을 더 쉽게 식별하고 그룹화할 수 있습니다.
• gitignore 파일 또는 .gitattributes 파일을 사용하여 무해하거나 도움이 되지 않는 메타데이터 변경 내용을 무시합니다. 이렇게 하면 커밋한 모든 변경 내용이 의미 있게 됩니다.

팁

작업을 스테이징하고 Git 리포지토리에 커밋하는 방법에 대한 구체적인 지침과 권장 사항은 커밋을 사용하여 작업 저장을 참조하세요.

변경 내용을 병합하기 위한 끌어오기 요청 만들기

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

끌어오기 요청을 사용하여 변경 콘텐츠를 Power BI 콘텐츠에 병합하는 경우 다음 요소를 고려합니다.

• 검토를 수행하기 위해 어떤 표준과 사례를 사용할 것인가요? 예를 들어, 의미 체계 모델에 대한 모범 사례 분석기의 규칙을 사용할 수 있습니다.
• 타사 도구를 사용하지 않으면 읽고 이해하기 어려운 보고서 메타데이터의 변경 내용을 검토하는 방법입니다.
• 병합 충돌을 해결하는 방법.

팁

콘텐츠 변경 콘텐츠를 병합하여 협업을 지원하기 위해 끌어오기 요청을 가장 효과적으로 사용하는 방법에 대한 구체적인 지침과 권장 사항은 끌어오기 요청 정보 및 병합 전략 및 Squash 병합을 참조하세요.

체크리스트 - 파일을 저장할 위치를 계획할 때 주요 결정 및 작업은 다음과 같습니다.

• 개발 도구 선택: 콘텐츠 개발 방식이 다른 콘텐츠 작성자와 협업하고 버전 제어를 사용하는 방식과 일치하는지 확인합니다.
• 모델 및 보고서에 대해 .pbip 및 .pbix 형식 중에서 선택: 일반적으로 .pbip 형식은 소스 제어에 더 유용하지만 셀프 서비스 사용자는 .pbix 파일을 더 쉽게 사용할 수 있습니다.
• 별도의 의미 체계 모델 및 보고서 개발: 버전 제어는 다양한 항목 종류에 대한 변경 내용을 별도로 관리할 때 가장 효과적입니다. 모델과 보고서 개발 분리: 이 작업은 수행하는 것이 좋습니다.
• 필요한 작업 영역 수 결정: 콘텐츠 수명 주기 관리의 성공을 위해서는 별도의 환경을 사용해야 합니다. 필요한 작업 영역 수를 명확히 하고 적절한 작업 영역 수준 계획을 수행합니다.
• 버전 제어 구현 방법 결정: SharePoint 또는 OneDrive for Business를 사용하는 간단한 방식과 소스 제어를 용이하게 하는 Azure DevOps를 사용하는 방법 중에서 결정합니다.
• 원격 리포지토리 설정: OneDrive 폴더 또는 Git Repo에 콘텐츠를 저장하여 변경 콘텐츠를 추적하고 관리할 구조화된 공간을 만듭니다.
• 소스 제어를 사용하는 경우 .gitignore 및 .gitattributes 파일 설정: 의미 있는 변경 내용만 추적할 수 있도록 리포지토리를 설정해야 합니다.
• 소스 제어를 사용하는 경우 분기 및 병합 전략 정의: 개발을 최대한 지원하기 위해 소스 제어를 설정하고 사용하는 방법에 대한 명확한 프로세스를 정의해야 합니다. 프로세스를 지나치게 복잡하게 만들지 마세요. 대신, 개발팀의 현재 작업 방식을 보완하려고 노력합니다.

관련 콘텐츠

이 시리즈의 다음 문서에서는 콘텐츠 수명 주기 관리의 일환으로 콘텐츠의 유효성을 검사하는 방법을 알아봅니다.