検証用の Power BI プロジェクト (PBIP) と Azure DevOps ビルド パイプライン
Fabric Git 統合と Azure DevOps を組み合わせると、ワークスペースを Azure DevOps リポジトリ内のブランチに接続し、それらの間で自動的に同期することができます。
PBIP 形式を Azure DevOps と統合すると、Azure Pipelines を使用して継続的インテグレーション/継続的デプロイ (CI/CD) パイプラインを自動化できます。 これらのパイプラインは PBIP メタデータ ファイルを処理し、運用システムにデプロイする前に一連の品質チェックを開発に適用します。
この記事では、継続的インテグレーションに焦点を当てて、Fabric ワークスペース内のすべてのセマンティック モデルとレポートのベスト プラクティスを保証する Azure DevOps パイプラインの作成方法について説明します。 自動品質テストを実装すると、一般的なミスを防ぎ、チームの効率性を高めることができます。 たとえば、このアプローチにより、新しいチーム メンバーがセマンティック モデルおよびレポート開発用に確立された基準に準拠することが保証されます。
PBIP と Fabric Git 統合の詳細については、「プロジェクトの概要」と「Fabric Git 統合の概要」を参照してください。
次の図は、開発の品質を検証するために Azure DevOps パイプラインをトリガーする 2 つの開発ワークフローを含むエンドツーエンドのシナリオを示しています。 パイプラインの実行では、以下のアクションが実行されます。
ユーザー 1 が Power BI Desktop を使用して開発します。
- VS Code を使用して main からブランチを作成する (feature/datasetchange)
- Power BI Desktop を使用してセマンティック モデルに変更を加える
- VS Code を使用してリモート リポジトリ ブランチに変更をコミットする
- Azure DevOps を使用して main ブランチへの pull request を作成する
同時に、ユーザー 2 が別の Fabric ワークスペースを使用して開発します。
- Fabric Git を使用して main からブランチを作成する (feature/reportchange)
- Fabric ワークスペースでレポートを変更する
- Fabric Git を使用してリモート リポジトリ ブランチに変更をコミットする
- Azure DevOps を使用して main ブランチへの pull request を作成する
チーム リーダーが pull request を確認し、Fabric Git を使用してチーム ワークスペースに対する変更を同期します。
pull request は、セマンティック モデルを検査し開発の品質を報告する Azure DevOps パイプラインをトリガーします。
Note
この例において、パイプラインは、開発者が Power BI プロジェクト フォルダー内のセマンティック モデルとレポートのメタデータに (カスタマイズ可能な) ベスト プラクティス ルールを適用できるようにする以下の 2 つのオープンソース コミュニティ ツールを使用します。
この記事の例のようなアプローチは、他のコミュニティ ツールにも適用されます。 この記事では、前述のコミュニティ ツールまたはルールの作成と編集の詳細について掘り下げることはしません。 これらのトピックの詳細については、提供されているリンクを参照してください。 この記事の焦点は、ソース管理と Fabric ワークスペースの間に品質ゲートを確立するプロセスです。 注意すべき重要な点は、言及されているコミュニティ ツールはサード パーティの共同作成者によって開発されており、Microsoft はそれらのサポートまたはドキュメントを提供していないことです。
ステップ 1 - Fabric ワークスペースを Azure DevOps に接続する
Fabric ワークスペースを Azure DevOps に接続します。
Fabric Git 統合でワークスペース項目のエクスポートを完了すると、Azure DevOps ブランチにワークスペース内の各項目のフォルダーが含まれます。
手順 2 - Azure DevOps パイプラインを作成して実行する
新しいパイプラインを作成するには:
左側のナビゲーション メニューの [パイプライン] タブで、[パイプラインの作成] を選択します。
Azure Repos Git を選択して、最初のリポジトリ (Fabric ワークスペースに接続されているものと同じリポジトリ) を選択します。
[スタート パイプライン] を選択します。
次の YAML コードがエディターに表示されます。
Power BI 開発者モード パイプラインからの YAML コードを、作成したパイプラインにコピーして貼り付けます。
[保存および実行] を選択して、新しいパイプラインをリポジトリにコミットします。
![[保存して実行] の選択の様子を示すスクリーンショット。](media/projects-build-pipelines/save-run.png)
Azure DevOps でパイプラインを実行し、次の 2 つのビルド ジョブを並列で開始します。
- Build_Datasets
- Tabular Editor バイナリをダウンロードします。
- ベスト プラクティス アナライザーの既定の規則をダウンロードします。 ルールをカスタマイズするには、Rules-Dataset.json をリポジトリのルートに追加します。
- すべてのセマンティック モデル項目フォルダーを巡回して、Tabular Editor の BPA ルールを実行します。
- Build_Reports
- PBI Inspector バイナリをダウンロードします。
- PBI Inspector の既定の規則をダウンロードします。 ルールをカスタマイズするには、Rules-Report.json をリポジトリのルートに追加します。
- すべてのレポート アイテム フォルダーを巡回して、Power BI Inspector ルールを実行します。
完了すると、Azure DevOps で遭遇したすべての警告とエラーのレポートが作成されます。
以下のリンクを選択して、2 つのジョブのより詳細なビューを開きます。
![[ログの表示] ボタンを示すスクリーンショット。](media/projects-build-pipelines/view-log.png)
レポートまたはセマンティック モデルで重大度レベルの高いルールに失敗した場合、ビルドは失敗し、エラーが強調表示されます。
ステップ 3 - ブランチ ポリシーを定義する
パイプラインが起動して実行されたら、main ブランチでブランド ポリシーを有効にします。 このステップで、main に直接コミットを行えないようにします。 変更を main にマージし直すには "pull request" が常に必要になります。また、すべての pull request で実行されるようにパイプラインを構成することができます。
[ブランチ]>[main ブランチ]>[ブランド ポリシー] の順に選択します。
作成したパイプラインをブランチのビルド ポリシーとして構成します。
ステップ 4 - pull request を作成する
Fabric ワークスペースに戻り、レポートまたはセマンティック モデルのいずれかに変更を加えて、変更をコミットしようとすると、次のエラーが表示されます。
main ブランチに変更を加えることができるのは、pull request を介する場合のみです。 pull request を作成するには、新しいブランチをチェックアウトして、変更を加えます。
以下のようにして、Fabric ワークスペースから直接ブランチを作成します。
[ソース管理] ペインで、[新しいブランチのチェックアウト] を選択し、ブランチの名前を指定します。
または、独立した分離されたワークスペース内または Power BI Desktop 内での開発を選択することもできます。 詳細については、「別のワークスペースを使用して開発する」を参照してください
この新しいブランチに変更をコミットします。
コミットの後、Azure DevOps ポータルから main ブランチに pull request を作成します。
pull request ワークフローでは、変更を検証してレビューするだけでなく、パイプラインを自動的にトリガーすることもできます。
いずれかのルールで重大度の高いエラーが発生した場合、pull request を完了して変更をメイン ブランチにマージし直すことはできません。
PBIP と Fabric Git 統合の詳細については、ブログ記事を参照してください。