수명 주기 관리 모범 사례

이 문서에서는 Microsoft Fabric에서 수명 주기 동안 콘텐츠를 관리하는 데이터 및 분석 작성자를 위한 지침을 제공합니다. 이 문서에서는 릴리스 도구로 소스 제어 및 배포 파이프라인에 Git 통합을 사용하는 데 중점을 둡니다. 엔터프라이즈 콘텐츠 게시, 엔터프라이즈 콘텐츠 게시에 대한 일반적인 지침입니다.

Important

이 기능은 미리 보기로 제공됩니다.

이 문서는 4개 섹션으로 구분되어 있습니다.

• 콘텐츠 준비 - 수명 주기 관리를 위해 콘텐츠를 준비합니다.

• 개발 - 배포 파이프라인 개발 단계에서 콘텐츠를 만드는 최선의 방법을 알아봅니다.

• 테스트 - 배포 파이프라인 테스트 단계를 사용하여 환경을 테스트하는 방법을 이해합니다.

• 프로덕션 - 배포 파이프라인 프로덕션 단계를 활용하여 콘텐츠를 사용할 수 있도록 합니다.

콘텐츠 준비

수명 주기 내내 진행 중인 관리를 위해 콘텐츠를 가장 잘 준비하려면 다음 섹션의 정보를 검토하세요.

• 콘텐츠를 프로덕션으로 릴리스합니다.

• 특정 작업 영역에 대한 배포 파이프라인을 사용하기 시작하세요.

팀 간 개별 개발

조직의 다른 팀은 일반적으로 동일한 프로젝트에서 작업하는 경우에도 다른 전문 지식, 소유권 및 작업 방법을 가지고 있습니다. 각 팀에게 그들이 좋아하는 대로 일할 수 있는 독립권을 주면서 경계를 설정하는 것이 중요합니다. 서로 다른 팀에 대해 별도의 작업 영역을 두는 것이 좋습니다. 별도의 작업 영역을 사용하여 각 팀은 서로 다른 권한을 갖고, 다른 소스 제어 리포지토리를 사용하고, 다른 주기로 콘텐츠를 프로덕션에 제공할 수 있습니다. 대부분의 항목은 작업 영역에서 데이터를 연결하고 사용할 수 있으므로 동일한 데이터와 프로젝트에 대한 공동 작업을 차단하지 않습니다.

권한 모델 계획

Git 통합 및 배포 파이프라인 모두 작업 영역 권한과 다른 권한이 필요합니다. Git 통합 및 배포 파이프라인에 대한 권한 요구 사항을 읽어봅니다.

안전하고 쉬운 워크플로를 구현하려면 사용되는 환경의 각 부분(Git 리포지토리 및 파이프라인의 개발/테스트/프로드 단계)에 액세스할 수 있는 사용자를 계획합니다. 몇 가지 고려할 사항이 있습니다.

• Git 리포지토리의 소스 코드에 대한 액세스 권한이 있는 사람은 누구인가요?

• 파이프라인 액세스 권한이 있는 사용자가 각 단계에서 수행할 수 있는 작업은 무엇인가요?

• 테스트 단계에서 콘텐츠를 검토하는 사람은 누구인가요?

• 테스트 단계 검토자가 파이프라인에 액세스할 수 있어야 하나요?

• 프로덕션 단계에 대한 배포를 감독해야 하는 사람은 누구인가요?

• 파이프라인에 할당하거나 git에 연결하는 작업 영역은 무엇입니까?

• 작업 영역을 연결하는 분기는 무엇입니까? 해당 분기에 대해 정의된 정책은 무엇인가요?

• 작업 영역이 여러 팀 구성원이 공유합니까? 작업 영역에서 직접 변경해야 하나요, 아니면 끌어오기 요청을 통해서만 변경해야 하나요?

• 어떤 단계에 작업 영역을 할당하나요?

• 할당하는 작업 영역의 사용 권한을 변경해야 합니까?

각 단계를 서로 다른 데이터베이스에 연결

프로덕션 데이터베이스는 항상 안정적이고 사용 가능해야 합니다. 개발 또는 테스트 의미 체계 모델을 위해 BI 작성자가 생성한 쿼리로 오버로드하지 않는 것이 가장 좋습니다. 프로덕션 데이터를 보호하고 전체 프로덕션 데이터 볼륨으로 개발 데이터베이스를 오버로드하지 않도록 개발 및 테스트를 위한 별도의 데이터베이스를 빌드합니다.

단계 간에 변경되는 구성에 매개 변수 사용

가능하면 개발/테스트/프로드 단계 간에 변경될 수 있는 모든 정의에 매개 변수를 추가합니다. 매개 변수를 사용하면 변경 내용을 프로덕션으로 이동할 때 정의를 쉽게 변경할 수 있습니다. 패브릭에서 매개 변수를 관리하는 통합된 방법은 아직 없지만 모든 유형의 매개 변수화를 지원하는 항목에서 사용하는 것이 좋습니다. 매개 변수는 데이터 원본 또는 패브릭의 내부 항목에 대한 연결 정의와 같은 용도가 다릅니다. 쿼리, 필터 및 사용자에게 표시되는 텍스트를 변경하는 데 사용할 수도 있습니다.
배포 파이프라인에서 각 배포 단계에 대해 서로 다른 값을 설정하도록 매개 변수 규칙을 구성할 수 있습니다.

개발

이 섹션에서는 배포 파이프라인을 사용하고 개발 단계에 적합하게 사용하기 위한 지침을 제공합니다.

Git 리포지토리에 작업 백업

Git 통합을 사용하면 모든 개발자가 Git에 커밋하여 작업을 백업할 수 있습니다. 패브릭에서 작업을 제대로 백업하려면 다음과 같은 몇 가지 기본 규칙이 있습니다.

• 작업할 격리된 환경이 있는지 확인하여 다른 사용자가 커밋되기 전에 작업을 재정의하지 않도록 합니다. 즉, 데스크톱 도구(예: VS Code, Power BI Desktop 또는 기타) 또는 다른 사용자가 액세스할 수 없는 별도의 작업 영역에서 작업합니다.

• 만든 분기에 커밋하고 다른 개발자가 사용하지 않습니다. 작업 영역을 작성 환경으로 사용하는 경우 분기 작업에 대해 읽어봅니다.

• 함께 배포해야 하는 변경 내용을 함께 커밋합니다. 이 조언은 단일 항목 또는 동일한 변경과 관련된 여러 항목에 적용됩니다. 모든 관련 변경 내용을 함께 커밋하면 나중에 다른 단계에 배포하거나, 끌어오기 요청을 만들거나, 변경 내용을 다시 되돌리기 수 있습니다.

• 큰 커밋은 최대 커밋 크기 제한에 도달할 수 있습니다. 함께 커밋하는 항목 수 또는 항목의 일반 크기를 염두에 두어야 합니다. 예를 들어 큰 이미지를 추가할 때 보고서가 커질 수 있습니다. 작동하더라도 큰 크기의 항목을 소스 제어 시스템에 저장하는 것은 잘못된 방법입니다. 이미지와 같은 정적 리소스가 많은 경우 항목의 크기를 줄이는 방법을 고려합니다.

변경 내용 롤백

작업을 백업한 후 이전 버전으로 되돌리기 작업 영역에서 복원하려는 경우가 있을 수 있습니다. 이전 버전으로 되돌리기 몇 가지 방법이 있습니다.

• 실행 취소 단추: 실행 취소 작업은 아직 커밋되지 않은 한 즉시 변경한 내용을 되돌리기 수 있는 쉽고 빠른 방법입니다. 각 항목을 개별적으로 실행 취소할 수도 있습니다. 실행 취소 작업에 대해 자세히 알아보세요.

• 이전 커밋으로 되돌리기: UI에서 이전 커밋으로 돌아갈 직접적인 방법은 없습니다. 가장 좋은 방법은 git 되돌리기 또는 git 재설정을 사용하여 이전 커밋을 HEAD로 승격하는 것입니다. 이렇게 하면 소스 제어 창에 업데이트가 있으며 해당 새 커밋으로 작업 영역을 업데이트할 수 있습니다.

데이터가 Git에 저장되지 않으므로 데이터 항목을 이전 버전으로 되돌리기 기존 데이터가 손상될 수 있으며 데이터를 삭제해야 하거나 작업이 실패할 수 있습니다. 변경 내용을 다시 되돌리기 전에 미리 확인하세요.

'프라이빗' 작업 영역 작업

격리된 상태로 작업하려는 경우 별도의 작업 영역을 격리된 환경으로 사용합니다. 분기 작업에서 작업 환경을 격리하는 방법에 대해 자세히 알아보세요. 사용자와 팀에 가장 적합한 워크플로를 보려면 다음 사항을 고려하세요.

• 작업 영역 설정: 시작하기 전에 새 작업 영역(아직 없는 경우)을 만들고, 패브릭 용량에 할당할 수 있고, 작업 영역에서 작업할 데이터에 액세스할 수 있는지 확인합니다.

• 새 분기 만들기: 기본 분기에서 새 분기를 만들어 최신 버전의 콘텐츠를 만듭니다. 또한 올바른 콘텐츠를 작업 영역으로 끌어올 수 있도록 분기의 올바른 폴더에 연결해야 합니다.

• 작고 자주 변경: 병합하기 쉽고 충돌이 발생할 가능성이 적은 작은 증분 변경을 수행하는 것이 Git 모범 사례입니다. 가능하지 않은 경우 먼저 충돌을 해결할 수 있도록 기본 분기를 업데이트해야 합니다.

• 구성 변경: 필요한 경우 작업 영역의 구성을 변경하여 생산성을 높일 수 있습니다. 일부 변경 내용에는 항목 간 연결 또는 다른 데이터 원본에 대한 연결 또는 지정된 항목의 매개 변수 변경 내용이 포함될 수 있습니다. 커밋하는 모든 항목은 커밋의 일부가 되며 실수로 기본 분기에 병합될 수 있습니다.

클라이언트 도구를 사용하여 작업 편집

이를 지원하는 항목 및 도구의 경우 의미 체계 모델 및 보고서를 위한 Power BI Desktop, Notebook용 VSCode 등 작성을 위한 클라이언트 도구를 사용하는 것이 더 쉬울 수 있습니다. 이러한 도구는 로컬 개발 환경일 수 있습니다. 작업을 완료한 후 변경 내용을 원격 리포지토리로 푸시하고 작업 영역을 동기화하여 변경 내용을 업로드합니다. 작성 중인 항목의 지원되는 구조로 작업하고 있는지 확인합니다. 확실하지 않은 경우 먼저 콘텐츠가 작업 영역에 이미 동기화된 리포지토리를 복제한 다음 구조가 이미 있는 위치에서 작성을 시작합니다.

작업 영역 및 분기 관리

작업 영역은 한 번에 하나의 분기에만 연결할 수 있으므로 이를 1:1 매핑으로 처리하는 것이 좋습니다. 그러나 수반되는 작업 영역의 양을 줄이려면 다음 옵션을 고려합니다.

• 개발자가 모든 필수 구성을 사용하여 프라이빗 작업 영역을 설정하는 경우 나중에 만드는 모든 분기에 해당 작업 영역을 계속 사용할 수 있습니다. 스프린트가 끝나면 변경 내용이 병합되고 새 작업을 시작하고 동일한 작업 영역의 새 분기로 연결을 전환하기만 하면 됩니다. 스프린트 중간에 갑자기 버그를 수정해야 하는 경우에도 이 작업을 수행할 수 있습니다. 웹에서 작업 디렉터리로 간주합니다.

• 클라이언트 도구(예: VS Code, Power BI Desktop 등)를 사용하는 개발자는 반드시 작업 영역이 필요하지는 않습니다. 분기를 만들고 해당 분기에 대한 변경 내용을 로컬로 커밋하고, 원격 리포지토리로 푸시하고, 작업 영역 없이 기본 분기에 끌어오기 요청을 만들 수 있습니다. 작업 영역은 모든 것이 실제 시나리오에서 작동하도록 검사 테스트 환경으로만 필요합니다. 언제 그런 일이 일어나야 할지 결정하는 것은 사용자의 달려 있습니다.

Git 리포지토리에서 항목 복제

Git 리포지토리에서 항목을 복제하려면 다음을 수행합니다.

1. 전체 항목 디렉터리를 복사합니다.
2. logicalId를 연결된 작업 영역에 대한 고유한 항목으로 변경합니다.
3. 표시 이름을 변경하여 원래 항목과 구분하고 중복된 표시 이름 오류를 방지합니다.
4. 필요한 경우 종속성에서 logicalId 및/또는 표시 이름을 업데이트합니다.

테스트

이 섹션에서는 배포 파이프라인 테스트 단계를 사용하기 위한 지침을 제공합니다.

프로덕션 환경 시뮬레이션

제안된 변경 내용이 프로덕션 단계에 어떤 영향을 미치는지 확인하는 것이 중요합니다. 배포 파이프라인 테스트 단계를 사용하면 테스트 목적으로 실제 프로덕션 환경을 시뮬레이션할 수 있습니다. 또는 Git을 다른 작업 영역에 연결하여 이를 시뮬레이션할 수 있습니다.

테스트 환경에서 다음 세 가지 요소가 충족되는지 확인합니다.

• 데이터 볼륨

• 사용량

• 프로덕션 환경과 비슷한 용량

테스트할 때 프로덕션 단계와 동일한 용량을 사용할 수 있습니다. 그러나 동일한 용량을 사용하면 부하 테스트 중에 프로덕션이 불안정해질 수 있습니다. 불안정한 프로덕션을 방지하려면 리소스에서 프로덕션 용량과 비슷한 다른 용량을 사용하여 테스트합니다. 추가 비용을 방지하려면 테스트 시간에 대해서만 비용을 지불할 수 있는 용량을 사용합니다.

실제 데이터 원본에 배포 규칙 사용

테스트 단계를 사용하여 실제 데이터 사용량을 시뮬레이션하는 경우 개발 및 테스트 데이터 원본을 구분하는 것이 가장 좋습니다. 개발 데이터베이스는 비교적 작아야 하며 테스트 데이터베이스는 프로덕션 데이터베이스와 최대한 근사해야 합니다. 데이터 원본 규칙을 사용하여 테스트 단계에서 데이터 원본을 전환하거나 배포 파이프라인을 통해 작동하지 않는 경우 연결을 매개 변수화합니다.

관련 항목 확인

변경한 내용은 종속 항목에도 영향을 줄 수 있습니다. 테스트하는 동안 변경 내용이 업데이트된 항목에 종속될 수 있는 기존 항목의 성능에 영향을 주거나 중단하지 않는지 확인합니다.

영향 분석을 사용하여 관련 항목을 쉽게 찾을 수 있습니다.

데이터 항목 업데이트

데이터 항목은 데이터를 저장하는 항목입니다. Git의 항목 정의는 데이터가 저장되는 방법을 정의합니다. 작업 영역에서 항목을 업데이트할 때 해당 정의를 작업 영역으로 가져와서 기존 데이터에 적용합니다. 데이터 항목 업데이트 작업은 Git 및 배포 파이프라인에 대해 동일합니다.

정의에 대한 변경 내용이 적용될 때 데이터를 보존할 때 다양한 항목의 기능이 다르기 때문에 변경 내용을 적용할 때 유의해야 합니다. 가장 안전한 방법으로 변경 내용을 적용하는 데 도움이 되는 몇 가지 사례는 다음과 같습니다.

• 변경 내용과 변경 내용이 기존 데이터에 미칠 수 있는 영향을 미리 파악합니다. 커밋 메시지 사용하여 변경 내용을 설명합니다.

• 해당 항목이 테스트 데이터로 변경 내용을 처리하는 방법을 확인하려면 먼저 변경 내용을 개발 또는 테스트 환경에 업로드합니다.

• 모든 것이 제대로 진행되는 경우 프로덕션 환경에서 예기치 않은 동작을 최소화하기 위해 실제 데이터(또는 가능한 한 가깝게)를 사용하여 스테이징 환경에서도 검사 것이 좋습니다.

• 데이터를 사용하는 비즈니스 사용자에게 발생할 수 있는 오류를 최소화하기 위해 Prod 환경을 업데이트할 때 최상의 타이밍을 고려합니다.

• 배포 후 Prod에서 배포 후 테스트하여 모든 것이 예상대로 작동하는지 확인합니다.

• 일부 변경 내용은 항상 호환성이 손상되는 변경으로 간주됩니다. 이전 단계를 통해 프로덕션 전에 추적할 수 있기를 바랍니다. Prod의 변경 내용을 적용하고 데이터를 복구하여 정상 상태로 되돌리고 비즈니스 사용자의 가동 중지 시간을 최소화하는 방법에 대한 계획을 수립합니다.

앱 테스트

앱을 통해 고객에게 콘텐츠를 배포하는 경우 프로덕션 환경에서 앱의 새 버전을 검토합니다. 각 배포 파이프라인 단계에 자체 작업 영역이 있으므로 개발 및 테스트 단계를 위해 앱을 손쉽게 게시하고 업데이트할 수 있습니다. 앱을 게시하고 업데이트하면 최종 사용자의 관점에서 앱을 테스트할 수 있습니다.

Important

배포 프로세스에는 앱 콘텐츠 또는 설정 업데이트가 포함되지 않습니다. 콘텐츠 또는 설정에 변경 내용을 적용하려면 필요한 파이프라인 단계에서 앱을 수동으로 업데이트해야 합니다.

생산

이 섹션에서는 배포 파이프라인 프로덕션 단계에 대한 지침을 제공합니다.

프로덕션 환경에 배포할 수 있는 사용자 관리

프로덕션으로의 배포는 신중하게 처리해야 하므로 특정 사용자만 이 중요한 작업을 관리하도록 하는 것이 좋습니다. 그러나 특정 작업 영역의 모든 BI 작성자가 파이프라인에 액세스할 수 있도록 하려는 경우가 있습니다. 프로덕션 작업 영역 권한을 사용하여 액세스 권한을 관리합니다. 다른 사용자는 작업 영역에서 콘텐츠를 볼 수 있지만 Git 또는 배포 파이프라인에서 변경하지 않는 프로덕션 작업 영역 뷰어 역할을 가질 수 있습니다.

또한 콘텐츠 만들기 프로세스의 일부인 사용자에게만 권한을 사용하도록 설정하여 리포지토리 또는 파이프라인에 대한 액세스를 제한합니다.

프로덕션 단계 가용성을 보장하는 규칙 설정

배포 규칙은 프로덕션 데이터가 항상 연결되어 있고 사용 가능하도록 보장하는 강력한 방법입니다. 배포 규칙이 적용되면 고객이 방해 없이 관련 정보를 볼 수 있다는 확신이 있는 동안 배포를 실행할 수 있습니다.

의미 체계 모델에 정의된 데이터 원본 및 매개 변수에 대한 프로덕션 배포 규칙을 설정해야 합니다.

프로덕션 앱 업데이트

UI를 통해 파이프라인에 배포하면 작업 영역 콘텐츠가 업데이트됩니다. 연결된 앱을 업데이트하려면 배포 파이프라인 API를 사용합니다. UI를 통해 앱을 업데이트할 수 없습니다. 콘텐츠 배포에 앱을 사용하는 경우 최종 사용자가 최신 버전을 즉시 사용할 수 있도록 프로덕션에 배포한 후 앱을 업데이트하는 것을 잊지 마세요.

Git 분기를 사용하여 프로덕션 환경에 배포

리포지토리가 '단일 소스-진실'로 사용되기 때문에 일부 팀은 Git에서 직접 다른 단계로 업데이트를 배포하려고 할 수 있습니다. Git 통합에서는 다음과 같은 몇 가지 사항을 고려해야 합니다.

• 릴리스 분기를 사용하는 것이 좋습니다. 모든 배포 전에 작업 영역의 연결을 새 릴리스 분기로 지속적으로 변경해야 합니다.

• 빌드 또는 릴리스 파이프라인에서 소스 코드를 변경하거나 작업 영역에 배포하기 전에 빌드 환경에서 스크립트를 실행해야 하는 경우 작업 영역을 Git에 연결하는 것이 도움이 되지 않습니다.

• 각 스테이지에 배포한 후 해당 스테이지와 관련된 모든 구성을 변경해야 합니다.

콘텐츠에 대한 빠른 수정

경우에 따라 프로덕션에 빠른 수정이 필요한 문제가 있을 수 있습니다. 먼저 테스트하지 않고 수정 사항을 배포하는 것은 잘못된 방법입니다. 따라서 항상 개발 단계에서 수정 사항을 구현하고 배포 파이프라인 단계의 나머지 부분에 푸시합니다. 개발 단계에 배포하면 프로덕션에 배포하기 전에 수정이 작동하는지 확인할 수 있습니다. 파이프라인을 통해 배포하는 데 몇 분밖에 걸리지 않습니다.

Git에서 배포를 사용하는 경우 Git 분기 전략 채택에 설명된 사례를 따르는 것이 좋습니다.

관련 콘텐츠

• 종단 간 수명 주기 관리 자습서
• Git 통합 시작
• 배포 파이프라인 시작