Enterprise の種類を選択する
GitHub Enterprise Cloudの使用を開始する前に、Enterprise の種類を選択する必要があります。 GitHub の個人用アカウントを使用してエンタープライズ リソースにアクセスしたり、必要に応じて追加の SAML アクセス制限を構成したり、Enterprise Managed Users で ID プロバイダー (IdP) を使用して Enterprise のアカウントをプロビジョニングおよび制御したりできます。
ニーズに最適な Enterprise の種類を特定するためのサポートについては、「GitHub Enterprise Cloud の Enterprise の種類の選択」を参照してください。
複数の所有者を割り当てる
企業に所有者が 1 人しかない場合、その所有者に連絡できないと、その企業のリソースにアクセスできなくなるおそれがあります。 リソースへのアクセスを保護するため、企業内の少なくとも 2 人のユーザーに所有者ロールを与えることをお勧めします。 詳細については、「Enterprise を管理するようユーザを招待する」を参照してください。
ポリシーの使用
ポリシーを使って、ビジネス ルールと規制コンプライアンスを強制することをお勧めします。
各エンタープライズ ポリシーを使って、組織レベルでポリシーに使用できるオプションを制御します。 組織のポリシーを構成することを組織所有者に許可するポリシーを適用しないことを選択できます。または、一連のオプションから選び、あなたの企業が所有するすべての組織に適用することもできます。 詳しくは、「エンタープライズ ポリシーについて」をご覧ください。
組織の数を最小限に抑える
ほとんどの事業は 1 つの組織から提供されるのが最良です。 コンプライアンス上やセキュリティ上の理由から複数の組織を必要とする企業もありますが、可能な限り少なくなるように努めてください。 組織の数が少なければインナーソースの実践が奨励され、幅広いオーディエンスが参加する話し合いが可能になり、管理費が減ります。
作るべき組織の数とその構造について詳しくは、「エンタープライズ内の組織を構成するためのベスト プラクティス」をご覧ください。
ユーザー所有のリポジトリで大規模なコラボレーションを行わない
可能であれば組織所有のリポジトリでコラボレーションを行い、ユーザー所有のリポジトリでのコラボレーションは最小限に抑えることをおすすめします。 組織所有のリポジトリにはより高度なセキュリティと管理機能が備わっており、エンタープライズのメンバーシップが変更されても引き続きアクセスできます。
人間が判読できるユーザー名を使う
エンタープライズ メンバーのユーザー名を制御する場合は、人間が判読できるユーザー名を使い、マシンによって生成された人間が判読しにくい ID は使わないようにします。
エンタープライズのプライベート リポジトリ内でユーザー名の表示を管理できます。 詳しくは、「Organization のメンバー名表示を管理する」を参照してください。
README の作成
Enterprise での変更等をメンバーと共有するために README を作成する必要があります。 たとえば、README を使用すると、メンバーが Enterprise 内のさまざまな Organization について学習したり、重要なリソースへのリンクを共有したり、Enterprise の設定やポリシーに関する情報を共有するのに役立ちます。詳しくは、「Enterprise の README の作成」をご覧ください。