JA
English
Deutsch
Español
Français
Italiano
Português
Nederlands
Polski
Bahasa Indonesia
Русский
Українська
العربية
עברית
한국어Microsoft FabricをGitHubとAzure DevOpsにシームレスに統合する
By Mirko Peters · · Updated
モダンなデータ分析ワークロードを管理するうえで、堅牢なバージョン管理とガバナンスの確保は欠かせません。テクニカルリーダーとして、私たちは開発者のスピードとエンタープライズ水準のコンプライアンスのバランスを常に取る必要があります。そのため、Microsoft Fabricのワークスペースを GitHub や Azure DevOps などの外部リポジトリに接続することは、分析エンジニアリングにおける大きな転換点になっています。この記事では、シームレスな統合を確立する方法、デプロイの責任範囲を評価する方法、そして各プラットフォームの独自の強みを活かす方法を解説します。
Automatically translated with AI from the original post. Read the English original
モダンなデータ分析ワークロードを管理するうえで、堅牢なバージョン管理とガバナンスの確保は欠かせません。テクニカルリーダーとして、私たちは開発者のスピードとエンタープライズ水準のコンプライアンスのバランスを常に取る必要があります。そのため、Microsoft Fabricのワークスペースを GitHub や Azure DevOps などの外部リポジトリに接続することは、分析エンジニアリングにおける大きな転換点になっています。この記事では、シームレスな統合を確立する方法、デプロイの責任範囲を評価する方法、そして各プラットフォームの独自の強みを活かす方法を解説します。
このテーマをさらに深く掘り下げ、これらのエコシステムがどのように連携するかについての専門家による解説を聞きたい方は、ぜひ関連するポッドキャストエピソード GitHub vs Azure DevOps for Microsoft Fabric CI/CD をお聴きください。
GitHub vs Azure DevOps: 知っておきたい5つの意外な事実
- 出自の違いと機能の収束: どちらも CI/CD とコラボレーションを対象としていますが、GitHub はソーシャルなコーディングプラットフォームとして誕生し、Azure DevOps は Microsoft のエンタープライズ向け ALM ツール（Team Foundation Server）から発展したため、ワークフローとエンタープライズ統合は大きく異なります。
- パイプラインの移植性: Azure DevOps のパイプラインは YAML ベースのビルドを多くのプラットフォームで実行でき、クラシックパイプラインのタスクを再利用することもできます。一方、GitHub Actions はコミュニティが作成したアクションを集めた大規模なパブリックマーケットプレースを提供しています。そのため、移植性は、利用可能なマーケットプレースのアクションと、組み込みの Azure タスクライブラリのどちらを使うかに左右されることが多くなります。
- Boards と Issues の考え方の違い: Azure DevOps には、カスタマイズ可能なプロセステンプレートと、エンタープライズ向けの計画・レポート機能を備えた本格的な作業項目システム（Boards）が含まれています。一方、GitHub Issues はよりシンプルでソーシャルな仕組みです。「github vs azure devops」を比較する際に、両者で同じプロジェクト管理ができると想定しているチームにとっては意外な点かもしれません。
- エンタープライズのコンプライアンスとオンプレミスの選択肢: Azure DevOps Server は、規制の厳しい組織で求められることの多い、成熟したオンプレミスホスティングとコンプライアンス管理を提供します。GitHub は GitHub Enterprise Server を提供していますが、歴史的にはクラウドファーストのワークフローに重点を置いてきました。そのため、コンプライアンス要件の厳しいチームにとって両者は明確に異なる選択肢になります。
- 価格とユーザーモデルの違い: GitHub の価格とコラボレーターモデルはリポジトリと組織を中心としており、オープンソース向けには手厚い無料プランがあります。一方、Azure DevOps は一部の機能（Test Plans、Artifacts）でユーザー単位のライセンスを採用しており、大規模なエンタープライズのライセンス契約では、コストをより予測しやすい場合があります。「github vs azure devops」を比較する際には、意外と見落とされがちな要素です。
デプロイの責任範囲を解説
デプロイの責任範囲とは
デプロイの責任範囲とは、DevOps のプロセスにおけるすべてのステップを自分で管理できる状態を指します。コードが開発からデリバリーへどのように移行するかは、自分で決めます。DevOps ツールへのアクセス権を誰が持つか、変更をどのように追跡するかも管理します。自動化のルールを定め、チームがそれに従っていることを確認します。
コードと成果物
DevOps プラットフォームでは、ソースコードと成果物を扱います。これらはデリバリーパイプラインの基盤を形成します。最新の DevOps ツールにおけるデプロイの責任範囲を構成する主な要素は次のとおりです。
- ソースコードの追跡
- テスト
- デプロイ
- インフラストラクチャの管理
- ビルドの追跡
- シークレットの管理
- リリースの管理
これらの工程は DevOps ツールを使って自動化します。自動化によって更新をより速く届けられ、ミスも減らせます。コードを安全に保ち、成果物がテスト済みのバージョンと一致していることを確認します。ビルドとリリースを追跡し、環境間で一貫性を保ちます。
アクセスとガバナンス
DevOps ツールへのアクセスを管理し、ガバナンスポリシーを設定します。誰がコードを閲覧、編集、デプロイできるかを決めます。自動化を使ってルールを徹底し、アクティビティを監視します。ガバナンスによって、開発とデリバリーの各段階でチームが標準に従うことが保証されます。操作を記録し、変更を確認することで、ソフトウェア開発プロセスを守ります。
なぜ責任範囲が重要なのか
責任範囲を持つことで、DevOps 環境を自分でコントロールできるようになります。デリバリーパイプラインをリスクから守り、開発を安全に保てます。規制への準拠を維持し、運用上のコントロールを支えます。
devopsツールを使って、堅牢なガバナンスの枠組みを構築します。チームの自律性が高まり、各チームが独立して作業できるようになります。リスクを管理し、デリバリープロセスの信頼性を保てます。自動化は、開発とデリバリーをより効率的にすることで、これらの目標を支えます。
ヒント: devopsパイプラインを自分たちで管理できるようになると、変更に素早く対応し、ソフトウェア開発を計画どおりに進め続けられます。
devopsツールについて賢く判断するには、デプロイの所有権を理解する必要があります。デリバリーの速度が向上し、コードを保護しながら、開発プロセスを管理下に置き続けられます。
GitHubの所有権モデル
コードとアーティファクトの保管
GitHubはソースコード管理の中心的な場所として使えます。コードをgithub.comにプッシュすると、すべての変更の履歴が明確に残ります。誰がいつ更新したのかを追跡しやすくなります。必要に応じて、パブリックリポジトリとプライベートリポジトリを使い分けてコードを保存できます。GitHub Enterpriseを使用すると、高度なセキュリティやコンプライアンスのツールなど、大規模な組織向けの追加機能を利用できます。
デプロイ用のアーティファクトについては、GitHubはGitHub Packagesを提供しています。このサービスを使うと、ビルドの成果物、コンテナーイメージ、その他のファイルをコードと一緒に保存できます。これらのアーティファクトには、ワークフローから直接アクセスできます。ただし、GitHub Packagesが提供するのは、作成日やダウンロード数といった基本的なメタデータのみです。アーティファクト管理のためにカスタムプロパティを追加したり、高度なクエリを使用したりすることはできません。JFrogなどの他のプラットフォームでは、メタデータやクエリの選択肢がより豊富です。
アクセス許可
github.com上でコードを閲覧・変更できる人を制御します。ユーザーとチームにロールを割り当て、各メンバーが必要なアクセス権だけを持つようにします。これは最小特権の原則に従うものです。組織内にチームを作成し、チームごとに異なるアクセス許可を設定できます。たとえば、開発者には書き込み権限を与えつつ、管理者権限は信頼できるメンバーに限定するといった使い方が考えられます。
GitHubをID・アクセス管理（IAM）システムと連携させると、アクセス管理を自動化できます。チームの変化に合わせて、ユーザーを簡単に追加または削除できるようになります。また、明確なアクセス制御ポリシーを定め、定期的に見直すことも大切です。GitHubではアクセスログを監査して、不審なアクティビティを見つけることもできます。
- ロールとアクセス許可は、リポジトリ、組織、またはエンタープライズの各レベルで割り当てます。
- 重要なコード変更にはコードオーナーを使ってレビューを必須にします。
- 管理者アクセスは制限し、必要な場合にのみ使用します。
- 不正な操作がないか、監査ログを定期的に確認します。
ガバナンスとコンプライアンス
デプロイを安全かつコンプライアンスに適合した状態に保つには、強固なガバナンスが必要です。GitHubには、これを管理するためのツールがいくつか用意されています。ワークフローをプロジェクト間で再利用できるため、時間を節約でき、一貫性も確保できます。GitHub Actionsを使うと、デプロイを自動化し、環境ごとのルールを適用できます。
アーティファクトのアテステーションを使うと、デプロイファイルが改ざんされていないことを検証できます。GitHubは、クラウドプラットフォームへの安全なデプロイのために OpenID Connect（OIDC）をサポートしています。誰がいつデプロイできるかのルールを設定して、デプロイを管理できます。また、GitHubではデプロイ履歴を確認できるため、監査やコンプライアンスチェックに役立ちます。
注: GitHub ActionsはMicrosoft Fabricと統合されているため、同じガバナンスの制御を使って、デプロイの自動化と分析ソリューションの管理を行えます。
セキュリティに関する考慮事項
GitHubをデプロイパイプラインで使用する際は、セキュリティに特に注意する必要があります。セキュリティの脅威は、ワークフローの多くの地点で発生し得ます。攻撃者は、ソースコードやビルドのアーティファクトにマルウェアを注入しようとする可能性があります。アクセスキーやパスワードなどの機密データも、ベストプラクティスに従わないと露出するおそれがあります。不正アクセスにより、攻撃者がパイプラインや本番環境を支配する可能性があります。古い依存関係には脆弱性が含まれることがあり、システム全体を脅かすおそれがあります。
強力なアクセス制御を使って、GitHubリポジトリを保護する必要があります。すべてのユーザーに対して二要素認証を有効にしてください。シークレット管理を使うと、資格情報やトークンを安全に保てます。機密情報をコードに直接保存することは避けてください。また、アクセス許可を定期的に見直し、不要になったユーザーのアクセス権は削除してください。
ヒント: GitHubの組み込みツールと外部ソリューションを組み合わせると、セキュリティ態勢を強化できます。追加の保護として、サードパーティのスキャナーを使用したり、クラウドセキュリティプラットフォームと統合したりすることもできます。
リポジトリとしてGitHubから始める - チェックリスト（GitHub と Azure DevOps の比較）
GitHubをコードリポジトリとして使い始めるための実践的なチェックリストです。
- GitHub アカウントを作成するか、サインインします
- チームのオーナーシップについて、個人アカウントと組織のどちらを使うかを決めます
- 新しいリポジトリを作成し（パブリックまたはプライベート）、適切な公開範囲を選択します
- わかりやすいリポジトリ名を付け、内容を説明する README.md を追加します
- プロジェクトのニーズに合った LICENSE ファイルを追加します
- 使用する言語やフレームワークに合わせた .gitignore を追加します
- 既定のブランチ（main）でリポジトリを初期化し、ブランチ保護ルールを設定します
- CODEOWNERS とコントリビューション ガイドライン（CONTRIBUTING.md）を設定します
- Issue テンプレートとプル要求テンプレートを設定します
- Issue の追跡用に、ラベル、マイルストーン、プロジェクト ボードを設定します
- CI/CD 用の GitHub Actions ワークフローを設定するか、既存のパイプラインと統合します
- CI、デプロイ、サードパーティ サービス用のリポジトリ シークレットを追加します
- ブランチ保護ルールを設定します。必須のレビュー、状態チェック、必要に応じて必須の署名付きコミットを含めます
- 依存関係の更新とセキュリティ アラートのために Dependabot を有効にします
- セキュリティ機能（コード スキャン、シークレット スキャン、脆弱性アラート）を有効にします
- CI、ChatOps、外部サービス用の Webhook または統合を設定します
- 共同作成者やチーム メンバーを招待し、リポジトリのアクセス許可を設定します
- 既存のリポジトリと Issue を移行します（Azure DevOps から移行する場合は、移行を計画し、作業項目をマッピングします）
- リポジトリ構造、開発ワークフロー、リリース プロセスを wiki または docs フォルダーに文書化します
- リリース、デプロイ、重要なワークフローの監視とアラートを設定します
- ワークフローと代替手段（GitHub と Azure DevOps の比較）を確認し、CI/CD とプロジェクト管理の選択を最適化します
- リポジトリへのアクセス、シークレット、セキュリティ設定を定期的に監査します
Azure DevOps のオーナーシップ モデル
リポジトリとパイプライン
Azure DevOps を使うと、コード、成果物、デプロイ プロセスを管理するための統合プラットフォームが得られます。Azure DevOps サービスは、コード リポジトリ、作業の追跡、テスト ツール、成果物の保存を一元化します。この統合により、ソフトウェア提供ライフサイクルのすべての段階を管理できます。各パイプラインの実行を特定のコミット、プル要求、作業項目までたどれるため、開発プロセスを明確に把握できます。
Azure DevOps パイプラインは、リソースへのアクセスに ID を使用します。これらの ID は、コレクション レベルまたはプロジェクト レベルで設定できます。プロジェクト レベルの ID を使うと、各プロジェクトに必要なリソースのみにアクセスを制限でき、セキュリティが高まります。チェックとパイプラインのアクセス許可を使えば、リポジトリ リソースの保護も強化できます。これにより、コードやデプロイ ワークフローのオーナーシップと編集権限を管理できます。
Azure DevOps は合理化された CI/CD をサポートしており、ビルド、テスト、デプロイを自動化できます。Azure Pipelines を使うと、継続的インテグレーションと継続的デリバリーが実現でき、更新を迅速かつ確実に提供できます。Microsoft は Azure DevOps をクラウド コンピューティングと連携しやすいように設計しており、ニーズの拡大に合わせてプロジェクトを簡単にスケールできます。
アクセス制御
ロールベースのアクセス制御を使用して、Azure DevOps サービスにアクセスできるユーザーを管理します。このモデルでは、ロールに基づいてアクセス許可を割り当てるため、各ユーザーは必要なアクセスのみを取得します。ユーザーをセキュリティ グループにまとめ、組織、プロジェクト、またはオブジェクトのレベルでアクセス許可を割り当てることができます。Microsoft は最小特権の原則に従うことを推奨しています。つまり、ユーザーには作業に必要なアクセス許可のみを付与します。
- ユーザーとグループにロールを割り当て、アクセスを正確に制御します。
- セキュリティ グループを使用して、さまざまなレベルでアクセス許可を管理します。
- アクセス許可を定期的に確認し、監査して、予期しない使用がないかを確認します。
ガバナンスとポリシー
安全で信頼性の高いデプロイには、強力なガバナンスが欠かせません。Azure DevOps は、ブランチ ポリシー、アクセス制御、カスタム ロールを通じてガバナンスを適用します。ブランチ ポリシーを使うと、コードをマージする前にチェックと要件を設定でき、品質の確かなコードだけが本番環境に到達します。最小特権の原則に基づいてセキュリティ プリンシパルにロールを割り当てることができ、不正アクセスのリスクを減らせます。
- マージ前にコード レビューとチェックを必須にするブランチ ポリシーを設定します。
- 本番環境での破壊的な操作を防ぐため、サービス プリンシパルにカスタム ロールを割り当てます。
- アクセス制御を使って、重要な環境にデプロイできるユーザーを制限します。
ヒント: Azure DevOps のガバナンス設定を定期的に確認し、デプロイのセキュリティとコンプライアンスを維持してください。
セキュリティとコンプライアンス
管理デプロイを行う際には、強固なセキュリティとコンプライアンスの統制が必要です。Azure DevOps には、コード、データ、ワークフローを保護するための幅広いツールが用意されています。組み込みのセキュリティ機能を使うことで、開発プロセスを安全に保ち、業界標準に沿った状態を維持できます。
Azure DevOps では、ロールベースのアクセス制御により、リソースの閲覧や変更を行えるユーザーを制限します。ユーザーやグループにアクセス許可を割り当て、適切な担当者だけがアクセスできるようにします。また、サービス接続を使うと、パイプラインが他の Azure サービスとどのようにやり取りするかを制御できます。これにより、不正な操作のリスクを減らせます。
ヒント: Azure DevOps のセキュリティ設定を定期的に確認してください。チームの規模が拡大したり、プロジェクトの内容が変わったりした際には、ポリシーとアクセス許可を更新しましょう。
Azure DevOps をリポジトリとして使い始めるためのチェックリスト(GitHub と Azure DevOps の比較)
- Azure DevOps の組織を作成するか、既存の組織にサインインします
- 新しいプロジェクトを作成し(公開範囲をプライベートまたはパブリックから選択)、バージョン管理として Git を選択します
- 最初のリポジトリを作成するか、既存のリポジトリをインポートします(GitHub またはローカルから)
- わかりやすい説明を記載した README.md とライセンスファイルを追加します
- プロジェクトの言語やフレームワークに合わせた .gitignore を追加します
- ブランチ戦略と命名規則を定義します(main、develop、feature/*、hotfix/*)
- main ブランチを保護します。ブランチポリシー、必須レビュアー、ステータスチェックを有効にします
- プルリクエストのテンプレートと、コントリビューター向けガイドラインを作成します
- リポジトリのアクセス許可とグループ(Readers、Contributors、Project Administrators)を設定します
- デプロイ用のサービス接続を設定します(Azure、AWS、Docker レジストリ、外部の Git プロバイダー)
- CI パイプライン(Azure Pipelines の YAML またはクラシック)を作成し、プルリクエストでビルドを検証します
- 環境ごと(dev/stage/prod)の CD パイプラインまたはリリースパイプラインを作成し、承認ゲートを設定します
- Boards と連携します。作業項目を作成し、コミットやプルリクエストを作業項目にリンクします
- 外部連携用の Webhook またはサービスフックを設定します(Slack、Teams、Jenkins など)
- リポジトリのブランチ保持とビルドの保持に関するポリシーを設定します
- 監査を有効にし、必要なコンプライアンスとセキュリティの統制を設定します
- コードスキャン、セキュリティ分析、依存関係チェックを設定します(GitHub には追加のツールが用意されている場合があるため、必要に応じて比較してください)
- パッケージのホスティングが必要な場合は、Artifacts のフィードを設定します(NuGet、npm、Maven)
- Wiki またはドキュメントサイトを作成し、適切な場合はドキュメントをリポジトリ内で管理します
- GitHub から移行する場合は、移行手順を計画します。リポジトリ、Issue、プルリクエスト、CI/CD、サービスアカウントを対応付けます
- チームメンバーを招待し、各自のアカウントからアクセスできることを確認します
- エンドツーエンドの初期テストを実施します。クローン、コミット、プッシュ、プルリクエストの作成、パイプラインの実行、テスト環境へのデプロイまでを確認します
- 利用状況とパイプラインを監視し、ポリシーと自動化を継続的に改善します
Microsoft Fabric との統合
Git 統合
Microsoft Fabric のワークスペースを GitHub リポジトリに直接接続できます。この接続により、分析プロジェクトに対して強力なバージョン管理を行えます。ワークスペースを GitHub の develop ブランチにリンクします。この構成により、すべての変更を追跡し、必要に応じて以前の状態に戻すことができます。Microsoft Fabric のデプロイメント パイプラインを使うと、開発からテスト、そして本番へとコンテンツを移行できます。このプロセスにより、環境間の同期の問題を回避しやすくなります。
安定した機能をリリースする場合は、リリースブランチを作成します。デプロイメント パイプラインを使って、これらの変更を本番環境に反映します。緊急の問題を修正する必要がある場合は、ホットフィックスブランチを作成します。このブランチを main ブランチにマージしてからデプロイします。環境ごとに個別のデータベースを使用することをお勧めします。この方法により、テストや開発の過程での誤った変更から本番データを保護できます。
Azure DevOps および GitHub による CI/CD
Azure DevOps や GitHub Actions を使って、Microsoft Fabric に CI/CD パイプラインを設定できます。これらのツールを使うと、ビルド、テスト、デプロイの各手順を自動化できます。デプロイメント パイプラインには、用途がひと目でわかる明確で説明的な名前を付けてください。これにより、各パイプラインの目的を簡単に識別できます。開発、テスト、本番などのパイプラインの段階ごとに、既存のワークスペースを使うことも、新しいワークスペースを作成することもできます。
段階間でコンテンツを頻繁に比較してください。この確認により、すべての項目が正しくデプロイされたことを確かめられます。パイプラインの任意のワークスペースからアプリケーションを公開できます。この手順により、エンドユーザーは最終デプロイの前に機能をテストできます。開発者や機能ごとに別々のブランチを維持してください。この方法は、マージの競合を避けるのに役立ちます。Gitflow のような堅実なブランチ戦略を使うと、開発、リリース、ホットフィックスを管理しやすくなります。
データガバナンス
Microsoft Fabricは、データライフサイクルのあらゆる段階にガバナンスを組み込んでいます。データの収集、保存、分析を1つの環境で管理できます。Microsoft Purviewはデータをカタログ化し、そのリネージ（系統）を追跡します。OneLakeは一元化されたストレージを提供するため、ガバナンスポリシーを簡単に適用できます。Microsoft Entra IDによりロールベースのアクセス制御を利用でき、誰がデータを閲覧または変更できるかを決めることができます。
ガバナンスポリシーはOneLakeレベルで適用します。これらのルールはワークスペースやデータセットをまたいでデータに追従します。このアプローチにより、データの取り扱いは一貫性を保ち、迅速になります。ワークスペースごとに個別のルールを設定する必要はありません。Microsoft Fabricの設計により、データの増加に伴ってもコントロールを維持し、コンプライアンス要件を満たしやすくなります。
セキュリティとコンプライアンス
Microsoft Fabricでデータやデプロイを管理する際は、強力なセキュリティとコンプライアンスの管理が必要です。このプラットフォームには、情報を保護し規制要件を満たすための高度なツールが用意されています。Data Factoryパイプライン内の機密データを分類し、保護することができます。これにより、重要な情報を不正アクセスから守ることができます。
Microsoft Fabricは、Microsoft Defender for Cloud Appsと連携します。この統合により、運用の可視性と制御が向上します。アクティビティを監視し、リスクの高い動作に対してアラートを設定できます。データリネージを追跡することalso可能です。この機能により、データがシステム内をどのように移動するかを把握できます。この情報を使ってコンプライアンスを検証し、機密データの流れを理解することができます。
ヒント：セキュリティとコンプライアンスの設定は頻繁に見直しましょう。定期的な確認により、新たなリスクに先手を打ち、データを安全に保つことができます。
GitHub vs Azure DevOps vs Fabric：所有権の比較
リポジトリの場所
コードがどこに存在するかを把握しておく必要があります。GitHub vs Azure DevOpsの比較において、これは重要なポイントです。GitHubはリポジトリをクラウドに保存します。パブリックとプライベートのどちらかを選択できます。共有や共同作業が容易なため、多くのオープンソースプロジェクトがGitHubを利用しています。Azure DevOpsもコードをクラウドに保存しますが、プライベートなエンタープライズ向けプロジェクトに重点を置いています。コードを誰が閲覧・変更できるかを、より細かく制御できます。Microsoft Fabricは、バージョン管理のためにGitHubとAzure DevOpsの両方に接続します。分析プロジェクトはFabricで管理しますが、実際のコードは接続先のリポジトリにあります。
ご自身のニーズに合ったプラットフォームを選びましょう。オープンな共同作業を重視するならGitHubが適しています。厳格な管理が必要であれば、Azure DevOpsがより多くの選択肢を提供します。Microsoft Fabricではどちらも利用できるため、ご自身のワークフローに合わせることができます。
アーティファクト管理
アーティファクト管理とは、プロジェクトが作成するビルド成果物、パッケージ、ファイルを扱う方法のことです。GitHub vs Azure DevOpsの比較では、大きな違いが見られます。GitHubはアーティファクトの保存にGitHub Packagesを使用します。パッケージの保存や共有といった基本的な機能が利用できます。Azure DevOpsはAzure Artifactsを提供しており、より高度な管理機能があります。バージョンの管理、フィードの設定、利用状況の追跡が可能です。Microsoft Fabricは、Power BIレポートやセマンティックモデルなど、分析アーティファクトに重点を置いています。バージョン管理のためにリポジトリと連携し、環境間でアーティファクトを移動するためにデプロイパイプラインを使用します。
ヒント：最小特権の原則を適用しましょう。ユーザーには必要最小限のアクセス許可のみを与えます。これによりリスクが低減され、セキュリティを維持しやすくなります。
ガバナンスとコンプライアンス
デプロイを保護し、業界標準を満たすためには、強力なガバナンスとコンプライアンスが必要です。GitHub、Azure DevOps、Microsoft Fabricのそれぞれが、これらのニーズに対して異なるツールとアプローチを提供しています。
GitHubは柔軟なガバナンスを提供します。ブランチ保護ルールを設定し、コードレビューを必須にし、CODEOWNERSファイルを使用できます。これらの機能により、誰がコードを変更できるかを管理できます。また、監査ログを使用して、リポジトリ内のアクションを追跡することもできます。
Azure DevOpsはエンタープライズ向けのガバナンスに重点を置いています。ブランチポリシー、承認ゲート、カスタムロールを設定できます。これらの管理機能により、プロジェクト全体で標準を徹底できます。Azure DevOpsでは、作業項目の追跡を利用して、コードの変更をビジネス要件に紐づけることもできます。
Microsoft Fabricは、データ分析のワークフローにガバナンスをもたらします。Microsoft Purviewを使ってデータのカタログ化とリネージの追跡を行います。ポリシーはOneLakeレベルで設定し、すべてのワークスペースに適用されます。この一元的なアプローチにより、データの増加に伴うコンプライアンス管理が容易になります。
ヒント: ガバナンス設定は定期的に見直してください。強固なガバナンスは、コンプライアンス要件への適合を支え、デプロイを安全に保つのに役立ちます。
セキュリティ態勢
コード、データ、デプロイをさまざまな脅威から保護する必要があります。プラットフォームごとに、利用できるセキュリティ機能と制御の内容は異なります。
GitHub では、二要素認証、シークレット管理、ブランチ保護によってリポジトリを保護できます。GitHub Actions を使うと、セキュリティスキャンや脆弱性チェックを自動化できます。
azure devops には、高度なセキュリティ制御機能があります。ロールベースのアクセスを使って、アクセス許可を制限できます。azure devops ではシークレットを安全に保存し、パイプラインに関連付けることができます。
Microsoft Fabric はデータセキュリティに重点を置いています。Microsoft Defender for Cloud Apps を使ってアクティビティを監視し、リスクの高い動作に対するアラートを設定できます。パイプライン内の機密データを分類して保護することもできます。
注: プラットフォームのセキュリティ機能とベストプラクティスを組み合わせる必要があります。チームを教育し、設定を見直し、脅威の変化に合わせてポリシーを更新してください。
実際の DevOps シナリオ
GitHub によるオープンソース
オープンソースプロジェクトに取り組む場合、github ではデプロイの所有権を簡単に管理できます。デプロイプロセスを自動化し、コードを変更するたびにプロジェクトを公開状態に保つことができます。一般的なオープンソースの DevOps ワークフローにおける所有権の仕組みは、次のとおりです。
- github のパブリックリポジトリにコードをプッシュします。
- main ブランチへのプッシュのたびに、自動デプロイが実行されます。
- デプロイに承認を申請したり、承認を待ったりする必要はありません。
- 自分の AWS アカウントなどの類似サービスを使用して、クラウドインフラストラクチャを引き続き管理できます。
- プロジェクトは、常に本番環境レベルのインフラストラクチャ上で公開され続けます。
Azure DevOps による企業での利用
企業環境では、複雑なプロジェクトを管理するために azure devops を使用することがよくあります。スピード、セキュリティ、コンプライアンスのバランスを取る必要があります。このような環境では、所有権の管理が難しくなることがあります。チームの役割と責任を明確に定める必要があります。azure devops では、アクセス許可を割り当て、ロールベースのアクセス制御を使用することで、これを実現できます。
Fabric によるデータ分析
データ分析プロジェクトを管理する場合、Microsoft Fabric では強力なデプロイの所有権を確保できます。ワークスペース内の各アイテムについて、誰がデプロイ、編集、表示できるかを制御できます。分析資産を明確に管理できます。新しいアイテムをデプロイすると、そのアイテムの所有者になります。アイテムが既に存在するステージにデプロイする場合、所有権は変わりません。
ヒント: Microsoft Fabric のデプロイパイプラインとワークスペースのアクセス許可を活用すると、データを安全に保ちながらチームの生産性を高めることができます。
ハイブリッド デプロイ
デプロイの管理には、複数のプラットフォームを使う必要があることが少なくありません。これは大規模な組織でよく見られるほか、異なるツールの長所を組み合わせたい場合にも起こります。ハイブリッドデプロイでは、ソース管理に GitHub、パイプラインに Azure DevOps、分析に Microsoft Fabric を使用できます。これらのプラットフォームを連携させることで、ニーズに合ったワークフローを構築できます。
ヒント: 各プラットフォームでアクセスとガバナンスの設定を見直してください。コードのデプロイや変更を行えるのが適切な担当者だけになるようにしてください。これにより、ワークフローの安全性を保てます。
適切な DevOps プラットフォームの選択
所有権に関する重要な質問
DevOps プラットフォームを選ぶ前に、適切な質問をする必要があります。これらの質問により、各ツールが所有権、ガバナンス、統合をどのように扱うかを把握できます。次の点を検討してください。
- コードとアーティファクトへのアクセスは、誰が制御していますか？
- プラットフォームは、ガバナンスとコンプライアンスをどのように適用しますか？
- デプロイでメタデータが欠けている場合に、リマインダーを自動化できますか？
- プラットフォームは、既存のツールとの統合をサポートしていますか？
- プラットフォームは、サービスの所有権とメタデータをどのように扱いますか？
ヒント: 早い段階でこれらの質問を検討してください。混乱を避けられ、DevOps ワークフローの強固な土台を築けます。
プラットフォームの強み
DevOps プラットフォームにはそれぞれ独自の強みがあります。プロジェクトのニーズとこれらの強みを照らし合わせる必要があります。すばやく導入して容易に統合したい場合は、GitHub Actions を使用できます。複雑なワークフロー向けに高度な制御が必要な場合は、Azure DevOps が適しています。Microsoft Fabric は、統合された分析とガバナンスを提供します。バージョン管理とデプロイのために、ワークスペースを GitHub または Azure DevOps に接続できます。
注: ワークフローとガバナンスの要件に合ったプラットフォームを選ぶ必要があります。DevOps の所有権について、各プラットフォームが異なる強みを備えています。
GitHub、Azure DevOps、Microsoft Fabric がコード、成果物、アクセス、ガバナンスをどのように管理しているかを理解すると、デプロイの責任の所在が明確になります。セキュリティとコンプライアンスの要件に合ったプラットフォームを選んでください。エンドポイント管理ポリシーを定義し、チーム間で共同の責任体制を確立して、不可欠なセキュリティ制御を特定します。リスクに先手を打つために、プラットフォームの機能を定期的に確認してください。プラットフォームの選択は、公平性、信頼性、説明責任を含む責任ある AI ポリシーと整合させてください。このアプローチにより、データを保護し、強固なガバナンスを維持できます。
関連するエピソードを直接お聴きいただくと、このテーマについてさらに学びを深められます: GitHub vs Azure DevOps for Microsoft Fabric CI/CD。
よくある質問
DevOps プラットフォームにおけるデプロイの責任とは何ですか?
デプロイの責任とは、コード、成果物、アクセス、ガバナンスを自分で管理することを意味します。誰がデプロイできるかを決め、変更を追跡し、ルールを適用します。この責任により、プロジェクトを保護し、コンプライアンスを維持できます。
GitHub、Azure DevOps、Microsoft Fabric はアクセス制御をどのように処理しますか?
各プラットフォームでロールとアクセス許可を設定します。GitHub ではチームとコードオーナーを使用します。Azure DevOps ではセキュリティ グループとロールベースのアクセスを使用します。Microsoft Fabric では、ワークスペースのアクセス許可に Microsoft Entra ID を利用します。
3 つのプラットフォームすべてでデプロイを自動化できますか?
はい、GitHub Actions、Azure Pipelines、または Microsoft Fabric のデプロイ パイプラインを使って自動化できます。自動化により、更新をより速く提供でき、エラーも減らせます。
Microsoft Fabric は GitHub や Azure DevOps とどのように統合されますか?
Fabric ワークスペースを GitHub または Azure DevOps のリポジトリに接続します。この統合により、バージョン管理、自動デプロイ、統合された分析ガバナンスが得られます。
デプロイを保護するセキュリティ機能にはどのようなものがありますか?
二要素認証、シークレット管理、自動セキュリティ スキャンを使用します。Azure DevOps では承認ゲートと Defender for Cloud を追加できます。Microsoft Fabric では、データ損失防止とプライバシー管理ツールを利用できます。
これらのプラットフォームでコンプライアンスをどのように管理しますか?
ブランチ ポリシー、監査ログ、ガバナンス ルールを設定します。Azure DevOps と Microsoft Fabric は、GDPR や ISO などのコンプライアンス フレームワークをサポートしています。GitHub Enterprise は、組織向けに高度なコンプライアンス ツールを提供しています。
Microsoft Fabric でデプロイされた分析資産の所有者は誰ですか?
新しいアイテムをデプロイすると、あなたが所有者になります。既存のアイテムがあるステージにデプロイしても、所有権は変わりません。ワークスペースのロールとアクセス許可により、アクセスを管理できます。
Azure DevOps と GitHub の主な違いは何ですか?
Azure DevOps（ado）は、Azure Boards、Pipelines、Repos、Test Plans、成果物管理を提供する開発者向けツール スイートで、エンタープライズのプロジェクト管理と CI/CD に重点を置いています。一方の GitHub は、Git リポジトリ、プルリクエスト、開発者コミュニティを中心とした Git 中心のプラットフォームで、GitHub Repos、GitHub Enterprise Cloud、GitHub Actions などの機能があります。Azure DevOps は、統合された作業項目の追跡や Visual Studio Team Services（TFS）の系譜から選ばれることが多く、GitHub は大規模なオープンソース エコシステムと最新のコラボレーション機能を提供します。
バージョン管理には Azure Repos と GitHub Repos のどちらを使うべきですか?
どちらも Git リポジトリとバージョン管理をサポートしています。Azure Repos は Azure Boards や Azure Pipelines と密接に統合されているため、Microsoft Azure DevOps のワークフローを使うチームに適しています。GitHub Repos（GitHub でホスト）は、パブリックおよびプライベートのリポジトリ、オープンソース プロジェクトの管理、コミュニティからの貢献、プルリクエスト ワークフローなどの機能に優れています。統合された Azure Boards を重視するか、より広範な GitHub プラットフォームとコミュニティを重視するかで選択してください。
Azure Repos から GitHub にリポジトリを移行できますか?
はい、Azure Repos から GitHub にリポジトリを移動できます。多くのチームは、ado repos から Git リポジトリをエクスポートして GitHub リポジトリにインポートするか、移行ツールを使用します。移行では通常、コミット履歴の保持、GitHub Enterprise Cloud のエンタープライズ管理ユーザーの管理、そして必要に応じて Azure Pipelines から GitHub Actions への CI/CD 統合の更新が伴います。
Azure Boards と GitHub Issues は、アジャイル プロジェクト管理の観点でどのように比較されますか?
Azure Boardsは、作業項目、バックログ、スプリントなどを備えた本格的なアジャイルプロジェクト管理機能を提供し、パイプラインやTest Plansとの深い統合も特長です。そのため、エンタープライズ向けのプロジェクト管理ツールとして有力な選択肢になります。GitHubのissue(およびプロジェクトボード)はよりシンプルで、オープンソースや開発者コミュニティのワークフローに適しています。GitHubもプロジェクト計画機能を拡充していますが、両方の良いところを活かすために、GitHubリポジトリをAzure Boardsに接続するチームもあります。
Azure DevOpsのユーザーでもGitHub Copilotを利用できますか?
GitHub Copilotは主にVisual Studio CodeやVisual Studioなどの開発者ツールと統合されているため、Azure DevOpsを使用している開発者も、IDEでCopilotを利用できます。GitHub Copilotとその後のCopilotワークスペース機能は、バックエンドのCI/CDに関係なく開発者が利用できるようになっています。ただし、一部のエンタープライズ向けの管理機能やライセンスは、GitHub Enterprise Cloudを使用しているか、Azure DevOpsで管理された環境を利用しているかによって異なります。
エンタープライズで管理されたユーザーとセキュリティの観点では、GitHubとAzure DevOpsのどちらが適していますか?
どちらのプラットフォームもエンタープライズ向けの機能を備えています。Microsoft Azure DevOpsはきめ細かなアクセス制御、Azure AD統合、高度なコンプライアンス機能を提供します。一方、GitHub Enterprise Cloudにはエンタープライズ管理ユーザーが含まれ、コードスキャン、シークレットスキャン、依存関係管理を備えたAzure向けのGitHub Advanced Securityも利用できます。選択は組織のニーズによります。既存のMicrosoftツールとの統合を重視するならAzure DevOps、オープンソースやコミュニティ機能と高度なセキュリティオプションを重視するならGitHubが適しています。
CI/CDパイプラインは、Azure PipelinesとGitHub Actionsでどのように違いますか?
Azure Pipelines(Azure Boards and Pipelinesの一部)は、Azure DevOpsやVisual Studioと強力に統合された、堅牢なマルチプラットフォームのCI/CDを提供します。GitHub Actionsは、GitHubプラットフォームと密接に統合されており、リポジトリのイベントをトリガーとした柔軟なワークフローと、シームレスなプルリクエストの自動化を提供します。どちらもコンテナ、クラウドへのデプロイ、セルフホステッドランナーに対応しています。ご自身のワークフローに合ったDevOpsツールを選ぶか、両者を接続して両方の良いところを活かしてください。
Visual StudioとVS Codeは、両方のプラットフォームで使用できますか?
はい、Visual StudioとVisual Studio Code(VS Code)の両方がGitHubとAzure DevOpsをサポートしています。Visual Studioには、Azure ReposやADO向けの組み込み統合機能があります。VS Codeは、GitHubリポジトリ、GitHub Copilot、一般的なGitリポジトリと相性がよいです。開発者は、これらのツールを使ってプラットフォームを問わずコードの編集、テストの実行、プルリクエストや作業項目の操作を行えます。
テストについてはどうですか。Azure Test PlansはGitHubにも存在しますか?
Azure Test Plansは、Azure DevOpsに統合されたテストソリューションで、手動テストや探索的テストのためのツールを提供します。GitHubには同等の組み込みテスト計画製品はありませんが、テストフレームワーク、アクション、サードパーティのテスト管理ツールをGitHubリポジトリと統合することで、同様のテスト自動化とレポート機能を実現できます。
価格とホスティングはどのように違いますか。GitHubでホストする場合と、Microsoft Azure DevOpsでホストする場合を比較してください。
GitHubは、GitHub.com、GitHub Enterprise Cloudといったホスト型サービスを提供し、チームやエンタープライズ向けの階層型プランを用意しています。パブリックリポジトリとプライベートリポジトリ、およびコミュニティへのアクセスを重視しています。Microsoft Azure DevOps Servicesも、ユーザー単位の料金体系を持つクラウドホスト型のオプションを提供しており、オンプレミス版(旧TFS/Visual Studio Team Services)もあります。コストを検討する際は、パイプラインの実行時間、成果物のストレージ、エンタープライズ管理ユーザー、オンプレミスでのホスティングが必要かどうかを考慮します。
チームはGitHubとAzure DevOpsを併用できますか?
はい、多くの組織が、コードのホスティングとコミュニティでの共同作業にはGitHubを、プロジェクト管理、パイプライン、テスト計画にはAzure DevOpsを組み合わせて利用しています。この方法では、リポジトリとコミュニティに関するGitHubの強みと、Azure BoardsなどのAzure DevOpsの機能を両立できます。Azure ReposからGitHubへのリポジトリ同期や、GitHubリポジトリのイベントとADOボードの連携は、統合機能やコネクタを使うことで簡単に行えます。
開発者コミュニティでは、GitHubとAzure DevOpsのどちらが好まれていますか?
オープンソースのコントリビューターや多くの個人開発者は、コミュニティを育めることや、パブリックリポジトリとプライベートリポジトリの両方を扱えること、統合されたレビュー ワークフローを備えていることから GitHub を好む傾向があります。一方、エンタープライズの開発者や、包括的なプロジェクト管理が必要なチームは Azure DevOps を選ぶことが多いです。また、既存の Visual Studio や Microsoft Azure への投資状況、そして GitHub Copilot や Azure 向け GitHub Advanced Security などの機能を重視するかどうかによっても選択は変わります。
GitHub と Azure DevOps のどちらを選ぶかを決める際、チームはどのような点を検討すべきでしょうか。
バージョン管理のニーズ、Visual Studio や VS Code との統合、アジャイルなプロジェクト管理の必要性 (Azure Boards)、セキュリティとコンプライアンスの要件、Azure Test Plans の必要性、コミュニティやオープンソースでの可視性、そして GitHub Copilot や高度なセキュリティスキャンなどの機能を利用したいかどうかを検討してください。自社のワークフローに合ったDevOps ツールを評価するか、Azure Repos のリポジトリを活用する、あるいは GitHub のリポジトリに Azure Boards やパイプラインを組み合わせるハイブリッドモデルを採用するのも選択肢です。