はじめに

こんにちは、ももたけです。ナビタイムジャパンで開発サポート部門に所属し、Atlassian製品をはじめとした開発系ツールの導入や運用促進を担当しております。Atlassian製品としては、Jira/Confluence/Bitbucketを500名ほどの規模で利用しており、権限の棚卸しを1年に2度実施しております。

この記事を見た方が、もしカオスになっている権限周りにお困りの場合に参考になればと思います！

Bitbucketのクラウド版に移行して変わったこと

ナビタイムジャパンでは、1つのBitbucketで全社のリポジトリを管理しており、その数は3500個を超えます。オンプレミス版を利用していた頃からこの膨大な数のリポジトリを棚卸ししていますが、クラウド版に移行するにあたって権限管理の点で1つ大きな差がありました。それは「プロジェクトごと」に権限を付与できないことです。

ナビタイムジャパンの場合を例にすると150個ほどのプロジェクトが存在します。サーバー版で「プロジェクトごと」に権限の棚卸しをする場合は、各プロジェクトのリーダーにそれぞれ1つのプロジェクトを確認してもらえれば、権限が問題ないことが担保できます。

一方でクラウド版で棚卸しを実施する場合は、3500個すべての権限を確認する必要があるため、サーバー版が150箇所の確認で済むことに比べて、23倍以上の労力が必要です。

問題になったこと

多くのリポジトリを権限管理しようとする場合に、2つほど問題が発生しました。

① 誰に棚卸しを依頼すればいいのか分からない

リポジトリの一覧画面のリンクだけを全社宛に送って「権限の棚卸しをしてください」と連絡しても、どのリポジトリの管理者になっていて、確認する必要があるのかが分からない人が殆どです。
仮に覚えている方が多くいたとしても、分からない方が一部でもいれば、すべてのリポジトリを確認できているとはいえない状況になります。
ほとんど望みがない状況なので何か手を打つ必要がありました。

② リポジトリごとの権限管理になることによって、同じメンバーの割当を別々のリポジトリに何度も行う必要がある

リポジトリは多いと十数人を超える規模で開発し利用しているため、それぞれの権限が現状で問題ないのか確認することが必要です。
異動したメンバーにadmin権限が残ったままになっていたり、新たに参加したメンバーに権限が付与されておらず、Pushしようとした場合にエラーになったりと、ここを疎かにすると実務に影響がでたりします。

リポジトリ管理者の一覧作成

「①誰に棚卸しを依頼すればいいのか分からない」の問題に対して、リポジトリ管理者のリストを作成することで対応しました。Bitbucketには多数のAPIが用意されており、下記のドキュメントにまとまっています。

API 仕様書 (リポジトリ一覧を取得)
API 仕様書 (リポジトリの権限を取得)

まずリポジトリの一覧を取得したあとに、それぞれの管理者を取得します。管理者取得APIを実行する場合はJQLが有効なため、q=permission%3D\"admin\"を付与すると、レスポンスがadminのみになるため、特にメンバーの権限が必要でない場合はつけておくとよいです。

# リポジトリ一覧を取得するサンプルリクエスト
https://api.bitbucket.org/2.0/repositories/{workspace_name}

# リポジトリの権限を取得するサンプルリクエスト
https://api.bitbucket.org/2.0/workspaces/{workspace_name}/permissions/repositories/{repos_name}?q=permission%3D\"admin\"

こちらをもとにGoogleのスプレッドシートを用いて一覧化しました。
取得した情報としては、

• プロジェクト名

• リポジトリのURL

• 管理者

になります。ここまで表示できればスプレッドシート上で自分の名前で検索して棚卸しが可能です。また、全リポジトリが出力されているため、まだ確認が終わっていないリポジトリがすぐにわかります。

リポジトリの権限を取得するためのAPIの注意

こちらのAPIですが、どのグループで権限を追加されているか把握できない仕様になっております。しかし、管理者グループなどをすべてのリポジトリに紐づけている場合は、すべてのリポジトリにadminの方の名前が出てくることになるため、確認するべきものがわかりづらくなります。

たとえば、とあるリポジトリにadminグループ（Aさん、Bさん、Cさん）とリポジトリの管理者Dさんが権限付与されている場合は、APIの返却が管理者（Aさん、Bさん、Cさん、Dさん）といった返却になります。本当に確認するべきDさんという情報は、adminグループ（Aさん、Bさん、Cさん）に埋もれてしまっていて分かりづらいです。

グループを活用した権限管理

「② リポジトリごとの権限管理になることによって、同じメンバーの割当を別々のリポジトリに何度も行う必要がある」の問題に対して、グループ機能を利用することで対策しました。ナビタイムジャパンでは殆どのケースでプロジェクト単位でリポジトリを管理している事が多いため、プロジェクト単位のグループを作成しておくと、非常に便利です。

メンバーの増減が発生した場合に、グループの設定を変更するだけでよく、全てのリポジトリの設定変更を実施する必要がなくなります。

グループ利用の注意

グループは一度作成すると、名称の変更ができません。当社は、現状に合わせて組織を柔軟に変更していく体制のため、年に何度か作り直すことがあります。グループを整備する上で、こういった変更に柔軟に対応できるようにしておくことが重要です。

実際の整備の例としては、組織体制は「A事業-Bプロジェクト-Cチーム」となっていますが、グループは「A事業-Bプロジェクト」という名前で作成し、チーム異動などには柔軟に対応しています。

おわりに

オンプレミス版からクラウド版に変更すると、権限周りで大きな違いがありました。グループの再作成が発生した場合に、再割り当てが必要なプロジェクトが分からないなどの問題もまだまだあり、よい権限管理方法については模索中です。

今回の記事によって、権限周りの管理がすこしでも楽になりますと幸いです。最後までお読みいただきありがとうございました。