Github Organizationおすすめ初期設定

メタサイト エンジニアのFJです。

github organizationの初期設定に悩む・・・というマネージャー・CTOの方は多いのではないでしょうか

メタサイトでは、今までGCPへのセルフホスティングでgitlabを運用していましたが、github（まずはteamプランです）への移行を決めました。

会社用githubアカウントか個人・会社併用か

github organizationに移行しようとなると、話題になりがちなのが、各エンジニアが会社用のgithubアカウントを用意するか？用意しないか？です。

githubの利用規約では、無料アカウントの複数保有を禁止しています。

「無料アカウント」なので、厳密には各エンジニアの個人アカウントが有料課金されていれば、複数保有をしても構わないようですが、各エンジニアの個人アカウントに課金（月4ドル）しつつ、organizationも課金するというのは現実的ではありません。

GitHub利用規約 - GitHub Docs https://docs.github.com/ja/site-policy/github-terms/github-terms-of-service

また、1アカウントで仕事もプライベートの開発もする事でgithubアカウントを育てて欲しいという思いもあります。

メタサイトでやってみたorganization設定

プロフィールページ

ここでは以下の項目の設定をしています。

• オーガニゼーション名
• URL
  • コーポレートサイトか、エンジニア採用サイトが好ましいかと思います
• Location
• Billing email (Private)
  • 請求書・領収書のPDFが送られるメールの宛先になります。弊社ですと経理メーリングリストを設定しています。
    • ここで設定するメールアドレスはgithubアカウントに紐づいている必要はありません。
• 支払い請求先メールアドレスを設定する - GitHub Docs https://docs.github.com/ja/billing/managing-your-github-billing-settings/setting-your-billing-email#setting-your-organizations-billing-email

Member privileges

直訳すると「メンバー特権」ですが、役割としては権限管理です。

まずは、「Base permissions」です。Github Organizationの中で最も重要かと思います。

Base permissionsはNo permission、Read、Write、Adminの4種類の権限が用意されております。

弊社ではNo permissionを選択しました。

この選択をすると、Organization配下のすべてのレポジトリに対して、OrganizationOwner以外にアクセス権が無い状態になります。

このままでは、エンジニアが開発したソースコードをPullもPushもできません。後ほど解説します。

Repository

デフォルトブランチの名前をmasterからmainへ変更しました。

Authentication security

Organizationに参加するメンバーに対して2段階認証を強制するかどうかです。

ここは落とし穴があり、英語ではアラートが出ていますが、強制した場合、2段階認証を有効にしていないユーザーはOrganizationから強制的に削除されます。

0からOrganizationを作成する際はあまり気にならないと思いますが、既に作成してエンジニアが参加しているOrganizationで2段階認証を強制する場合は、全員が2段階認証を有効にしていることを確認してから実行して下さい。

Organizationのメンバーが2段階認証を有効にしているかどうかは、以下の方法で確認してください。

Organization 内のユーザが 2 要素認証を有効にしているかどうかを表示する - GitHub Docs https://docs.github.com/ja/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/viewing-whether-users-in-your-organization-have-2fa-enabled

Organization で 2 要素認証を要求する - GitHub Docs https://docs.github.com/ja/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization

Code security and analysis

自動でpackage.jsonなど、マニフェストファイルを見て、セキュリティ上問題があるライブラリを検知し、アラート及びPRの発行まで行ってくれます。

PRを作成するだけで、自動でマージはされませんので安心してください。

また、PR作成後に更なるアップデートがあった場合はPRの内容もアップデートされます。

チーム設定

Organization設定のMember privilegesにおいて、No permissionを選択したと書きましたが、この設定の影響により、新規に追加されたメンバーは一切のレポジトリへのアクセスができません。

ですが、レポジトリ1つ1つに各メンバーの権限を付与していては非効率的で管理が破綻する事は目に見えています。

そこで、チームにレポジトリとメンバーを紐付ける事で管理を効率的かつ破綻しない管理が可能になります。

サンプルとして「Blog Team」というチームを作成してみました。

Blog Teamにレポジトリを紐付けてみました。

また、赤矢印で指しているところで、権限が選択可能になっています。

権限は5種類用意されています。

Organizationのリポジトリロール - GitHub Docs https://docs.github.com/ja/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization

よく使うのはWriteとAdminかと思います。

弊社では、エンジニアにはWrite、マネジメントにはAdminを振っています。

また、弊社には業務委託で働いて頂いているエンジニアも多数いらっしゃるので、プロジェクト毎にチームを作成し、そこへ担当する業務委託のエンジニアをメンバーとして追加し、Write権限を付与しています。

エンジニアが参加していないプロジェクトのレポジトリにはアクセスできないようにしています。

理想とするチーム構成

セキュリティの関係で実際のチーム構成はお見せできませんので、理想とするチーム構成を以下に整理します。

• engineer
  • 社員エンジニア
• manager
  • マネージャー、部長
• blog-project
  • 業務委託エンジニアAさん
  • ...
• xxx-project
  • 業務委託エンジニアBさん
  • ...

チーム構成と紐付けるプロジェクトの関係

上記で理想とするチーム構成を示しましたが、チームとプロジェクトの関係は以下のようになります。

• engineerチーム
  • blog-project
    • Write権限
  • xxx-project
    • Write権限
• managerチーム
  • blog-project
    • Admin権限
  • xxx-project
    • Admin権限
• blog-projectチーム
  • blog-project
    • Write権限
• xxx-projectチーム
  • xxx-project
    • Write権限

blog-projectチーム、xxx-projectチームには、それぞれのプロジェクトしか書き込み権限を持たせない構成にしています。