GitHub Enterprise Cloud で Organization を使用するための戦略
GitHub Enterprise Cloud (GHEC) の中で、Organization は、洗練されたセキュリティと管理の機能がある共有アカウントで、そこではユーザーが同時に多くのプロジェクトにまたがって協力します。構造を事前に計画して、不必要なサイロができたり、管理のオーバーヘッドが増加したりしないようにすることが重要です。適切な構造にすると、協力と発見を促進する一方、管理のオーバーヘッドは減少します。
ごく一部の例外を除いて 1 つの Organization を GitHub Enterprise アーキテクチャで使用することを Philips が選んだ理由と、一般的ではあるものの、複雑度が若干高いアーキテクチャを Fidelity が選んだ理由をご紹介します。
このガイドの学習内容
GitHub ができるだけ少数の Organization を使用してビジネス ニーズを満たすことを推奨する理由
複数の Organization を使用する場合の一般的なビジネスの考慮事項
GitHub Organization を企業構造に合わせて過度に連動させることが問題になる理由
企業に最適な Organization 構造を選択する方法および考えられるモデルのいくつかの例
推奨される Organization の数
GHEC を使用するお客様の一部は、全コンテンツのコラボレーションに 1 つの Organization を使用しています。Enterprise アカウント内で複数の Organization を使用するお客様もいます。コンテンツを完全に分離して、次のようなビジネス要件を満たす必要があるためです。
法的なまたはビジネス別の、一連のコンテンツ、ユーザーなどの区別
データ分類要件または規制要件
合併、買収、ダイベスティチャーなどの商業的な変化
ユーザーが新機能を試し、トレーニングの演習を完了するためのテスト/サンドボックス領域を提供できること
一般的に、Enterprise 内にはできるだけ少数の Organization を作成して、ビジネス ニーズに対応することをお勧めしています。可能であれば、1 つのみを使用します。それぞれの Organization に独自の管理および設定が必要であるため、Organization を追加するとオーバーヘッドが増加します。Organization は互いから独立性を保つため、定義上サイロが生まれます。また、オープンソースの原則が社内で適用されている場合は、コラボレーションおよびインナーソース文化を阻害する可能性があります。チームとリポジトリ権限を代用できる場合は Organization を使用しないようにしてください。
企業構造と Organization
GitHub Organization を企業構造に合わせて過度に連動させないようにすることをお勧めします。
GHEC を設定する際、権限の管理と通知数の抑制のためにはプロジェクトや部門ごとに独立した Organization を作成するのが最適であると最初は思うかもしれません。GitHub ではこれをお勧めしていません。Organization 構造の柔軟性を制限し、長期的にはより複雑な課題となる可能性があります。
その理由の 1 つは、企業構造は頻繁に変更される可能性があり、その変更が現状を破壊するほど大掛かりな可能性があります。通知の数が少ない可能性もあります。GHEC 設定は GitHub Organization に影響せず、また下流での作業 (インテグレーションのパスの再登録や外部リンクの更新など) を生むことなく、企業の再編成に緩やかに対応できる必要があります。さらに、企業構造に合わせて連動させると、会話のサイロが増加し、管理の負担が膨らみます。
代わりに、1 つの Organization 内で GitHub チームを使用して、ロールや権限を指定する方法を検討してください。同じ Organization 内のチームとユーザーは、互いのコンテンツを簡単に発見し、質問し、互いにメンションできます。チームとユーザーが複数の Organization に分散している場合、これはより複雑になります。チームが複数の Organization にアクセスする必要がある場合、各 Organization にこのチームを作成し、適切な ID プロバイダーにマッピングしなければなりません。管理者は、コンテンツを表示したり質問したりするためだけにユーザーを複数の Organization に追加、管理してほしいと要求され、たちまち悩まされることになります。これにより、Organization を最初から分離しておくメリットの多くが打ち消されます。
最後に、全てのプロジェクトに Organization を持つと、インテグレーションの管理負担が増加します。GitHub App は Organization にインストールされるため、多くの Organization を持つ Enterprise では、各 Organization に各インテグレーションをインストールし、管理する必要があります。また、Organization ごとに GitHub App のインストール数制限が 100 件であることに留意してください。
企業に最適な Organization 構造の選択
以下では、GitHub Enterprise Cloud のお客様が導入に成功している 3 つの一般的なモデルを詳しく確認します。お客様はビジネスにおいて、最小限の Organization を効果的に活用しています。
モデル 1: 単一の Organization
このモデルでは、全てまたはほぼ全てのリポジトリに対して 1 つの Organization を使用しています。小規模または中規模の Organization (開発者が 5,000 人未満) では、このアプローチを用いて GitHub 環境を管理しています。
このモデルでは、ほとんどのユーザーが Organization の基本レベルの権限を [なし] に設定しています。この場合、リポジトリを表示し、変更を提案するには、全てのユーザーが全てのリポジトリを明示的に追加する必要があります。このアプローチのみを使用すると、サイロが生まれ、可視性が大きく制限され、インナーソースを大いに阻害します。この傾向に対抗するため、チームを使用して可用性を守ることをお勧めします。たとえば、「全てのメンバー」チームを作成し、このチームをコラボレーション向けに開かれたリポジトリに追加します。さらに、この種のチームが全てのリポジトリにデフォルトで自動的に追加されるようにし、その後、必要な人のみにリポジトリが表示されるように限定する必要がある場合の例外プロセスを作成することもできます。
例外
酌量が必要な事情に対応するため、このモデルには少々異なった形が存在します。たとえば、非常に慎重に対応すべき顧客のプロジェクトなど、他の全ての作業から完全に隔離しておく必要があるプロジェクト向けの「極秘」 Organization を 1 つか 2 つ管理する場合があります。その場合も、大半の作業は 1 つの Organization で行われます。
同様に、知的財産法に関する課題に対応するために、特定の拠点のチームが管理するリポジトリを区分して、独立した Organization を使用する場合があります。
GitHub に移行したのは、チームを単一のプラットフォームに統合して、インナーソースを促進するためです。当社のチームは世界中に分散しており、以前はそれぞれが独自のシステムを使用していました。そのため、一緒に仕事を行うのが困難を極めました。さまざまシステム、ポリシー、チームなどを扱わなければなりませんでした。今では、全ての開発者と社内のコードを単一の GitHub Organization で管理しています。社内のリポジトリはデフォルトで読み取りアクセスに設定しており、コードの発見と再利用もより簡単になりました。
同時に、オープン ソースのコラボレーションやテスト用の追加の GitHub Organization も設定してあります。 このように、ソフトウェア開発の大部分を単一の Organization で行うことによって、シンプルさと可視性を持って作業しながらも、明確な境界と権限を保つことができます。
モデル 2: 赤-青-サンドボックス-アーカイブ
赤-青-サンドボックス-アーカイブ モデルは 2 つの主要な Organization とサンドボックスを使用します。以下で、各 Organization の機能を説明します。
青の Organization
青の Organization は開発者向けの主要なコラボレーション スペースとして機能します。リポジトリの 90% がここに存在します。基本レベルの権限を「書き込み」に設定して、インナーソースを促進し、ユーザーによるリポジトリへの変更提案を推奨します。同時に、青の Organization ではリポジトリのブランチ保護 (このモジュールの後のガイドで説明します) を使用して、ユーザーが変更の提案のみを行えるようにします。提案された変更は定義されたコード レビュー および承認プロセスを経てから受け入れられます。
その後、チームを通じてリポジトリにより、より高レベルの権限を付与します。これは各チームのリポジトリ ページで確認できます。青の Organization で発生するアクティビティの大部分では、チームとインテグレーションを管理する負担が最小限になります。
赤の Organization
赤の Organization は必要な人のみに表示されるように限定する必要があるリポジトリ向けです。Organization のデフォルト権限を[なし] に設定して、リポジトリを読み取る、または変更を提案するためにはリポジトリへのチームの明示的な追加が必要になるようにします。
この Organization には、不要な独自の制約を抑止するために、リポジトリとチームの作成に関する、定義されたプロセスを用意する必要があります。
サンドボックス Organization
サンドボックス Organization は、全ユーザーがリポジトリを作成し、実験できる共有スペースを提供します。このスペースは可視性が高く、個別に個人リポジトリを使用するよりも効果的なコラボレーションが促進されます。開発者が個人リポジトリを作成することを抑止するために GHEC を設定した場合、このような Organization は特に重要になります。
サンドボックス Organization を使用することが決定した場合、サンドボックスから赤または青の Organization に成果物を移動するプロセスを定義して、実験が正式な管理下に移行されるようにする必要があります。
アーカイブ Organization (任意)
最後に、任意であるアーカイブ Organization には活発に保守されなくなったリポジトリが含まれています。どのリポジトリも、全てのユーザーに対して読み取り専用に設定してアーカイブできますが、このアーカイブされたリポジトリは既存の Organization に残しておくこともできます。独立した Organization に、アーカイブされたリポジトリの所有権を移譲し、他の Organization を活発な作業のために残しておくことを望む企業もあります。なお、このようにすることを選択すると、リポジトリのオーナー/名前構文が変わります。また、元の Organization にリポジトリが存在していることをユーザーが想定している場合は GitHub でリポジトリを探すことが困難になる可能性があります。
当初、当社は GitHub の Organization を使用した Fidelity 製品モデルのミラーリングを試みましたが、Organization の数が多くなることがわかりました。アクセスと制御管理の観点や、インナーソース、イネーブルメント、オンボーディング、サポートに関するスケーリングの課題から、困難な状況に陥ることにすぐに気付きました。
最終的に赤-青-サンドボックス-アーカイブを使用することにしたところ、インナーソース、再利用、発見を促進するオープンで目に見えるモデルを利用できるようになると同時に、機微性が高く規制されたコードに必要なセキュリティとコンプライアンス管理が実現されました。
より幅広いコラボレーションとイノベーションを可能にし、ハッカソン スタイルのイベントをサポートするために、開発者は最小限のポリシーと制限でサンドボックス Organization にリポジトリを作成できます。また、青の Organization 内のプロジェクトを自身の個人的なユーザー スペースにフォークして他のユーザーとコラボレーションし、プル リクエストを送信して変更をメイン プロジェクトにマージすることができます。このようにして、摩擦のないインナーソースのエコシステムが構築され、発見やコントリビューションが行いやすくなりました。
モデル 3: 投資先企業
青-赤モデルが企業の内部構造に十分に適合しないシナリオがいくつかあります。
たとえば、比較的変更が少ない事業部門に数万人の従業員が区分される非常に大規模な企業にとっては、このモデルは不十分です。このような企業には、リテールバンキング、個人投資、資本市場、保険部門から構成される国際的な銀行などがあります。
また、この陣営には互いから独立して機能する事業ユニットを持つ投資先企業も含まれます。このような企業には放送ネットワーク、制作スタジオ、ストリーミング サービス、インタラクティブ ゲームの会社から構成されるメディア企業などがあります。このような企業では合併、買収、ダイベスティチャーなども定期的に行われます。
超大規模企業においては、GHEC の Organization 構造に企業の最上位の部門をマッピングすることをお勧めします。通常、最上位の部門は CEO の 1 段階下位の部門であり、変更が少ない性質があります。多くの場合、Organization はこのような部門内で生まれ、最上位の構造は保たれます。
投資先企業においては、Organization は各ビジネス エンティティにマッピングされる必要があります。Organization はある企業から別の企業に移譲でき、合併やダイベスティチャーの管理の負担を軽減します。
可能な場合、投資先企業または主要な事業部門に対して Organization を 1 つに保つことをお勧めします。本質的には、これは上で説明した 1 つの Organization を複数導入する戦略です。最も多い場合でも、各主要部門に最小限の青-赤の構造を導入することをお勧めします。この構造を選択する場合は、全部門に対して 1 つのサンドボックスを導入し、アーカイブ リポジトリは主要な Organization 内に保持することを検討してください。このようにすることで、管理すべき活発な Organization の数を最小限にすることができます。
投資先企業のオープン ソース プロジェクトに関する注意: オープン ソース プロジェクトは企業の Organization から独立させて、専用の Organization に保持する必要があります。そうしない場合、特に外部コラボレーターがいる場合はセキュリティ境界の問題が発生します。Enterprise Managed User (EMU) 環境を使用している場合、制限を考慮すると別の Enterprise アカウントを持つ必要がある可能性があります。
Enterprise アカウントでの Organization の作成、管理
組織に最適な構造を決定したら、Enterprise オーナーは Enterprise アカウントが所有する Organization を管理できます。管理方法には次のとおり、いくつかの異なるオプションがあります: 新しい Organization を作成する、既存の Organization を招待または移譲する (EMU を使用していない Enterprise のみ)、Organization のメンバーシップと所有権を管理する。
新しい Organization を作成する
Enterprise で新しい Organization を作成すると、リポジトリ、プロジェクト、ドキュメント、コラボレーション向けに、独立した新しいコンテナーができます。Organization の名前は、Organization を所有する Enterprise にかかわらず GitHub.com 全体で一意である必要があります。Enterprise アカウントの名前は Organization の URL やパスに含まれません。
Enterprise アカウントが所有する Organization を作成する Enterprise オーナーは、自動的に Organization のオーナーになります。作成プロセス中に追加の Organization のオーナーを選択できます。
既存の Organization を招待または移譲する
注意: このオプションは EMU を使用していない企業のみが使用できます。EMU Enterprise では移行ツールを使用しない Enterprise 外コンテンツの取り込み、取り出しが制限されています。
Enterprise アカウントに取り込みたい Organization が GitHub.com にすでに存在する場合、その Organization をお使いの Enterprise アカウントに移譲または招待できます。既存 Organization の所有状態によっては、所有権または現在の Enterprise オーナー (Enterprise の一部である場合) または Organization のオーナー (スタンドアロン Organization の場合) の承認が必要になります。Enterprise オーナーを受け取るユーザーは、現在のオーナーが受け入れた後に移譲の最終承認を与える必要があります。
外部の Enterprise を自分の Enterprise に移譲する場合はいくつもの重要な考慮事項が適用されます。この考慮事項の詳細はこちらのドキュメントで説明されています。その中で留意しておくべき最も重要な考慮事項は、移譲される Organization から追加される一意のユーザーを受け入れるためには、お使いの Enterprise アカウントに十分なユーザー ライセンスが必要になるということです。
このオプションは合併および買収、移行、Organization の一部で GitHub の Enterprise プラン以外を使用していた場合のアップグレードで役に立ちます。長期戦略に応じて、移譲された Organization を独立して保つ、またはリポジトリを別の Organization にさらに移譲する必要があるかもしれません。
Organization のメンバーシップと所有権を管理する
Enterprise オーナーは、Organization のオーナーまたは Enterprise 内の任意の Organization のメンバーとして自分を追加できます。ただし、メンバーシップの場合は Organization レベルの SAML やクロスドメイン ID 管理システムによって管理されていない Organization に限ります。これは Organization のオーナーが退職したり、担当できなくなったりした場合、またはこのいずれかのロールのアクセス権が必要な場合に役立ちます。また、アクセス権が不要になった場合はこのインターフェイスを使用して自分からロールを削除できます。
SAML およびクロスドメイン ID 管理システムを使用して管理される Organization については、プロビジョニングに ID プロバイダーを代用して、自動化による意図しないプロビジョニング解除を防止するようにします。
次の内容: GitHub Enterprise Cloud の Enterprise 設定とポリシーを構成する
これで、Enterprise アカウント内で複数の Organization を使用する場面と方法について、情報に基づいた意思決定を行えるようになりました。次は、Enterprise および Organization の両方のレベルで設定する必要のある主要な構成について確認します。
その他のリソース: