ライフサイクル管理のベスト プラクティス

  • [アーティクル]

この記事では、Microsoft Fabric のライフサイクル全体でコンテンツを管理しているデータおよび分析作成者向けのガイダンスを提供します。 この記事では、リリース ツールとしてソース管理とデプロイ パイプラインに Git 統合を使用することに焦点を当てています。 Enterprise コンテンツの発行に関する一般的なガイダンスについては、Enterprise コンテンツの発行に関するページを参照してください。

重要

この機能はプレビュー中です。

この記事は、次の 4 つのセクションに分かれています。

  • コンテンツの準備 - ライフサイクル管理のためにコンテンツを準備します。

  • 開発 - デプロイ パイプラインの開発ステージでコンテンツを作成するための最適な方法について説明します。

  • テスト - デプロイ パイプラインのテスト ステージを使用して環境をテストする方法を理解します。

  • 運用 - デプロイ パイプラインの運用ステージを利用して、コンテンツを使用できるようにします。

コンテンツの準備

ライフサイクル全体を通じて継続的な管理のためにコンテンツを最適に準備するには、次を行う前に、このセクションの情報を確認してください。

  • コンテンツを運用環境にリリースします。

  • 特定のワークスペースのデプロイ パイプラインの使用を開始します。

チーム間で開発を分離する

同じプロジェクトで作業する場合でも、組織内の異なるチームは、通常、異なる専門知識、所有権、および作業方法を持っています。 各チームに好きなように働く独立を与えながら、境界を設定することが重要です。 チームごとに個別のワークスペースを用意することを検討してください。 個別のワークスペースを使用することで、各チームは異なるアクセス許可を持ち、異なるソース管理リポジトリを操作し、異なる頻度でコンテンツを運用環境に出荷できます。 ほとんどのアイテムはワークスペース間でデータを接続して使用できるため、同じデータとプロジェクトでのコラボレーションはブロックされません。

アクセス許可モデルを計画する

Git 統合パイプラインとデプロイ パイプラインの両方で、ワークスペースのアクセス許可とは異なるアクセス許可が必要です。 Git 統合とデプロイ パイプラインのアクセス許可要件について説明します。

安全で簡単なワークフローを実装するには、使用されている環境の各部分 (Git リポジトリとパイプラインの開発/テスト/prod ステージの両方) にアクセスするユーザーを計画します。 いくつかの考慮事項を次に示します。

  • Git リポジトリ内のソース コードにアクセスできる必要があるユーザー。

  • パイプラインへのアクセス許可を持つユーザーが各ステージで実行できる操作は何か

  • テスト ステージでコンテンツをレビューしているユーザー。

  • テスト ステージのレビュー担当者はパイプラインにアクセスできる必要があるかどうか

  • 運用ステージへのデプロイを監視するユーザー。

  • パイプラインに割り当てるワークスペース、または git に接続しているワークスペース。

  • ワークスペースの接続先ブランチ。 そのブランチに定義されているポリシー。

  • ワークスペースは複数のチーム メンバーによって共有されているか。 ワークスペース内で直接、または Pull 要求を通じてのみ変更を行う必要があるか。

  • ワークスペースを割り当てるステージはどれか

  • 割り当てるワークスペースのアクセス許可を変更する必要があるか。

異なる複数のステージを異なるデータベースに接続する

運用データベースは常に安定し、使用可能である必要があります。 開発またはテスト セマンティック モデルでは、BI 作成者によって生成されたクエリをオーバーロードしないことをお勧めします。 運用データを保護し、運用データのボリューム全体で開発データベースをオーバーロードしないように、開発とテスト用に個別のデータベースを構築します。

ステージ間で変更される構成にパラメーターを使用する

可能な限り、dev/test/prod ステージ間で変更される可能性があるすべての定義にパラメーターを追加します。 パラメーターを使用すると、変更を運用環境に移行するときに定義を簡単に変更できます。 Fabric でパラメーターを管理する統一された方法はまだありませんが、任意の種類のパラメーター化をサポートする項目でパラメーターを使用することをお勧めします。 パラメーターには、データ ソースへの接続の定義や Fabric の内部項目への接続など、さまざまな用途があります。 また、クエリ、フィルター、およびユーザーに表示されるテキストを変更するためにパラメーターを使用することもできます。
デプロイ パイプラインでは、デプロイ ステージごとに異なる値を設定するパラメーター規則を構成できます。

開発

このセクションでは、デプロイ パイプラインを操作し、開発ステージに合わせて使用するためのガイダンスを提供します。

Git リポジトリに作業をバックアップする

Git 統合を使用すると、すべての開発者が Git にコミットすることで作業をバックアップできます。 Fabric で作業を適切にバックアップするためのいくつかの基本的なルールを次に示します。

  • 作業がコミットされる前に他のユーザーが作業をオーバーライドしないように、作業を行うための分離された環境があることを確認します。 つまり、Desktop ツール (VS Code、Power BI Desktop など)、または他のユーザーがアクセスできない個別のワークスペースで作業します。

  • 自分が作成し、他の開発者が使用していないブランチにコミットします。 作成環境としてワークスペースを使用している場合は、ブランチの操作に関するページを参照してください。

  • 一緒にデプロイする必要がある変更を一緒にコミットします。 このアドバイスは、1 つの項目、または同じ変更に関連する複数の項目に適用されます。 関連するすべての変更を一緒にコミットすると、後で他のステージにデプロイするとき、pull request を作成するとき、または変更を元に戻すときに役立ちます。

  • 大きなコミットが最大コミット サイズの制限に達する可能性があります。 一緒にコミットする項目の数、または項目の一般的なサイズに注意してください。 たとえば、大きな画像を追加すると、レポートが大きくなる可能性があります。 たとえ機能していても、大きなサイズの項目をソース管理システムに格納するのは悪い習慣です。 画像などの静的リソースが多数ある場合は、項目のサイズを小さくする方法を検討してください。

変更をロール バックする

作業をバックアップした後、以前のバージョンに戻してワークスペースに復元したい場合があります。 以前のバージョンに戻すには、いくつかの方法があります。

  • [元に戻す] ボタン: 元に戻す操作は、変更がまだコミットされていない限り、加えた変更をすぐに元に戻す簡単かつ迅速な方法です。 各項目を個別に元に戻すこともできます。 取り消し操作の詳細については、こちらをご覧ください。

  • 古いコミットに戻す: UI で以前のコミットに直接戻す方法はありません。 最善のオプションは、git revert または git reset を使用して、古いコミットを HEAD に昇格させる方法です。 これを行うと、更新があることがソース管理ペインに示され、その新しいコミットでワークスペースを更新できます。

データが Git に格納されていないため、データ項目を古いバージョンに戻すと既存のデータが壊れる可能性があり、その場合はデータを削除する必要が発生したり、操作が失敗したりする可能性があることを考慮してください。 変更を元に戻す前に、これを事前に確認してください。

"プライベート" ワークスペースの操作

分離して作業する場合は、分離された環境として別のワークスペースを使用します。 ブランチの操作に関するセクションで、作業環境を分離する方法の詳細を参照してください。 自分とチームに最適なワークフローを実現するために、次の点を考慮してください。

  • ワークスペースのセットアップ: 作業を開始する前に、新しいワークスペースを作成し (まだワークスペースがない場合)、 ワークスペースを Fabric 容量に割り当てることができ、ワークスペースで作業するためのデータにアクセスできることを確認します。

  • 新しいブランチの作成: "メイン" ブランチから新しいブランチを作成して、最新バージョンのコンテンツを利用できるようにします。 また、適切なコンテンツをワークスペースにプルできるように、ブランチ内の正しいフォルダーに接続してください。

  • 小さな頻繁な変更: マージが容易で競合が発生する可能性が低い小さな増分変更を行うのが Git のベスト プラクティスです。 それが不可能な場合は、自分で競合を解決できるように、まずメインからブランチを更新してください。

  • 構成の変更: 必要に応じて、ワークスペースの構成を変更して、作業の生産性を向上させます。 一部の変更には、項目間の接続、異なるデータ ソースへの接続、または特定の項目のパラメーターに対する変更が含まれる場合があります。 コミットしたものはすべてコミットの一部になり、誤ってメイン ブランチにマージされる可能性があることを覚えておいてください。

クライアント ツールを使用して作業内容を編集する

これをサポートするアイテムおよびツールについては、セマンティック モデルとレポートでは Power BI Desktop、Notebooks では VSCode など、オーサリングのクライアント ツールを使用して作業する方が簡単な可能性があります。これらのツールはローカル開発環境にできます。 作業が完了したら、リモート リポジトリに変更をプッシュし、ワークスペースを同期して変更をアップロードします。 作成している項目のサポートされている構造を操作していることを確認してください。 わからない場合は、まず、ワークスペースに既に同期されているコンテンツを含むリポジトリを複製して、そこから作成を開始します。構造は既にそのリポジトリに配置されています。

ワークスペースとブランチの管理

ワークスペースは一度に 1 つのブランチにのみ接続できるため、これを 1 対 1 のマッピングとして扱うことをお勧めします。 ただし、必要なワークスペースの量を減らすには、次のオプションを検討してください。

  • 必要なすべての構成を備えたプライベート ワークスペースを開発者が設定した場合、開発者はそのワークスペースを今後作成するブランチ用に引き続き使用できます。 スプリントが完了すると、変更がマージされ、新しいタスクが開始されます。そのときに接続を同じワークスペース上の新しいブランチに切り替えるだけで済みます。 スプリントの途中で突然バグを修正する必要がある場合にも、これを行うことができます。 ブランチを Web 上の作業ディレクトリと考えてください。

  • クライアント ツール (VS Code、Power BI Desktop など) を使用している開発者はワークスペースを使用する必要がない場合があります。 ワークスペースを使用せずに、ブランチを作成し、変更をそのブランチにローカルにコミットして、それらの変更をリモート リポジトリにプッシュし、メイン ブランチに対する pull request を作成することができます。 ワークスペースは、すべてが実際のシナリオで動作することをチェックするためのテスト環境としてのみ必要です。 それをいつ実行するかを決めるのは開発者です。

Git レポジトリでアイテムを複製する

Git レポジトリでアイテムを複製するには:

  1. アイテム ディレクトリ全体をコピーします。
  2. logicalId を、その接続されたワークスペース固有のものに変更します。
  3. 元のアイテムと区別し、重複する表示名エラーを回避するため表示名を変更します。
  4. 必要に応じて任意の依存関係で logicalId および/またはディスプレイ名を更新します。

テスト

このセクションでは、デプロイ パイプラインのテスト ステージを操作するためのガイダンスを提供します。

運用環境をシミュレートする

提案した変更が運用ステージにどのように影響するかを確認することが重要です。 デプロイ パイプラインのテスト ステージを使用すると、テスト目的で実際の運用環境をシミュレートできます。 または、Git を別のワークスペースに接続することで、これをシミュレートすることもできます。

テスト環境では、次の 3 つの要素に対応していることを確認してください。

  • データ ボリューム

  • 使用量ボリューム

  • 運用環境と同様の容量

テスト時には、運用ステージと同じ容量を使用できます。 ただし、同じ容量を使うと、ロード テスト中に運用環境が不安定になることがあります。 運用環境が不安定にならないようにするには、運用環境の容量のリソースに似た別の容量を使ってテストします。 余計なコストが発生しないように、テスト時間分だけ支払えば済む容量を使います。

運用環境をシミュレートするテスト環境を備えたデプロイ パイプラインを示す図。

配置ルールを実際のデータ ソースで使用する

テスト ステージを使用して実際のデータ使用をシミュレートする場合は、開発とテストのデータ ソースを分離することをお勧めします。 開発データベースは比較的小さくする必要があるため、テスト データベースは運用データベースにできるだけ類似したものにする必要があります。 データ ソース ルールを使用して、テスト ステージでデータ ソースを切り替えるか、デプロイ パイプラインで作業しない場合は接続をパラメーター化します。

加えた変更は、依存項目にも影響を与える可能性があります。 テスト中に、変更が既存の項目のパフォーマンスに影響したり、パフォーマンスを壊滅的に低下させたりしないことを確認します。既存の項目は更新された項目に依存している可能性があります。

影響分析を使用すると、関連する項目を簡単に見つけることができます。

データ項目の更新

データ項目は、データを格納する項目です。 Git の項目の定義は、データの格納方法を定義します。 ワークスペース内の項目を更新するときに、その定義がワークスペースにインポートされ、既存のデータに適用されます。 データ項目を更新する操作は、Git パイプラインとデプロイ パイプラインでも同じです。

定義に変更が適用されるときにデータを保持する場合は、項目ごとに機能が異なるため、変更を適用するときは注意が必要です。 最も安全な方法で変更を適用するのに役立つプラクティスを次に示します。

  • 変更の内容と、変更が既存のデータに与える影響を事前に把握します。 コミット メッセージを使用して、加えられた変更を説明します。

  • テスト データを使用して項目が変更をどのように処理するかを確認するには、まず変更を開発またはテスト環境にアップロードします。

  • すべてがうまくいった場合は、運用環境での予期しない動作を最小限に抑えるために、実際のデータ (または可能な限りそれに近いデータ) を使用してステージング環境で変更をチェックすることをお勧めします。

  • Prod 環境を更新するときに最適なタイミングを考慮して、データを使用するビジネス ユーザーにエラーが与えるかもしれない損害を最小限に抑えます。

  • デプロイ後、Prod でデプロイ後にテストして、すべてが期待どおりに動作していることを確認します。

  • 一部の変更は常に破壊的変更と見なされます。 うまくいけば、上記の手順は、運用の前にそれらの変更を追跡するのに役立ちます。 Prod で変更を適用し、データを回復して通常の状態に戻し、ビジネス ユーザーのダウンタイムを最小限に抑える方法を計画します。

アプリをテストする

アプリを通じて顧客にコンテンツを配布する場合は、アプリを運用環境にデプロイする前にアプリの新しいバージョンを確認してください。 各デプロイ パイプライン ステージには独自のワークスペースがあるため、開発ステージおよびテスト ステージにアプリを簡単に発行および更新できます。 アプリを発行および更新すると、自分がエンド ユーザーの観点でアプリをテストできます。

重要

デプロイ プロセスには、アプリのコンテンツや設定の更新は含まれません。 コンテンツまたは設定に変更を適用するには、必要なパイプライン ステージでアプリを手動で更新します。

実稼働

このセクションでは、デプロイ パイプラインの運用ステージに関するガイダンスを提供します。

運用環境にデプロイできるユーザーを管理する

運用環境へのデプロイは慎重に行う必要があるため、特定の担当者のみがこの繊細な操作を管理できようにすることをお勧めします。 しかし、特定のワークスペースのすべての BI 作成者にパイプラインへのアクセス許可を付与したい場合もあります。 アクセス許可の管理には、運用環境のワークスペースのアクセス許可を使います。 他のユーザーは、ワークスペース内のコンテンツを表示する運用ワークスペース ビューアー ロールを持つことができますが、Git またはデプロイ パイプラインから変更を加えることはありません。

さらに、コンテンツ作成プロセスの一部であるユーザーに対してのみアクセス許可を有効にすることで、リポジトリまたはパイプラインへのアクセスを制限します。

運用ステージの可用性を保証するルールを設定する

配置ルールは、運用環境のデータが常に接続され、ユーザーが使用できるようにするための強力な方法です。 デプロイ規則を適用すれば、顧客が混乱なく関連情報を表示できることが保証された状態でデプロイを実行することができます。

セマンティック モデルで定義されたデータ ソースとパラメーター向けの本番環境展開ルールが設定されていることを確認してください。

運用アプリを更新する

UI を使用してパイプラインに展開すると、ワークスペースのコンテンツが更新されます。 関連付けられているアプリを更新するには、展開パイプライン API を使用します。 UI を使用してアプリを更新することはできません。 コンテンツ配布にアプリを使用する場合は、エンド ユーザーがすぐに最新バージョンを使用できるように、運用環境にデプロイした後にアプリを更新することを忘れないでください。

Git ブランチを使用した運用環境へのデプロイ

リポジトリは "単一の信頼できるソース" として機能するため、一部のチームにおいては、Git から異なるステージに直接、更新プログラムをデプロイする必要が生じることがあります。 これは、Git 統合で可能ですが、いくつかの考慮事項があります。

  • リリース ブランチを使用することをお勧めします。 すべてのデプロイの前に、ワークスペースの接続を新しいリリース ブランチに継続的に変更する必要があります。

  • ビルドまたはリリース パイプラインでソース コードを変更する必要がある場合、またはワークスペースにデプロイする前にビルド環境でスクリプトを実行する必要がある場合は、ワークスペースを Git に接続しても役に立ちません。

  • 各ステージにデプロイした後、そのステージに固有のすべての構成を必ず変更してください。

コンテンツのクイック修正

迅速な修正が必要な問題が運用環境に発生することがあります。 また、最初にテストを行わずに修正プログラムをデプロイすることは、好ましくありません。 そのため、常に開発ステージで修正を実装してから、残りのデプロイ パイプライン ステージにプッシュしてください。 開発ステージにデプロイすることで、運用環境にデプロイする前に、修正が機能することを確認できます。 パイプライン全体でのデプロイは、数分かかるのみです。

Git からのデプロイを使用している場合は、「Git ブランチ戦略を採用する」に記載されているプラクティスに従うことをお勧めします。

関連するコンテンツ