次の方法で共有

組織の構造を計画する

  • [アーティクル]

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Azure DevOps で作成する組織、プロジェクト、チームの数のガイドとして、ビジネス構造を使用します。 この記事は、Azure DevOps のさまざまな構造とシナリオの計画に役立ちます。

Azure DevOps でのビジネスと共同作業には、次の構造を考慮してください。

また、次のシナリオを計画することもできます。

少なくとも 1 つの組織が必要で、これで、自社、コード プロジェクトの大規模なコレクション、さらには複数の関連する事業単位を表すことができます。

組織とは

Azure DevOps の組織は、関連プロジェクトのグループを編成して接続するためのメカニズムです。 たとえば、事業部門や地域部門、その他の企業構造です。 会社全体に対して 1 つの組織を選択するか、自分用に 1 つの組織を選択するか、特定のビジネス ユニット用に個別の組織を選択できます。

各組織は、次のように、サービスの独自の 無料レベル (サービスの種類ごとに最大 5 人のユーザー) を取得します。 すべてのサービスを使用することも、既存のワークフローを補完するために必要なものだけを選択することもできます。

  • Azure Pipelines: CI/CD 用に 1 か月あたり 1,800 分の 1 つのホストされたジョブと 1 つのセルフホステッド ジョブ
  • Azure Boards: 作業項目の追跡とボード
  • Azure Repos: 無制限のプライベート Git リポジトリ
  • Azure Artifacts: パッケージ管理
  • 無制限の利害関係者
    • 最初の 5 人のユーザーが無料 (Basic ライセンス)
    • Azure Pipelines
      • 1 つの Microsoft ホスト型 CI/CD (1 つの同時実行ジョブ、1 か月あたり最大 30 時間)
      • 1 つのセルフホステッド CI/CD 同時実行ジョブ
    • Azure Boards: 作業項目の追跡とボード
    • Azure Repos: 無制限のプライベート Git リポジトリ
    • Azure Artifacts:organizationあたり 2 GiB 無料

Note

Azure DevOps クラウドベースのロード テスト サービスは非推奨となりましたが、 Azure Load Testing は引き続き使用できます。 このフル マネージドのロード テスト サービスを使用すると、既存の Apache JMeter スクリプトを使用して高スケールの負荷を生成できます。 詳細については、「 Azure Load Testing とは と Azure DevOps でのクラウド ロード テストと Visual Studio でのロード テスト機能の変更を参照してください。

いくつの組織が必要ですか?

Azure DevOps の 1 つの組織から始めます。 その後、さまざまなセキュリティ モデルが必要になる可能性がある組織を後で追加できます。 1 つのコード リポジトリまたはプロジェクトに必要な組織は 1 つだけです。 別々のチームが単独でコードやその他のプロジェクトに取り組む必要がある場合は、それらのチーム用に別々の組織を作成することを検討してください。 URL は異なります。 別の組織を追加する前に、必要に応じてプロジェクト、チーム、リポジトリを追加します。

作業構造と、管理するさまざまなビジネス グループと参加者を確認するには、少し時間がかかります。 詳細については、「 プロジェクトを事業単位にマップする と 構造に関する考慮事項を参照してください。

ヒント

会社所有の Microsoft Entra 組織の場合は、IP を保護する方法として、ユーザーが新しい組織を作成できないようにすることを検討してください。 詳細については、「 Microsoft Entra テナント ポリシーを使用した組織の作成を参照してください。 ユーザーは、制限なしで MSA または GitHub アカウントを使用して組織を作成できます。

チームとは

チームは、チームで構成可能な多くのツール サポートするユニットです。 これらのツールは、作業の計画と管理に役立ち、コラボレーションを容易にします。

個別の製品または機能チームごとにチームを作成する

各チームは独自のバックログを所有しています。 新しいバックログを作成するには、新しいチームを作成します。 チームとバックログを階層構造に構成、プログラム所有者はチーム全体の進行状況をより簡単に追跡し、ポートフォリオを管理し、ロールアップ データを生成できます。 チームを作成すると、チーム グループが作成されます。 このグループは、クエリで使用することも、チームのアクセス許可を設定することもできます。

プロジェクトとは

Azure DevOps のプロジェクトには、次の一連の機能が含まれています。

  • アジャイル計画のためのボードとバックログ
  • 継続的インテグレーションとデプロイのためのパイプライン
  • ソース コードと成果物のバージョン管理と管理のためのリポジトリ
  • プロジェクト ライフ サイクル全体の継続的なテスト統合各組織には、1 つ以上のプロジェクトが含まれています

次の図では、架空の Contoso 企業は Contoso-Manufacturing 組織内に 4 つのプロジェクトを持っています。

4 つのプロジェクトがある組織の画像

必要なプロジェクトはいくつですか?

Azure Boards、Azure Repos、Azure Pipelines などの Azure DevOps サービスの使用を開始するプロジェクトを少なくとも 1 つ用意します。 組織を作成すると、既定のプロジェクトが自動的に作成されます。 既定のプロジェクトには、作業を開始するコード リポジトリ、作業を追跡するためのバックログ、ビルドとリリースの自動化を開始するためのパイプラインが少なくとも 1 つあります。

組織内では、次のいずれかの方法を実行できます。

  • 単一プロジェクトを作成して、複数のリポジトリとチームを含める
  • 複数プロジェクトを作成して、それぞれに、チーム、リポジトリ、ビルド、作業項目、その他の要素の独自のセットを含める

多数のチームが何百もの異なるアプリケーションとソフトウェア プロジェクトに取り組んでいる場合でも、Azure DevOps の 1 つのプロジェクト内でそれらを管理できます。 ただし、ソフトウェア プロジェクトとそのチームの間でより詳細なセキュリティを管理する場合は、多くのプロジェクトを使用することを検討してください。 最高レベルの分離とは、各組織が 1 つの Microsoft Entra テナントに接続されている組織です。 ただし、1 つの Microsoft Entra テナントは、多くの Azure DevOps 組織に接続できます。

Note

組織で [ ユーザーの可視性とコラボレーションを特定のプロジェクトに限定 する] プレビュー機能が有効になっている場合、 Project スコープ ユーザー グループに追加されたユーザーは、追加されていないプロジェクトにアクセスできなくなります。 詳細と重要なセキュリティ関連のコールアウトについては、「 組織の管理」、「プロジェクトのユーザーの可視性を制限する」を参照してください。

単一プロジェクト

単一プロジェクトでは、すべての作業を組織全体で同じ "ポートフォリオ" レベルに配置します。 作業のリポジトリと反復パスのセットが同じです。 単一プロジェクトでは、チームはソース リポジトリ、ビルド定義、リリース定義、レポート、パッケージ フィードを共有します。 場合によっては、1 つの大規模な製品またはサービスを多数のチームが管理します。 製品ライフ サイクル全体でこれらのチームが密接に相互依存します。 プロジェクトを 1 つ作成し、チームとエリア パスを使用して作業を分割します。 この設定により、チームは互いの作業を見通せるため、組織の連携が保たれます。 チームが作業項目の追跡に同じ分類を使用するため、コミュニケーションが容易になり、一貫性を維持しやすくなります。

ヒント

複数のチームが同じ製品で作業する場合、すべてのチームを同じイテレーション スケジュールに従うことで、チームを調整し、同じ間隔で価値を提供することができます。 たとえば、Azure DevOps の組織には、1 つのプロジェクト内に 40 を超える機能チームと 500 人のユーザーがいます。これは、共通の目標と共通のリリース スケジュールを持つ共通の製品セットに取り組んでいるためです。

大量のクエリとボードを使用すると、探しているものを見つけるのが難しくなります。 製品のアーキテクチャによっては、ビルド、リリース、リポジトリなどの他の領域にこの問題が発生する可能性があります。 適切な名前付け規則と単純なフォルダー構造を使用してください。 リポジトリをプロジェクトに追加するときは、戦略を検討し、そのリポジトリを独自のプロジェクトに配置できるかどうかを判断します。

複数プロジェクト

製品を出荷する方法によって、プロジェクト構造を最適に決定できます。 プロジェクトを複数にすることで、管理の負担を移し、チームの決定に従ってプロジェクトをより自律的に管理できます。 また、異なるプロジェクト間でセキュリティと資産へのアクセスをより詳細に制御できます。 ただし、多くのプロジェクトでチームが独立すると、いくつかのアラインメントの課題が生まれます。 プロジェクトごとに異なるプロセスまたは反復スケジュールを使用している場合は、分類が同じでないと、コミュニケーションとコラボレーションが難しくなる可能性があります。

ヒント

すべてのプロジェクトで同じプロセスとイテレーション スケジュールを使用すると、チーム間でデータとレポートをロールアップする機能が向上します。

Azure DevOps は、作業を管理するためのプロジェクト間エクスペリエンスを提供します。

次のシナリオにより、別のプロジェクトを追加できます。

  • プロジェクト内の情報へのアクセスを禁止または管理するには
  • 組織内の特定の部署のカスタム作業追跡プロセスをサポートするには
  • 独自の管理ポリシーと管理者を持つ完全に個別の部署をサポートするには
  • 作業プロジェクトに変更をロールアウトする前に、カスタマイズ アクティビティのテストまたは拡張機能の追加をサポートするには

複数プロジェクトを検討している場合は、Git リポジトリの移植性により、プロジェクト間でリポジトリ (完全な履歴を含む) を簡単に移行できる点に留意してください。 他の履歴をプロジェクト間で移行することはできません。 たとえば、プッシュや pull request の履歴です。

プロジェクトを事業単位にマップする場合は、会社で単一の組織を取得し、複数プロジェクトを設定して、1 つ以上のプロジェクトで 1 つの事業単位を表すようにします。 会社の Azure DevOps 資産はすべて、この組織内に含まれ、特定のリージョン (たとえば、西ヨーロッパ) 内に配置されます。 プロジェクトを事業単位にマッピングするために次のガイダンスを検討してください。

1 つのプロジェクト、複数のチーム 1 つの組織、複数プロジェクト、チーム 複数の組織
一般的なガイダンス 小規模な組織やチームが高度に連携する大規模な組織に最適です。 異なる作業で異なるプロセスを必要とする場合に適しています。 TFS レガシ移行の一部として、また、組織間の厳しいセキュリティ境界に有用です。 各組織内の複数のプロジェクトとチームで使用されます。
スケール 数万人のユーザーと数百のチームをサポートしますが、この規模で、すべてのチームが関連作業に取り組んでいる場合に最適です。 プロジェクトが 1 つの場合と同じですが、プロジェクトが複数の方が簡単な可能性があります。
Process チーム間の連携プロセス。ボードやダッシュボードなどをカスタマイズするためのチームの柔軟性。 プロジェクトごとに独立したプロセス。 たとえば、さまざまな作業項目の種類、カスタム フィールドなどです。 複数プロジェクトと同じです。
コラボレーション さまざまなチームの作業と資産の間で、既定の可視性と再利用が最も高いです。 適切な可視性と再利用が可能ですが、意図的かどうかに関係なく、プロジェクト間で資産を非表示にする方が簡単です。 組織間の可視性、コラボレーション、再利用が不十分です。
レポートのロールアップとポートフォリオ管理 チーム全体のロールアップとチーム間の調整力が最も優れています。 プロジェクト全体で適切なレポートが可能です。 プロジェクト間のロールアップとチームの調整が難しくなります。 組織間のロールアップと調整はありません。
セキュリティ/分離 チーム レベルで資産をロック ダウンできますが、既定はオープンな可視性とコラボレーションです。 プロジェクト間でロック ダウンする力が優れています。 既定では、プロジェクト内の良好な可視性、プロジェクト全体の良好な分離を提供します。 組織間の厳しい境界。分離に優れ、組織間で共有する力は最小限。
コンテキストの切り替え チームの連携とユーザーの作業切り替えが最も簡単です。 ユーザーが共同作業を行い、作業間でコンテキストを切り替えるのが比較的簡単です。 ユーザーが異なる組織で作業する必要がある場合は、難しくなります。
情報過多 既定では、"情報過多" を回避するために "お気に入り" のようなメカニズムを使用するユーザーには、すべての資産が表示されます。 情報過多のリスクを軽減します。プロジェクトの境界を越えるほとんどのプロジェクト資産が表示されません。 組織全体の資産が分離され、情報過多のリスクが軽減されます。
管理オーバーヘッド 多くの管理が、個々のチームに委任されます。 ユーザー ライセンスと組織レベルの管理が最も簡単です。 作業間の調整が必要な場合、さらに多くの作業が必要になる可能性があります。 プロジェクト レベルの管理が多くなります。 オーバーヘッドが増えますが、プロジェクトの管理ニーズが異なる場合に有用です。 プロジェクトが増えると、管理オーバーヘッドが増え、組織間の柔軟性を向上できます。

プロジェクト内でリポジトリとバージョン 管理を構成する

以前に作成した組織の 1 つと、アクセスが必要なユーザーを対象とする特定の戦略的な作業について考えてみましょう。 この情報を使用して、プロジェクトの名前と 作成を行います。 このプロジェクトには、作成した組織で定義された URL があり、〘〘〗〘〗〘 https://dev.azure.com/{organization-name}/{project-name}.

プロジェクトの設定でプロジェクトを構成します。

[プロジェクトの設定] ボタンを示すスクリーンショット。

プロジェクトの管理の詳細については、「 Azure DevOps でのプロジェクトの管理を参照してください。 データを移行することで、プロジェクトを別の組織に移動できます。 プロジェクトの移行の詳細については、 Migration の概要を参照してください。

バージョン管理の管理

Azure Repos サービスが有効になっているプロジェクトでは、バージョン管理リポジトリでコードを格納および修正できます。 リポジトリを構成するときは、次のオプションを検討してください。

Git と Team Foundation バージョン管理 (TFVC)

Azure Repos には、チームが選択できる次のバージョン管理システムが用意されています。

  • Git と TFVC。 プロジェクトに、それぞれの種類のリポジトリを持つことができます。 既定では、新しいプロジェクトには空の Git リポジトリがあります。 Git を使用すると、開発者ワークフローの柔軟性が大幅に向上し、開発者エコシステムのほぼすべての関連ツールと統合できます。 どのプロジェクトでも Git リポジトリを使用できます。 プロジェクトに追加できる Git リポジトリの量に制限はありません。

TFVC は、一元化されたバージョン管理システムで、このシステムも利用できます。 Git とは異なり、1 つのプロジェクトに対して許可される TFVC リポジトリは 1 つだけです。 ただし、そのリポジトリ内で、必要に応じて複数の製品とサービスのコードを編成するためにフォルダーとブランチを使用します。 プロジェクトでは、必要に応じて TFVC と Git の両方を使用できます。

Monorepo とサービスごとに 1 つのリポジトリ

モノレポからさまざまな独立したサービスをデプロイすることは、早期の勢いを目指す小規模なチームに効果的です。 ただし、この戦略は、いくつかの要因によってチームが成長するにつれて問題になる可能性があります。

  • 新しいメンバーに必要な知識は、システムの全体的な複雑さに伴って増加します。
  • 1 つのリポジトリ内でコードを共有すると、サービス間で意図しない結合が発生する可能性があります。
  • 共有コードの変更は、さまざまなサービスの動作に影響を与える可能性があるため、これらの変更を追跡するのは困難です。

大規模なチームでは、モノレポを管理するために、強力なエンジニアリング規範と堅牢なツールが必要です。 または、共有リソース用の個別のリポジトリと共に、サービスごとに個別のリポジトリを選択することもできます。 このアプローチでは、より多くの初期セットアップが必要になりますが、チームの成長に合わせてより効果的にスケーリングされます。 また、特定のサービス リポジトリだけに集中できる新しいメンバーのオンボードも簡単になります。

小規模なチームから始める場合は、monorepo を選択することをお勧めします。 チームが拡大し、複雑さが増すにつれて、別のリポジトリに移行できます。

プロジェクト内の 1 つのリポジトリと多くのリポジトリ

1 つのプロジェクト内に複数のリポジトリを設定する必要があるか、またはプロジェクトごとにリポジトリを設定する必要がありますか? 次のガイダンスは、これらのリポジトリ全体の計画および管理機能に関連しています。

複数のリポジトリを含む 1 つのプロジェクトは、製品またはサービスが、調整されたリリース スケジュールで動作している場合に適切に機能します。 開発者が複数のリポジトリを頻繁に操作する場合は、プロセスの共有と一貫性を確保するために、それらを単一プロジェクトに保持します。 ケースの適用や最大ファイル サイズなどのアクセス制御とオプションがプロジェクト レベルで設定されるため、1 つのプロジェクト内でリポジトリ アクセスを管理する方が簡単です。 リポジトリが単一プロジェクト内にある場合でも、アクセスの制御と設定を個別に管理できます。

複数のリポジトリに格納されている製品が独立したスケジュールまたはプロセスで動作する場合は、それらを複数のプロジェクトに分割できます。 Git リポジトリの移植性により、プロジェクト間でリポジトリを簡単に移動し、完全に忠実なコミット履歴を保持できます。 pull request やビルド履歴などのその他の履歴は、簡単には移行されません。

次の要因とヒントに基づいて、1 つのリポジトリと多くのリポジトリを決定します。

  • コードの依存関係とアーキテクチャ
  • それぞれ個別にデプロイ可能な製品またはサービスを独自のリポジトリに配置する
  • これらのリポジトリ全体でコードを調整する予定がある場合は、コードベースを多くのリポジトリに分割しないでください。これらの変更を調整するのに役立つツールがないためです
  • コードベースが既にモノリスである場合は、それを 1 つのリポジトリに保持します。 モノリシック リポジトリの詳細については、「 Microsoft が DevOps を使用して最新のソフトウェアを開発する方法 記事を参照してください。
  • 切断されたサービスが多数ある場合は、サービスごとに 1 つのリポジトリが適切な戦略です

ヒント

アクセス許可を管理することを検討してください、組織内のすべてのユーザーがリポジトリを作成できません。 リポジトリが多すぎる場合、リポジトリに格納されているコードやその他のコンテンツを所有しているユーザーを追跡するのは困難です。

共有リポジトリとフォークされたリポジトリ

信頼された組織内で共有リポジトリを使用することをお勧めします。 開発者は、互いの変更の分離を維持するのにブランチを使用します。 優れたブランチとリリースの戦略を用いて、1 つのリポジトリで 1,000 人超の開発者の同時開発をサポートできるように拡張できます。 分岐とリリースの戦略の詳細については、「 Adopt a Git branching strategy and Release Flow: Our Branching Strategy」を参照してください。

フォークは、メイン リポジトリを更新するための直接アクセスを持つべきではないベンダー チームと作業する場合に有用です。 フォークは、オープンソース プロジェクトのように、数多くの開発者が頻繁にコントリビューションしないシナリオでも有用です。 フォークを操作する場合、フォークされたリポジトリをメイン リポジトリから分離するために、別のプロジェクトを維持したい場合があります。 管理オーバーヘッドが増える可能性がありますが、メイン プロジェクトがよりクリーンに保たれます。 詳細については、 Forks の記事を参照してください。

次の図は、"会社" が組織、プロジェクト、作業項目、チーム、リポジトリを構成する方法のサンプルを示しています。

会社の組織構造を示す図。

一時リソースと共有リソースの管理

次のベスト プラクティスを使用して、一時的なリソースと共有リソースを効果的に管理する方法を検討します。

  • 一時的な環境: 一時的な環境は有効期間が短く、テスト、開発、ステージングなどのタスクに使用されます。 これらの環境を効率的に管理するには:
    • 個別のリポジトリとパイプライン: 一時環境とそれに関連付けられている各リソース (Azure Functions など) には、独自のリポジトリとパイプラインが必要です。 この分離により、環境とそのリソースを同時にデプロイおよびロールバックできるため、必要に応じて簡単に起動および破棄できます。
    • 例: Azure Functions、ストレージ アカウント、その他のサービスなど、必要なすべてのリソースを含め、開発環境専用のリポジトリとパイプラインを作成します。
  • 共有リソース: 共有リソースは通常、有効期間が長く、複数の環境で使用されます。 多くの場合、これらのリソースのスピンアップ時間が長くなり、コストが高くなります。 共有リソースを効果的に管理するには:
    • 個別のリポジトリとパイプライン: Azure SQL Database などの共有リソースには、独自のリポジトリとパイプラインが必要です。 この分離により、一時的な環境でこれらの共有リソースを使用できるため、デプロイの高速化とコスト効率の向上が実現します。
    • 例: 複数の一時環境で使用できる Azure SQL Database のリポジトリとパイプラインを作成します。
  • 共有インフラストラクチャ リソース: 仮想プライベート クラウド (VPC) やサブネット (ランディング ゾーンとも呼ばれます) などの共有インフラストラクチャ リソースにも、独自のリポジトリとパイプラインが必要です。 この方法により、インフラストラクチャが一貫して管理され、さまざまな環境で再利用できるようになります。
    • 例: VPC とサブネット構成のリポジトリとパイプラインを作成します。これは、他のリポジトリやパイプラインから参照できます。

組織構造の詳細

組織の管理者アカウントの種類を選択する

組織を作成するときに、サインインに使用する資格情報によって、組織で使用する ID プロバイダーが定義されます。 Microsoft アカウントまたは Microsoft Entra インスタンスを使用して組織を作成します。 これらの資格情報を使用して、 https://dev.azure.com/{YourOrganization}で新しい組織に管理者としてサインインします。

Microsoft アカウントを使用する

Microsoft Entra ID を使用して組織のユーザーを認証する必要がない場合は、Microsoft アカウントを使用します。 すべてのユーザーは、Microsoft アカウントを使用して組織にサインインする必要があります。 Microsoft アカウントを持っていない場合は、作成します。

パスワードを入力してサインインする

Microsoft Entra インスタンスがない場合は、 Azure ポータルから無料で作成するか Microsoft アカウントを使用して組織を作成します。 その後、組織を Microsoft Entra ID に 接続。

Microsoft Entra アカウントを使用する

Azure または Microsoft 365 を使用している場合は、既に Microsoft Entra アカウントを持っている可能性があります。 Microsoft Entra ID を使用してユーザーのアクセス許可を管理する会社で働いている場合は、おそらく Microsoft Entra アカウントを持っている可能性があります。

Microsoft Entra アカウントをお持ちでない場合は、Microsoft Entra ID に サインアップ 組織を Microsoft Entra ID に自動的に接続します。 組織にアクセスするには、すべてのユーザーがそのディレクトリのメンバーである必要があります。 他の組織のユーザーを追加するには、 Microsoft Entra B2B コラボレーションを使用します。

Azure DevOps では、Microsoft Entra ID を使用してユーザーが認証されるため、そのディレクトリ内のメンバーであるユーザーのみが組織にアクセスできます。 そのディレクトリからユーザーを削除すると、ユーザーは組織にアクセスできなくなります。 特定の Microsoft Entra 管理者のみが ディレクトリ内のユーザーを管理するため、管理者は組織にアクセスするユーザーを制御します。

ユーザーの管理の詳細については、「 Manage ユーザー」を参照してください。

組織をビジネス ユニットにマップする

社内の各部署は、独自の Microsoft Entra テナントと共に、Azure DevOps 内の独自の組織を取得します。 チームや進行中の作業に基づいて必要に応じて、個々の組織内でプロジェクトをに設定できます。

大企業では、異なるユーザー アカウント (Microsoft Entra アカウントの可能性が高い) を使用して複数の組織を作成できます。 戦略と作業を共有するグループとユーザーを検討し、それらを特定の組織にグループ化します。

たとえば、架空の Fabrikam 社は次の 3 つの組織を作成しました。

  • Fabrikam-Marketing
  • Fabrikam-Engineering
  • Fabrikam-Sales

各組織には、次のような個別の URL があります。

  • https://dev.azure.com/Fabrikam-Marketing
  • https://dev.azure.com/Fabrikam-Engineering
  • https://dev.azure.com/Fabrikam-Sales

組織は同じ会社を対象としていますが、ほとんど互いに分離されています。 このように何も分離する必要はありません。 ビジネスに意味を持つ場合にのみ境界を作成します。

ヒント

異なる組織を組み合わせるよりも、既存の組織をプロジェクトで簡単にパーティション分割できます。