組織の構造を計画する
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Azure DevOps で作成する組織、プロジェクト、チームの数のガイドとして、ビジネス構造を使用します。 この記事は、Azure DevOps のさまざまな構造とシナリオの計画に役立ちます。
Azure DevOps でのビジネスと共同作業には、次の構造を考慮してください。
また、次のシナリオを計画することもできます。
- Azure DevOps の組織とプロジェクト をエンタープライズ、ビジネス ユニット、チーム構造にマップする
- リポジトリ (リポジトリ) を構築する
- チームを構成する - チームがアジャイルで自律的になるのを助けるか妨げる可能性があります
- データ へのアクセスを管理する - アクセス権を持つ必要があるユーザーとアクセスできないユーザー
- レポートのニーズ
- 一般的なプラクティスを促進する - 基本的な要素を使用してアジャイルな考え方と文化を作成する
少なくとも 1 つの組織が必要で、これで、自社、コード プロジェクトの大規模なコレクション、さらには複数の関連する事業単位を表すことができます。
組織とは
Azure DevOps の組織は、関連プロジェクトのグループを編成して接続するためのメカニズムです。 たとえば、事業部門や地域部門、その他の企業構造です。 会社全体に対して 1 つの組織を選択するか、自分用に 1 つの組織を選択するか、特定のビジネス ユニット用に個別の組織を選択できます。
各組織は、次のように独自 の Free レベル のサービス (サービスの種類ごとに最大 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 とは」および 「Visual Studio でのロード テスト機能の変更」および「Azure DevOps でのクラウド ロード テスト」を参照してください。
いくつの組織が必要ですか?
Azure DevOps の 1 つの組織から始めます。 その後、さまざまなセキュリティ モデルが必要になる可能性がある組織を後で追加できます。 1 つのコード リポジトリまたはプロジェクトに必要な組織は 1 つだけです。 別々のチームが単独でコードやその他のプロジェクトに取り組む必要がある場合は、それらのチーム用に別々の組織を作成することを検討してください。 URL は異なります。 別の組織を追加する前に、必要に応じてプロジェクト、チーム、リポジトリを追加します。
作業構造と、管理するさまざまなビジネス グループと参加者を確認するには、少し時間がかかります。 詳細については、「プロジェクトを事業単位にマップする」および「構造に関する考慮事項」を参照してください。
ヒント
会社所有の Microsoft Entra 組織の場合は、IP を保護する方法として、ユーザーが新しい組織を作成できないようにすることを検討してください。 詳細については、「Microsoft Entra テナント ポリシーを使用して組織の作成を制限する」を参照してください。 ユーザーは、制限なしで MSA または GitHub アカウントを使用して組織を作成できます。
チームとは
チームは、チームで構成可能な多くの ツールをサポートするユニットです。 これらのツールは、作業の計画と管理に役立ち、コラボレーションを容易にします。
個別の製品または機能チームごとにチームを作成する
各チームは独自のバックログを所有しています。 新しいバックログを作成するには、新しいチームを作成します。 チームとバックログを階層構造に構成することで、プログラム所有者はチーム全体の進行状況をより簡単に追跡し、ポートフォリオを管理し、ロールアップ データを生成できます。 チームを作成すると、チーム グループが作成されます。 このグループは、クエリで使用することも、チームのアクセス許可を設定することもできます。
プロジェクトとは
Azure DevOps のプロジェクトには、次の一連の機能が含まれています。
- アジャイル計画のためのボードとバックログ
- 継続的インテグレーションとデプロイのためのパイプライン
- ソース コードと成果物のバージョン管理と管理のためのリポジトリ
- プロジェクト ライフ サイクル全体の継続的なテスト統合各組織には、1 つ以上のプロジェクトが含まれています
次の図では、架空の Contoso 企業は Contoso-Manufacturing 組織内に 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}.
プロジェクト設定でプロジェクトを 構成します。
![[プロジェクトの設定] ボタンを示すスクリーンショット。](../media/settings/open-project-settings-vert-brn.png?view=azure-devops)
プロジェクトの管理の詳細については、「Azure DevOps でのプロジェクトの管理」を参照してください。 データを移行することで、プロジェクトを別の組織に移動できます。 プロジェクトの移行の詳細については、「移行オプション」を参照してください。
バージョン管理の管理
Azure Repos サービスが有効になっているプロジェクトでは、バージョン管理リポジトリでコードを格納および修正できます。 リポジトリを構成するときは、次のオプションを検討してください。
Git と Team Foundation バージョン管理 (TFVC)
Azure Repos には、チームが選択できる次のバージョン管理システムが用意されています。
- Git と TFVC。 プロジェクトに、それぞれの種類のリポジトリを持つことができます。 既定では、新しいプロジェクトには空の Git リポジトリがあります。 Git を使用すると、開発者ワークフローの柔軟性が大幅に向上し、開発者エコシステムのほぼすべての関連ツールと統合できます。 どのプロジェクトでも Git リポジトリを使用できます。 プロジェクトに追加できる Git リポジトリの量に制限はありません。
TFVC は、一元化されたバージョン管理システムで、このシステムも利用できます。 Git とは異なり、1 つのプロジェクトに対して許可される TFVC リポジトリは 1 つだけです。 ただし、そのリポジトリ内で、必要に応じて複数の製品とサービスのコードを編成するためにフォルダーとブランチを使用します。 プロジェクトでは、必要に応じて TFVC と Git の両方を使用できます。
1 つのリポジトリと多くのリポジトリ
1 つのプロジェクト内に複数のリポジトリを設定する必要があるか、またはプロジェクトごとにリポジトリを設定する必要がありますか? 次のガイダンスは、これらのリポジトリ全体の計画および管理機能に関連しています。
複数のリポジトリを含む 1 つのプロジェクトは、製品またはサービスが、調整されたリリース スケジュールで動作している場合に適切に機能します。 開発者が複数のリポジトリを頻繁に操作する場合は、プロセスの共有と一貫性を確保するために、それらを単一プロジェクトに保持します。 ケースの適用や最大ファイル サイズなどのアクセス制御とオプションがプロジェクト レベルで設定されるため、1 つのプロジェクト内でリポジトリ アクセスを管理する方が簡単です。 リポジトリが単一プロジェクト内にある場合でも、アクセスの制御と設定を個別に管理できます。
複数のリポジトリに格納されている製品が独立したスケジュールまたはプロセスで動作する場合は、それらを複数のプロジェクトに分割できます。 Git リポジトリの移植性により、プロジェクト間でリポジトリを簡単に移動し、完全に忠実なコミット履歴を保持できます。 pull request やビルド履歴などのその他の履歴は、簡単には移行されません。
次の要因とヒントに基づいて、1 つのリポジトリと多くのリポジトリを決定します。
- コードの依存関係とアーキテクチャ
- それぞれ個別にデプロイ可能な製品またはサービスを独自のリポジトリに配置する
- これらのリポジトリ間で調整されたコード変更を行うと予想される場合は、コードベースを多くのリポジトリに分割しないでください。これらの変更を調整するのに役立つツールはありません
- コードベースが既にモノリスである場合は、それを 1 つのリポジトリに保持します。 モノリシック リポジトリの詳細については、Microsoft が DevOps を使用して最新のソフトウェアを開発する方法に関する記事を参照してください。
- 切断されたサービスが多数ある場合は、サービスごとに 1 つのリポジトリが適切な戦略です
ヒント
組織内のすべてのユーザーがリポジトリを作成できないように、アクセス許可の管理を検討してください。 リポジトリが多すぎる場合、リポジトリに格納されているコードやその他のコンテンツを所有しているユーザーを追跡するのは困難です。
共有リポジトリとフォークされたリポジトリ
信頼された組織内で共有リポジトリを使用することをお勧めします。 開発者は、互いの変更の分離を維持するのにブランチを使用します。 優れたブランチとリリースの戦略を用いて、1 つのリポジトリで 1,000 人超の開発者の同時開発をサポートできるように拡張できます。 分岐とリリースの戦略の詳細については、「Git 分岐戦略の採用」と「リリース フロー: 分岐戦略」を参照してください。
フォークは、メイン リポジトリを更新するための直接アクセスを持つべきではないベンダー チームと作業する場合に有用です。 フォークは、オープンソース プロジェクトのように、数多くの開発者が頻繁にコントリビューションしないシナリオでも有用です。 フォークを操作する場合、フォークされたリポジトリをメイン リポジトリから分離するために、別のプロジェクトを維持したい場合があります。 管理オーバーヘッドが増える可能性がありますが、メイン プロジェクトがよりクリーンに保たれます。 詳細については、フォークの記事を参照してください。
次の図は、"会社" が組織、プロジェクト、作業項目、チーム、リポジトリを構成する方法のサンプルを示しています。
組織構造の詳細
組織の管理者アカウントの種類を選択する
組織を作成するときに、サインインに使用する資格情報によって、組織で使用する ID プロバイダーが定義されます。 Microsoft アカウントまたは Microsoft Entra インスタンスを使用して組織を作成します。 これらの資格情報を使用して、新しい組織 https://dev.azure.com/{YourOrganization}に管理者としてサインインします。
Microsoft アカウントを使用する
Microsoft Entra ID を使用して組織のユーザーを認証する必要がない場合は、Microsoft アカウントを使用します。 すべてのユーザーは、Microsoft アカウントを使用して組織にサインインする必要があります。 Microsoft アカウントを持っていない場合は、作成します。
Microsoft Entra インスタンスがない場合は、Azure portal から無料で作成するか、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 管理者 のみがディレクトリ内のユーザーを管理するため、管理者は組織にアクセスするユーザーを制御します。
ユーザーの管理の詳細については、「ユーザーの管理」を参照してください。
組織をビジネス ユニットにマップする
社内の各部署は、独自の 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
組織は同じ会社を対象としていますが、ほとんど互いに分離されています。 このように何も分離する必要はありません。 ビジネスに意味を持つ場合にのみ境界を作成します。
ヒント
異なる組織を組み合わせるよりも、既存の組織をプロジェクトで簡単にパーティション分割できます。
関連記事
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示