수명 주기 관리 모범 사례

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

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

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

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

• 테스트 - 배포 파이프라인 테스트 단계를 통해 환경을 테스트하는 방법에 대해 알아보세요.

• 프로덕션 - 배포 파이프라인 프로덕션 단계를 활용하여 콘텐츠를 소비할 수 있도록하세요.

콘텐츠 준비

콘텐츠의 수명 주기 동안 지속적인 관리를 위해 해당 섹션의 정보를 사전 검토하여 콘텐츠를 제대로 준비하세요:

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

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

팀 간 분리 개발

같은 프로젝트를 진행하는 경우라고 해도 조직 내 팀마다 전문성, 소유권, 작업 방식이 다른 경우가 많습니다. 각 팀이 원하는 방식으로 작업할 수 있도록 독립성을 부여하는 동시에 경계를 설정하는 것이 중요합니다. 팀별로 별도의 작업 영역을 사용하는 것이 좋습니다. 별도의 작업 영역을 사용하면 팀마다 서로 다른 권한을 갖고, 서로 다른 소스 제어 저장소에서 작업하고, 서로 다른 주기로 콘텐츠를 프로덕션에 출시할 수 있습니다. 대부분의 항목은 여러 작업 영역에서 데이터를 연결하고 사용할 수 있으므로 동일한 데이터와 프로젝트에 대한 공동 작업을 차단하지 않습니다.

권한 모델 계획

Git 통합 및 배포 파이프라인 모두 작업 영역 권한과는 다른 권한을 필요로 합니다. Git 통합 및 배포 파이프라인에 대한 권한 요구 사항에 관한 내용을 확인하세요.

안전하고 간편한 워크플로의 구현을 위해서는 파이프라인의 Git 리포지토리와 개발/테스트/프로덕션 단계 모두에서 사용 중인 환경의 각 부분에 액세스할 수 있는 사용자를 계획하세요. 몇 가지 고려할 사항이 있습니다.

• Git 리포지토리의 소스 코드에 누가 액세스해야 하나요?

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

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

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

• 프로덕션 스테이지로의 배포는 누가 감독해야 할까요?

• 어떤 작업 영역을 파이프라인에 할당하거나 git에 연결하고 있나요?

• 어느 분기에 작업 영역을 연결하고 있나요? 해당 분기에 정의된 정책은 무엇인가요?

• 다수의 팀원이 작업 영역을 공유하고 있나요? 작업 영역에서 직접 변경해야 하나요, 아니면 당겨받기 요청을 통해서만 변경해야 하나요?

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

• 할당하는 작업 영역의 권한을 변경해야 하나요?

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

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

단계 간에 변경되는 구성에 매개 변수를 사용합니다

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

개발

이 섹션에서는 배포 파이프라인 작업과 개발 단계에 적절한 사용에 대한 지침을 제공합니다.

Git 리포지토리에 작업 내용 백업하기

Git 통합을 통해 모든 개발자는 Git에 커밋하여 작업을 백업할 수 있습니다. 패브릭에서 작업을 올바르게 백업하려면 다음의 기본 규칙을 따르세요.

• 작업이 커밋되기 전에 다른 사람이 작업을 덮어쓰지 않도록 격리된 환경에서 작업할 수 있도록 합니다. 즉, 데스크톱 도구(예: VS Code, Power BI Desktop 등)에서 작업하거나 다른 사용자가 액세스할 수 없는 별도의 작업 공간에서 작업해야 합니다.

• 내가 생성하고 다른 개발자가 사용하지 않는 분기에 커밋합니다. 작업 영역을 제작 환경으로 사용하는 경우 분기 작업에 대한 내용을 확인합니다.

• 함께 배포해야 하는 변경 사항은 함께 커밋합니다. 이 조언은 단일 항목 또는 동일한 변경 사항과 관련된 다수의 항목에 적용됩니다. 관련된 모든 변경 사항을 함께 커밋하면 나중에 다른 단계로 배포하거나 당겨 받기 요청을 만들거나 변경 사항을 되돌릴 때 도움이 됩니다.

• 대규모 커밋은 최대 커밋 크기 제한에 걸릴 수 있습니다. 함께 커밋하는 항목의 개수 또는 항목의 일반적인 크기를 고려합니다. 예를 들어 큰 이미지를 추가하면 보고서가 커질 수 있습니다. 가능하다고 해도 소스 제어 시스템에 대용량 항목을 저장하는 것은 좋지 않습니다. 이미지와 같은 정적 리소스가 많은 경우 항목의 크기를 줄이는 방법을 고려합세요.

변경 내용 롤백

작업을 백업한 후 이전 버전으로 되돌리고 작업 영역에서 복원할 필요가 있을 수 있습니다. 몇 가지 방법으로 이전 버전으로 되돌릴 수 있습니다.

• 실행 취소 버튼: 실행 취소는 아직 커밋되지 않은 변경 내용을 쉽고 빠르게 되돌릴 수 있는 작업입니다. 각 항목을 개별적으로 실행 취소할 수도 있습니다. 실행 취소 작업에 대해 자세히 알아보세요.

• 이전 커밋으로 되돌리기: UI에서 이전 커밋으로 바로 돌아갈 수 있는 방법은 없습니다. 현재 최선의 방법은 git 되돌리기 또는 git 재설정을 사용하여 이전 커밋을 HEAD로 승격하는 것입니다. 이를 통해 소스 제어 창에 업데이트가 표시되며 새 커밋으로 워크스페이스를 업데이트할 수 있습니다.

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

'비공개' 작업 영역에서 작업하기

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

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

• 새 분기 생성하기: 주 분기에서 새 분기를 생성하여 최신 버전의 콘텐츠를 보유할 수 있습니다. 또한 분기의 올바른 폴더에 연결하여 올바른 콘텐츠를 작업 영역으로 가져올 수 있도록 하세요.

• 작고 잦은 변경: 병합이 쉽고 충돌 가능성이 적은 작은 단위의 점진적인 변경을 하는 것이 Git 모범 사례라 할 수 있습니다. 불가능할 경우에는 먼저 메인에서 분기를 업데이트하여 스스로 충돌을 해결하도록 하세요.

• 구성 변경: 필요시 작업 영역의 구성을 변경하여 보다 생산적으로 작업할 수 있도록 하세요. 일부 변경 사항에는 항목 간 연결, 다른 데이터 원본에 대한 연결 또는 특정 항목의 매개 변수 변경이 포함될 수 있습니다. 커밋하는 모든 것이 커밋의 일부가 되어 실수로 주 분기에 병합될 수 있다는 사실을 기억하세요.

클라이언트 도구로 작업 편집

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

작업 영역 및 분기 관리

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

• 개발자가 모든 필수 구성이 포함된 비공개 작업 영역을 설정한 경우 향후 생성하는 모든 분기에서 해당 작업 영역을 계속 사용할 수 있습니다. 스프린트가 끝나고 변경 사항이 병합되어 새로운 작업을 시작하려면 동일한 작업 영역의 새로운 분기로 연결을 전환하기만 하면 됩니다. 스프린트 도중에 갑자기 버그를 수정해야 하는 경우에도 이 작업을 수행할 수 있습니다. 웹상의 작업 디렉토리라고 생각하면 됩니다.

• 클라이언트 도구(예: VS Code, Power BI Desktop 등)를 사용하는 개발자에게는 작업 영역이 반드시 필요하지는 않습니다. 작업 영역 없이도 분기를 생성하고 해당 분기에 로컬로 변경 사항을 커밋하고, 원격 리포지토리에 돌려주고, 주 분기에 당겨받기 요청을 생성할 수 있습니다. 작업 영역은 실제 시나리오에서 모든 것이 작동하는지 확인하기 위한 테스트 환경으로만 필요합니다. 그 시기는 사용자가 결정할 수 있습니다.

Git 리포지토리에 항목 복제하기

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

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

테스트

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

프로덕션 환경 시뮬레이션

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

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

• 데이터 볼륨

• 사용량

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

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

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

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

관련 항목 확인

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

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

데이터 항목 업데이트

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

정의 변경 내용이 적용될 때 데이터 보존과 관련하여 항목마다 기능이 다르므로 변경 내용을 적용할 때 주의합니다. 가장 안전한 방법으로 변경 내용을 적용하는 데 도움이 될 수 있는 몇 가지 사례를 소개합니다.

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

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

• 모든 것이 순조롭게 진행되면 실제 데이터(또는 가능한 한 이에 가까운 데이터)를 사용하여 스테이징 환경에서도 확인하여 프로덕션에서 예기치 않은 동작을 최소화할 것을 권장합니다.

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

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

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

앱 테스트

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

생산

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

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

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

또한 콘텐츠 작성 프로세스에 참여하는 사용자에게만 파이프라인 권한을 사용하도록 설정하여 액세스를 제한해야 합니다.

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

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

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

프로덕션 앱 업데이트

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

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

리포지토리는 '신뢰할 수 있는 단일 원본' 역할을 하므로 일부 팀은 Git에서 직접 여러 단계로 업데이트를 배포할 수 있습니다. 몇 가지 고려 사항을 통해 Git 통합이 가능합니다.

• 릴리스 분기 사용을 권장합니다. 매번 배포하기 전에 작업 영역과 새 릴리스 분기의 연결을 지속적으로 변경해야 합니다.

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

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

콘텐츠에 대한 빠른 수정

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

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

관련 콘텐츠

• 종단 간 수명 주기 관리 튜토리얼
• Git 통합 시작하기
• 배포 파이프라인 시작