Zenn
🔑

GitHub Organization の管理の仕方

2020/10/15に公開
GitHub
マネジメント
tech

導入

GitHub の Organizationの管理をする機会を得ましたが、管理機能については不勉強でしたので、公式ドキュメントを読み込み、ここにまとめます。

本記事は、主に以下のような疑問を持つ方に役立つ情報を記述しています。

  • Organizationってなに？Projectsってなに？Teamってなに？
  • どういうまとまりで管理者がいる？
  • Organizationには個人で加入可能？Teamに入らないといけない？
  • Teamは入れ子構造にできる？
  • 権限はオーバーライドされる？権限のレベルにはなにがある？
  • Organizationでまとめられた大きなグループを「階層型組織として管理するTeam」という概念、「プロジェクトごとに管理するProject」という概念がある中で、権限周りの管理はどうやって区分けしたらいい？

1. 各用語の定義

Organizationとは？

Organizationについて | GitHub Docsによれば、

Organizationは、企業やオープンソースプロジェクトが多くのプロジェクトにわたって一度にコラボレーションできる共有アカウントです。 オーナーと管理者は、Organizationのデータとプロジェクトへのメンバーのアクセスを、洗練されたセキュリティ及び管理機能で管理できます。

つまり、Organizationとは、

  • 複数のプロジェクト（GitHubにおけるProjectのことを指していると予想）を束ねるものである
  • 複数のデータ（リポジトリやアクションを指す？）を束ねるものである
  • Organizationを管理する人として、オーナーと管理者が存在する
  • Organizationの保持する複数のプロジェクトやデータに対して、Organizationのメンバーがアクセスできる機能があり、アクセス権限等はOrganizationのオーナーや管理者によって適切に管理される（＋管理を支援する機能がある）

と解釈できる。

Organizationが保持する機能

Organizationの配下にTeamというさらに細かい組織を構築することができ、アクセス権限の管理やメンションなども入れ子構造にできる。（Team単位でアクセス権限管理、Teamに対してメンションができる、という意味）

Teamとは？

Teamについて | GitHub Docsによれば、

Team は、Organization のメンバーによって構成されるグループであり、カスケードになったアクセス権限とメンションを伴う会社やグループの構造を反映します。

about-team_01

Teamにまつわる機能としては、以下のようなものがある

  • Organizationのオーナーとチームメンテナは、Teamに対して、Organizationのリポジトリへの管理・読み取り・書き込みアクセスを付与することができる（Organizationの管理者は？）
  • Organizationのメンバーは
    • Team名をメンションすることで、Teamメンバー全員に一括で通知を送ることができる
    • Teamからのレビューをリクエスト（PullReq？）することによっても、Team全体に通知を送ることができる
    • プルリクエストがオープンされたリポジトリへの読み取りアクセスを持つ特定の Team からのレビューをリクエストできる（？？？）
    • コードの特定の種類や領域に対して Team をオーナーとして CODEOWNERS ファイルで指定できます。

Teamの可視性

  • Public Team
    • Organization内の全メンバーが「見る」「メンションする」ことが可能
  • Private Team
    • Organizationのオーナー、Teamのメンバーのみ「見る」ことが可能
    • 親チームの下に入れ子にしたり、子チームを持つことは出来ない
    • 外部なパートナーとやりとりする時やセンシティブな情報を扱う時に適している、とされている

Teamのページ

各Teamは、Organization内に独自のページを持つことができる。
Teamのページでは、

  • Teamメンバー、子チーム、Teamのリポジトリを見ることができる
  • OrganizationのオーナーとTeamのメンテナは、Teamの設定を編集できる

入れ子Teamの仕様説明

  • Public Team なら入れ子構造にできる
  • Teamの入れ子は何階層でも良い
  • 親チームは、複数の子チームを持つことができる
  • 親チームが、メンションされると配下の全子チームにも通知が飛ぶ
  • 子チームは、親を一つしか持てない
  • 子チームは、親のアクセス権限を引き継ぐ
  • 子チームのメンバーは、親チームの直接のメンバーではない
  • 親チームの権限とメンションの共有先を一覧したい場合は、親チームのページのMembersを見るとよい

Project boardsとは？

プロジェクトボードについて | GitHub Docsによれば、

GitHubのプロジェクトボードは、作業を整理して優先順位付けするための役に立ちます。 プロジェクトボードは、特定の機能の作業、包括的なロードマップ、さらにはリリースのチェックリストのためにも作成できます。 プロジェクトボードを使うと、要求に適したカスタマイズされたワークフローを作成する柔軟性が得られます。

プロジェクトボードは、Issue、プルリクエスト、選択した列内でカードとして分類されるノートから構成されます。 列内のカードの並び替え、列から列へのカードの移動、および列の順序の変更には、ドラッグアンドドロップまたはキーボードショートカットが利用できます。

プロジェクトボードのカードには、ラベル、アサインされた人、スタータス、オープンした人など、Issueやプルリクエストに関連するメタデータが含まれます。 プロジェクトボード内で Issue あるいはプルリクエストのタイトルをクリックして、Issue やプルリクエストを見て簡単な編集をすることができます。

タスクのリマインダとして機能するノートを列内に作成し、GitHub 上の任意のリポジトリからの Issue やプルリクエストを参照させたり、プロジェクトボードに関係する情報を追加したりすることができます。 ノートにリンクを追加することで、他のプロジェクトを参照するカードを作成することもできます。 ノートでは要求を満たせない場合、ノートを Issue に変換することができます。 プロジェクトボードのノートのIssueへの変換に関する詳しい情報についてはプロジェクトボードへのノートの追加を参照してください。

プロジェクトボードは３種類ある

  1. ユーザーが所有するプロジェクトボード（Projects in User Profile Page）
    • 任意の個人リポジトリからのIssue及びプルリクエストと紐づく
    • 最大25個のリポジトリと紐付けられる
  2. Organization内プロジェクトボード（Projects in an Organization Profile Page）
    • Organizationに属する任意のリポジトリからのIssue及びプルリクエストと紐づくことができる
    • 最大25個のリポジトリと紐付けられる
  3. リポジトリプロジェクトボード（Projects in a Repository Page）
    • 単一のリポジトリ内のIssueとプルリクエストに紐づくことができる
    • 他のリポジトリのIssueやプルリクエストを参照するノートも含まれる

本記事では、省略するが、プロジェクトボードについて詳細に知りたい場合は以下のドキュメントが参考になる。

2. 組織の構造とアクセス権限管理

OrganizationとTeamの管理に関するドキュメント などを参考に記述する。

組織の構造

Organization周辺の人物は、以下のように分類できる。

GitHub-Org-Team-Structure

  1. OrganizationのOwner/Admin
  2. Organizationのメンバー & Organization内のTeamのOwner/Admin（GitHub Docsでは、チームメンテナと呼称されている）
  3. Organizationのメンバー & どのTeamにも所属していない
  4. Organizationのメンバー & Organization内のTeamのメンバー
  5. Organizationの外部のGitHubユーザー

※OrganizationのOwner兼あるTeamのメンバーもあり得るが、（複数ルートで権限をもつ場合）より強い権限が優先されることから除外している

さて、

組織の構造を決める要素、すなわちグルーピングの機能として、「Team」「Project」という2つが存在することがわかった。必要な情報を整理すると、

  • Team
    • アクセス権限と通知をグループ化することができる
    • グループを階層化することができ、アクセス権限や通知の設定もオーバーライドされる
  • Project
    • 一つの個人 or Organization or リポジトリに紐づく形で存在する
    • 階層化することはできない。常にフラットな状態。

すなわち、以下のような運用を想定されているのではないかと考えられる

  • 組織内のあらゆるリソースに関するアクセス権限のグループ化、情報通達のグループ化をする目的でメンバーをまとめるために「Team」を使う（必ずしも階層化する必要はない）
  • 一人のメンバーが複数のチームに所属することはできるが、管理がやや煩雑になりそうなので、控えておいた方がいいかも？
  • プロジェクト単位で情報をグループ化する目的で「Project」を使う
  • 一人のメンバーが複数のプロジェクトに参加することができて、管理面で煩雑さが増すことはない

アクセス権限の管理は誰が誰に対して実行できるのか？

  • Organaization以下の管理
    • 「OrganizationのOwnerまたは管理者」が
    • 「Organizationのメンバーまたはチーム」に対して実行できる
  • Team以下（子チーム含む）の管理
    • 「OrganizationのOwnerまたは管理者」が
    • 「Organizationのメンバー」に対して
    • 「Teamの管理者（ドキュメント中では、チームメンテナと呼称されている）」が
    • 「管理しているチームのメンバー」に対して実行できる
  • （Organizationの）Projectの管理
    • 「OrganizationのOwner」または「プロジェクトボードの管理者」が
    • 「Organizationメンバー」「Organization内のチーム」「外部のコラボレータ」に対して実行できる

設定可能な権限・ロールの種類

  • None：アクセス権限なし
  • Read：読み取り可能
  • Write：書き込み可能
  • Admin：管理可能

3. 細かい仕様（編集中）

  • Team無所属でOrganizationのメンバーであるユーザーをあるTeamに入れた場合、どのような変化がおきるのか？
  • 一人のメンバーは複数のTeamに入れるのか？（たぶん入れると思うけど）入れるとしたら、それぞれTeamごとの権限が異なる場合、そのメンバーはどういう権限を持つのか？強い権限が弱い権限を上書きする、という直感的イメージに従うのか？
    • Organization のプロジェクトボードに対するチームのアクセスを管理するによれば、

    • Organizationのプロジェクトボードに対して複数のアクセス経路がある場合（個人として、Teamを通じて、Organizationのメンバーとして）、プロジェクトボードに対する最上位の権限レベルが下位の権限レベルをオーバーライドします。

    • 他（リポジトリなど）の場合も同様と推測する。

Discussion