GitHub Enterprise Cloud の構造的コンポーネントを理解する

GitHub Enterprise Cloud (GHEC) では、多数の柔軟な構成オプションが提供されるので、それぞれのビジネスは固有のニーズに合わせて、プラットフォームを構成することができます。GHEC の実装に単一で「最良」の手法が存在するわけではありませんが、ユーザーが注意深く考慮すべき共通のパターンとステップがいくつか存在します。

GHEC の実装成功は、全ての内部作業で使用する 1 つの Enterprise アカウントを作成することから始まります。これにより、GitHub Organization、ユーザー、チーム全体のポリシーを規定でき、また、唯一の請求管理ポータルにすることができます。

Organization の構造は常に進化しています。また、GitHub アーキテクチャは、コラボレーション可能なデベロッパーエクスペリエンスを促進する意図を反映するものである必要があります。その際、ビジネスの複雑で動的な性質を考慮しつつ、セキュリティとコンプライアンスの要件を満たす必要もあります。では、GHEC アカウントのコアとなる構造の確認を始めましょう。

このガイドの学習内容

GHEC の構造的コンポーネントおよびコンポーネント間の関係
各コンポーネントが管理レベルを提供する方法
これらのコンポーネントを使用してビジネスを設定し、必須要件を強制し、コラボレーションを促進するための初期段階で考慮すべき事項

これが重要である理由

このラーニングパスの後半では、ビジネスニーズをサポートするために、異なる Organization 構造を使用して最適な設定およびポリシーのインフラストラクチャを構築します。必須要件を満たす最適な意思決定を行えるようにするには、これらのコンポーネントの相互作用を理解することが重要です。

Enterprise アカウント

Enterprise アカウントは GHEC の最上位の構造です。設計上、Enterprise アカウントは論理的に分離されており、そのリソースは GHEC 内で他の Enterprise から独立しています。Enterprise アカウントは請求、ライセンスの割り当て、およびその他のポリシーと設定向けの純粋な管理コンテナーです。管理者は Enterprise アカウントを使用して、ID プロバイダー (IdP)、ライセンス割り当ておよび請求、サポートチケットと権利の付与、ログ管理などの内部ビジネスシステムと GitHub との接続方法を管理します。また、GitHub リソースと機能の使用を管理するポリシーを定義、適用する機能を提供します。このポリシーは Enterprise アカウント内の全ての Organization に同じように適用されます。

Enterprise アカウントのインターフェイスは、Enterprise 管理者 (オーナー) であるユーザーによって定期的に活用されるのみです。通常、標準的なエンドユーザーは Enterprise アカウントインターフェイスを使用する必要はありません。

Organization

Enterprise は 1 つ以上の Organization から構成されています。ユーザーは Organization に追加されます。Organization は共有リポジトリ、チーム、ディスカッション、プロジェクトの「オーナー」です。これを使用すると、管理者はその Organization に属するリポジトリおよび Organization 内のユーザー動作によりきめ細かいポリシーを設定できるようになります。Enterprise レベルで適用されていないポリシーは分配され、各 Organization で個別に定義されます。通常、Organization は事業部門と一致していません。一般的には、GitHub Organization は 1 つのみにして、さらに分割するにはリポジトリやチームなど、他の機能を使用することをお勧めしています。ただし、たとえば、トレーニングやテストのためのサンドボックス Organization を提供する、独立した法的エンティティをスピンオフするなど、複数の Organization を使用する営業上の理由または法的な理由がある場合もあります。後ほど、例と戦略の詳細をいくつか説明します。

Organization は Enterprise アカウントレベルに集約される、請求、使用状況、ライセンスに関する報告向けデータをさらに詳細化するための出発点となります。GitHub Actions や Codespaces のような従量制料金のサービスはリポジトリおよび Organization レベルの両方で報告されます。これらのサービスの支出限度額は各 Organization ベースで設定できます。

通常、Organization はエンドユーザーが使用する構造で最も上位のものです。たとえば、Organization 規模のコード検索をしたり、SAML を使用して Organization にログインしたりできます。Enterprise アカウント内に Enterprise オーナーが管理する複数の Organization が存在する可能性がありますが、エンドユーザーの視点では、Organization は完全に独立したコンテナーとして機能します。

リポジトリ

リポジトリはアプリケーションソースコードとその他のファイルをホストします。開発者が GitHub で接する主な構造で、アプリケーションセキュリティのメトリクス、CI/CD ワークフロー、その他の日常的な活動へのアクセスが含まれています。

リポジトリは Organization レベルに集約されます。ただし、一部のリポジトリの可視性オプションは、Organization または Enterprise 外のユーザーに読み取り専用としてリポジトリを表示できるようにします。リポジトリの可視性のガイドで詳細を確認します (または、リポジトリの可視性の設定に関するドキュメントを参照できます)。

Teams

GitHub のチームはユーザーを共通のプロジェクト、専門スキル、またはその他の共通基盤を持つユーザーをグループにまとめます。チームはリポジトリ群にロールベースのアクセスを提供します。これにより、権限管理構造を作成できると同時に、コンテンツの発見可能性と再利用を可能な限り高く、広く保つことができます。

権限管理に使用されるチームは ID プロバイダー (IdP) グループと同期している必要があります。このようにすると、既存のアクセスプロセスおよび監査管理がコード、オンボーディング、オフボーディングへのアクセスを管理できます。

権限はチーム以外も使用できます。GitHub のチームを使用して、プロジェクトチーム間および (IdP によって明示的に定義されていない) トピックベースのチーム間のコラボレーションを促進できます。また、チームはコードのレビュー担当者として自動的に指定できます。

階層と設定継承の観点においては、チームは Organization レベルに集約されます。つまり、Enterprise アカウント内の複数の Organization で同じチームを再利用するには、各 Organization に同じものを再作成する必要があります。

次の内容: GitHub Enterprise Cloud ユーザーのアクセスモデルを選択する

これで、GHEC のコアとなる構造的コンポーネントを理解できました。次のステップでは GHEC を導入する新しい企業が最初に選択する必要のあるものの 1 つ、すなわち、標準モデルまたは Enterprise Managed User (EMU) モデルのどちらを使うべきかについて確認します。

それぞれのメリットとデメリットを確認し、Philips や Travelport など、他の GitHub のお客様が最適なモデルを選んだ方法について取り上げます。