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

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

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

수명 주기 관리는 생성부터 최종 사용 중지까지 콘텐츠를 처리하는 데 사용하는 프로세스 및 사례입니다. 수 명 주기 관리의 첫 번째 단계에서는 솔루션을 계획하고 수명 주기 관리에 대한 접근 방식에 영향을 주는 주요 결정을 내리는 콘텐츠를 계획하고 디자인합니다. 두 번째 단계에서는 콘텐츠를 개발하고 변경 내용을 관리합니다.

수명 주기 동안 콘텐츠 변경을 관리하는 것은 콘텐츠 작성자 간의 효과적인 공동 작업과 소비자에게 안정적이고 일관된 콘텐츠 전달을 보장하는 데 중요합니다.

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

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

버전 제어의 다른 이점은 다음과 같은 기능을 포함합니다.

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

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

콘텐츠 개발 방법 결정

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

Power BI 데스크톱

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

• 사용할 파일 형식: 콘텐츠를 .pbix 또는 .pbip 파일로 저장할 수 있습니다. 자세한 내용은 이 문서의 뒤쪽에 있는 콘텐츠 형식 결정을 참조하세요.
• 사용자 지정 콘텐츠를 관리하는 방법: Power BI Desktop 파일에 테마, 사용자 지정 시각적 개체 또는 이미지를 추가할 수 있습니다. 수명 주기 관리에 대한 고유한 고려 사항이 필요할 수 있습니다. 예를 들어 콘텐츠 작성자가 고유한 사용자 지정 시각적 개체를 만들 때 시각적 정의를 별도의 파일에 저장하고 관리해야 합니다.
• 미리 보기 기능을 관리하는 방법: Power BI Desktop에서 기능 또는 설정을 미리 보기하도록 옵트인하여 콘텐츠와 사용 방법을 변경할 수 있습니다. 예를 들어 미리 보기 기능을 사용하는 콘텐츠의 유효성을 검사하는 추가 단계를 수행할 수 있습니다.

웹 작성

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

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

기타 도구

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

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

다른 도구를 사용하여 콘텐츠를 만들 때 몇 가지 주요 결정에는 다음이 포함됩니다.

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

콘텐츠를 만드는 방법을 결정하면 다음으로 저장하고 관리하는 데 사용할 형식을 선택해야 합니다.

콘텐츠 형식 결정

만들 콘텐츠와 사용할 도구에 따라 콘텐츠에서 다른 파일 형식을 사용할 수 있습니다. 그러나 도구 내에서도 다른 형식 중에서 선택해야 합니다. 예를 들어 Power BI Desktop을 사용하여 만든 보고서 및 의미 체계 모델의 경우 .pbix 파일과 .pbip 파일 중에서 선택해야 합니다. 이 결정은 콘텐츠를 개발하는 방법뿐만 아니라 수명 주기 동안 해당 콘텐츠를 관리하는 방법 및 특정 개발 작업을 얼마나 효율적으로 완료할 수 있는지에 대한 기능적 영향을 줍니다. 예를 들어 Power BI Desktop에서 콘텐츠를 개발하지만 Git 통합을 사용하여 해당 콘텐츠를 게시하려면 .pbip 파일을 사용해야 합니다.

콘텐츠의 파일 형식은 수명 주기 동안 변경됩니다. 예를 들어 처음에는 보고서 및 모델에 대한 .pbix 파일을 만들기 시작할 수 있습니다. 그러나 새 콘텐츠 작성자가 사용자와 공동 작업을 수행하거나 생산성을 향상하려는 경우 .pbip 파일과 같은 다른 형식으로 전환할 수 있습니다.

다음 섹션에서는 Power BI에서 선택해야 하는 일반적인 형식에 대해 간략하게 설명합니다.

Power BI Desktop(.pbix) 파일 형식

Power BI 보고서 및 모델의 기본 및 가장 일반적인 형식은 .pbix 파일 형식입니다. 이 이진 형식은 대부분의 사람들에게 쉽게 관리하고 사용할 수 있습니다. 그러나 파일 콘텐츠를 열거나 사용하여 변경 내용을 추적하거나 개발자 생산성을 향상시킬 수는 없습니다.

다음과 같은 경우 .pbix 파일 형식을 사용합니다.

• OneDrive 새로 고침을 사용하여 콘텐츠를 게시할 계획입니다.
• 콘텐츠 작성자는 여러 파일의 폴더(예: .pbip 형식)가 아닌 단일 파일을 사용하고 공유하려고 합니다.
• 콘텐츠 작성자는 더 간단하기 때문에 .pbix 형식을 선호합니다.

Power BI 프로젝트(.pbip) 파일 형식

.pbix 파일 대신 Power BI 프로젝트(.pbip) 형식을 사용하여 콘텐츠를 저장할 수도 있습니다. 이 형식은 파일을 폴더 구조로 분할합니다. .pbip의 폴더 구조에는 모델 및 보고서에 대한 정의 및 구성을 제공하는 여러 메타데이터 파일을 열고 읽을 수 있습니다. 파일 내용을 열고 읽을 수 있으므로 수동으로 또는 프로그래밍 방식으로 변경할 수 있으므로 생산성이 크게 향상됩니다. 또한 Git 통합과 같은 패브릭의 특정 기능을 사용하려면 Power BI Desktop에서 콘텐츠를 개발하는 경우 .pbix 형식 대신 .pbip 형식을 사용해야 합니다.

다음 이미지는 .pbix 파일과 .pbip 파일의 차이점을 보여줍니다.

요약하면 사용자 또는 자동화된 프로세스는 Power BI Desktop에서 파일을 열지 않고 .pbip 파일의 내용을 보고 수정할 수 있습니다. 반면. .pbix 파일은 이진 파일이며 해당 내용을 보거나 수정하는 데 지원되는 메서드는 없습니다. 다음과 같은 메타데이터 콘텐츠를 보거나 변경할 수 있는 다양한 시나리오가 있습니다.

• 변경 내용에 대한 가시성과 함께 변경 내용을 추적하고 관리하여 소스 제어를 수행하려고 합니다.
• 대량으로 변경하거나 파일에서 항목을 검색하려고 합니다.
• 시각적 개체, 테이블 또는 측정값과 같은 파일의 요소를 다시 사용하려고 합니다.
• Power BI Desktop의 사용자 인터페이스에 표시되지 않는 속성 또는 설정을 보려고 합니다.
• 콘텐츠를 게시하기 전에 메타데이터를 검사하여 모범 사례 위반을 검색하는 등의 특정 프로세스를 자동화하려고 합니다.

.pbip 파일 형식은 의미 체계 모델 및 보고서 정의에 TMDL 또는 PBIR 형식을 각각 사용할 수도 있으며, 고유한 장점과 고려 사항을 염두에 두어야 합니다.

다음과 같은 경우 .pbip 파일 형식을 사용합니다.

• OneDrive 새로 고침이 아닌 Git 통합을 사용하여 콘텐츠를 게시하거나 배포할 계획입니다.
• 소스 제어를 사용하여 변경 내용을 추적하고 관리할 계획입니다.
• Power BI Desktop을 다른 도구와 함께 사용하여 모델 또는 보고서를 개발할 계획입니다.
• 여러 콘텐츠 작성자가 모델 또는 보고서에서 공동 작업합니다.
• 생산성 향상을 활용하고 모델 또는 보고서를 만드는 시간을 절약하려고 합니다.
• 개발, 테스트 또는 배포 프로세스의 일부를 자동화할 계획입니다.
• 모델 및 보고서 파일을 여러 방식으로 구조화하려고 합니다 (예: .Report 폴더에는 여러 보고서를, .SemanticModel 폴더에는 여러 모델을 포함시키는 것처럼).

테이블 형식 모델 정의 언어(.tmdl) 파일 형식

모델을 .pbip으로 저장하면 TMSL(테이블 형식 모델 스크립팅 언어)을 사용하는 단일 .bim 파일 또는 새 테이블 형식 모델 정의 언어를 사용하는 여러 .tmdl 파일의 폴더 구조로 저장할 수 있습니다. TMDL은 모델의 변경 내용을 더 쉽게 읽고 관리할 수 있도록 의미 체계 모델 정의에 YAML과 유사한 구문을 사용합니다.

다음은 TMDL 형식의 예입니다.

새 TMDL 형식의 몇 가지 장점은 다음과 같습니다.

• 모델 메타데이터가 더 간결하고, 구조화되고, 읽기 쉽기 때문에 소스 제어 및 Git 통합을 더 잘 사용할 수 있습니다.
• 충돌을 만들지 않고 변경 내용을 보다 쉽게 병합할 수 있습니다.
• 모델 간에 모델 개체를 다시 사용하거나 복사(예: 날짜 테이블)와 같은 특정 보고 작업에 대한 효율성을 향상시킬 수 있습니다.

다음은 TMDL 형식을 사용하는 소스 제어의 예입니다.

다음과 같은 경우 TMDL 형식을 사용합니다.

• 소스 제어를 사용하여 변경 내용을 추적하고 관리할 계획입니다.
• 메타데이터를 변경하여 개발자 생산성을 향상하려고 합니다.
• Visual Studio Code 또는 테이블 형식 편집기 같은 다른 도구를 사용하여 의미 체계 모델을 개발합니다.

Power BI PBIR(고급 보고서) 형식입니다.

콘텐츠를 .pbip 파일로 저장할 때 기본 보고서 형식 또는 새 PBIR 형식을 사용하도록 선택할 수 있습니다. 이 새로운 형식은 특히 .pbip 파일과 함께 PBIR 형식을 사용하는 경우 개발자 생산성 및 협업을 향상시킬 수 있는 몇 가지 이점을 제공합니다.

다음은 PBIR 형식의 예입니다.

PBIR 형식을 사용할 때의 몇 가지 장점은 다음과 같습니다.

• 보고서 메타데이터가 더 간결하고, 구조화되고, 읽기 쉽기 때문에 소스 제어 및 Git 통합을 더 잘 사용할 수 있습니다.
• 다음과 같은 특정 보고 작업에 대한 효율성을 향상시킬 수 있습니다.
  • visual.json를 복사하여 페이지 간에 시각적 요소를 다시 사용하거나 복사합니다.
  • 보고서 간에 페이지를 다시 사용하거나 복사합니다.
  • 사용자 지정 색상, 필드 및 기타 시각적 구성을 한 번에 찾아서 바꿔야 합니다.
  • "테이블 간에 이름이 변경되거나 이동된 필드로 인한 '깨진' 시각적 개체 수정"
• 메타데이터에 주석을 추가하여 CI/CD(연속 통합/지속적인 배포)를 지원하는 특정 자동화 또는 작업이 더 원활하게 이루어질 수 있도록 메타데이터를 보고할 수 있습니다.
• semantic-link-labs와 같은 도구는 새로운 PBIR 형식에서 더 많은 유용성을 발휘할 수 있도록 활용할 수 있습니다.

다음과 같은 경우 PBIR 형식을 사용합니다.

• 소스 제어를 사용하여 변경 내용을 추적하고 관리할 계획입니다.
• 메타데이터를 변경하여 보고서 작성자의 생산성을 향상하려고 합니다.
• 보고서를 프로그래밍 방식으로 또는 자동으로 변경하려고 합니다.

Power BI 템플릿(.pbit) 파일 형식

Power BI 보고서 또는 의미 체계 모델을 .pbit 파일로 저장할 수도 있습니다. 그러나 .pbit 파일은 특정 보고서 레이아웃 또는 모델 구조를 다시 사용하기 위한 것입니다. 개발 중에는 .pbit 형식을 사용하여 Power BI 콘텐츠를 저장하고 관리해서는 안 됩니다. 대신 다시 사용할 수 있는 템플릿을 만들어 조직의 다른 사용자와 공유하려는 경우 .pbit 파일을 사용해야 합니다.

다른 형식

Power BI에서 다른 콘텐츠(예: 대시보드, 데이터 흐름 또는 페이지를 매긴 보고서)를 개발할 때 Fabric에서 항목을 개발하는 경우 콘텐츠 파일이 없을 수 있습니다. 또는 항목의 정의만 소스 제어에 저장할 수 있습니다. 자세한 내용은 이 시리즈의 이전 문서에서 파일을 저장할 위치 결정(Decide )을 참조하세요.

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

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

• 현재 사용 중인 콘텐츠에 영향을 주지 않고 콘텐츠를 개발하고 테스트할 수 있습니다. 이렇게 하면 프로덕션의 콘텐츠에 의도하지 않은 중단이 발생할 수 있는 변경 내용을 방지할 수 있습니다.
• 별도의 데이터 게이트웨이 또는 패브릭 용량을 사용하는 것과 같이 콘텐츠를 개발하고 테스트하기 위해 별도의 리소스를 사용할 수 있습니다. 이렇게 하면 개발 및 테스트에 사용되는 리소스가 프로덕션 워크로드를 방해하여 데이터 새로 고침 또는 보고서가 느려지는 것을 방지할 수 있습니다.
• 이러한 각 단계에 대해 개별 환경을 사용하여 콘텐츠를 개발, 테스트 및 릴리스하는 보다 구조화된 프로세스를 만들 수 있습니다. 이렇게 하면 생산성을 향상시킬 수 있습니다.

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

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

이 콘텐츠의 수명 주기 동안 별도의 작업 영역을 사용하는 방법을 계획할 때 다음 질문에 대답합니다.

• 필요한 작업 영역은 몇 개입니까?
• 작업 영역을 항목 유형별로 구분하시겠습니까?
• 각 작업 영역에 대한 액세스 권한은 누구에게 있나요?
• 작업 영역이 패브릭 배포 파이프라인에 속합니까, 아니면 Azure Pipelines 사용과 같은 다른 방법을 사용하여 배포를 오케스트레이션할 것인가요?
• 작업 영역 간 게시를 어떻게 관리하시겠습니까? 예를 들어 보고서에 대한 테스트 작업 영역의 보고서가 데이터 항목에 대한 별도의 테스트 작업 영역의 의미 체계 모델에 연결되도록 해야 합니까?
• 또한 별도의 온-프레미스 데이터 게이트웨이 클러스터와 같은 프로덕션 작업 영역의 항목에 대해 별도의 지원 리소스를 사용해야 합니까?

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

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

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

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

이 다이어그램은 이 방법에서 작업 영역을 구분하는 다음 프로세스 및 구성 요소를 보여 줍니다.

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

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

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

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

이 다이어그램은 이 방법에서 작업 영역을 구분하는 다음 프로세스 및 구성 요소를 보여 줍니다.

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

Git 통합을 사용하여 프라이빗 작업 영역

중요 비즈니스용 콘텐츠를 제공할 때 각 개발자는 자체 프라이빗 작업 영역을 개발에 사용할 수도 있습니다. 이 시나리오에서 프라이빗 작업 영역을 사용하면 콘텐츠 작성자가 패브릭 포털에서 콘텐츠를 테스트하거나 개발 팀의 다른 사용자에게 중단을 주지 않고 예약된 새로 고침과 같은 기능을 사용할 수 있습니다. 콘텐츠 작성자는 여기서 패브릭 포털에서 데이터 흐름과 같은 콘텐츠를 개발할 수도 있습니다. Azure DevOps와 함께 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 리포지토리를 사용하여 버전 제어를 수행할 수 있습니다. Azure DevOps 대신 GitHub를 사용할 수도 있습니다. 두 방법 모두 원격 스토리지 위치에 로컬 콘텐츠 파일을 추가하여 변경 내용을 추적하고 관리하는 데 도움이 됩니다. 더 크고 복잡한 시나리오를 지원하는 기능과 견고성이 부족하므로 더 작고 간단한 프로젝트에만 SharePoint 또는 OneDrive를 사용하는 것이 좋습니다.

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

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

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

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

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

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

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

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

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

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

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

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

SharePoint 또는 OneDrive를 사용하여 다음 시나리오에서 변경 내용을 추적하고 관리하지 않도록 합니다.

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

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

Microsoft Teams 통합

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

체크 인 및 체크 아웃 파일

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

버전 기록

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

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

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

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

다음 다이어그램에서는 로컬에서 콘텐츠를 개발한 다음, Git 통합을 사용하여 패브릭 작업 영역과 동기화할 수 있는 원격 리포지토리에 변경 내용을 커밋하여 소스 제어를 수행하는 방법에 대한 개략적인 개요를 보여 줍니다.

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

항목	설명
	콘텐츠 작성자는 로컬 환경에서 의미 체계 모델 및 보고서를 개발하고 이러한 모델 및 보고서를 .pbip 파일로 저장합니다. 콘텐츠 작성자는 의미 체계 모델을 개발하고 모델 메타데이터를 저장할 수도 있습니다.
	준비가 되면 콘텐츠 작성자는 변경 내용을 저장하여 정기적으로 원격 Git 리포지토리에 커밋하고 푸시합니다.
	원격 Git 리포지토리에서 콘텐츠 작성자는 버전 제어를 용이하게 하는 개체 수준 변경 내용을 추적합니다. 콘텐츠 작성자는 콘텐츠를 작업할 분기를 만들고 끌어오기 요청을 사용하여 변경 내용을 단일 분기로 병합할 수도 있습니다.
	콘텐츠 작성자는 Git 통합을 사용하여 원격 리포지토리의 콘텐츠를 동기화할 수 있습니다. 또한 REST API와 함께 Azure Pipelines와 같은 다른 방법을 사용하여 콘텐츠를 배포할 수도 있습니다.
	패브릭 작업 영역에서 콘텐츠 작성자는 동기화 또는 배포가 완료된 후 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을 사용하려면 콘텐츠 작성자가 Visual Studio 또는 Visual StudioCode와 같은 SCM용 CLI(명령줄 인터페이스) 또는 GUI(그래픽 사용자 인터페이스) 클라이언트를 사용해야 합니다.
• 라이선스 및 사용 권한: Azure Repos Git 리포지토리를 만들고 사용하려면 콘텐츠 작성자는 다음이 있어야 합니다.
  • 액세스 수준이 스테이크홀더가 아닌 기본으로 설정됩니다.
  • 조직 및 프로젝트에 속합니다.
  • 적절한 리포지토리 권한.
• 패브릭 Git 통합: 원격 리포지토리의 콘텐츠를 Microsoft Fabric 작업 영역과 동기화하기 위해 콘텐츠 작성자는 Fabric Git 통합을 사용합니다. 이는 데이터 흐름과 같이 패브릭 포털에서 만든 콘텐츠의 변경 내용을 추적하고 관리하는 데 중요합니다.

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

다음 다이어그램에서는 Azure DevOps가 소스 제어와의 협업을 가능하게 하는 방법에 대한 개략적인 개요를 보여 줍니다. 비슷한 기능을 수행하는 다른 서비스를 포함하는 AzureDevOps 대신 GitHub Enterprise를 사용할 수도 있습니다.

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

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

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

분기 사용

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

분기 전략을 사용하여 패브릭 콘텐츠를 관리하는 경우 다음 요소를 고려합니다.

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

커밋에 대한 일괄 변경 사항

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

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

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

Power BI 콘텐츠에 대한 변경 내용을 스테이징하고 커밋하는 경우 다음 요소를 고려합니다.

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

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

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

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

• 검토를 수행하는 데 사용할 표준 및 사례(있는 경우)입니다. 예를 들어 의미 체계 모델에 모범 사례 분석기 에서 규칙을 사용할 수 있습니다.
• 타사 도구를 사용하지 않고는 읽고 이해하기 쉽지 않은 보고서 메타데이터에 대한 변경 내용을 검토하는 방법입니다.
• 병합 충돌을 해결하고 처리하는 방법입니다.

검사 목록 - 파일을 저장할 위치를 계획할 때 주요 결정 및 작업에는 다음이 포함됩니다.

관련 콘텐츠

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