組織の構造を計画する

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

Azure DevOps で作成する組織、プロジェクト、チームの数のガイドとして、ビジネス構造を使用します。 この記事は、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 無料

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

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

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

チームとは

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

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

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

プロジェクトとは

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 組織に接続できます。

単一プロジェクト

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

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

複数プロジェクト

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

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

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

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

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

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

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

以前に作成した組織の 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 の両方を使用できます。

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 の記事を参照してください。

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

組織構造の詳細

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

組織を作成するときに、サインインに使用する資格情報によって、組織で使用する 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

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

関連記事

• 組織を作成する
• プロジェクトの作成
• Microsoft Entra ID に組織を接続する
• 請求の設定
• ユーザー基本設定の設定