はじめに
こんにちは！
SRE (Service Reliability Engineering) の多田です。
みなさんは GitHub がお好きでしょうか？
私は大好きで、特にマスコットキャラクターの Octocat の愛らしさには癒されています 🐙
本記事では、現在は再編済みとなっている旧「プロダクト開発センター」体制下で運用していた 2 つの GitHub Organization を 1 つに統合した話をさせていただきます。
GitHub Organization の統合にはリソースの移行、CI/CDの整合性、メンバー周知、セキュリティ設定の差異など多くの課題が伴います。
本記事では、そうした実務的な課題をどう乗り越えたかを共有します。
旧プロダクト開発センターの成り立ち
まず、旧プロダクト開発センターという 1 つのセンターで、なぜ複数の Organization が運用されていたのか、という背景に少し触れておきます。
弊社の ホームページ にも記載がありますが、そもそも博報堂テクノロジーズの成り立ちとして、
マーケティング×テクノロジーの力で、社会と生活者に新しい価値や体験を提供するために、博報堂テクノロジーズは、博報堂ＤＹグループのテクノロジー戦略会社として、開発体制を集結し、体制強化・進化を目的として設立されました。
とあるように、開発体制を集結し設立されています。
旧プロダクト開発センターは、旧 IREP（現・ONE に統合）、negocia の 2 つの関連会社から成り立っています。
もともと各々の会社で GitHub Organization を契約してたものが、博報堂テクノロジーズの体制後もそのまま運用が続けられていました。
しかし、以下の理由から統合の検討を開始しました。
- コスト最適化 : Seats 料金や Actions の上限を一本化できる
- 運用負荷の削減 : アカウント管理ポリシーや監査設定をひとつに集約できる
- 情報の透明性向上 : Repositories や Issues を横断検索できる
- ベストプラクティスの統一 : ブランチ保護や自動化設定を標準化できる
Organization 統合に向けて
統合を進める前に、現状を把握し、統合が及ぼす影響を確認したうえで、統合の方針を定める必要があります。
現状の把握
| 旧 IREP Organization | negocia Organization | |
|---|---|---|
| Plan | GitHub Team | GitHub Team |
| Two-factor authentication | Require two-factor authentication | Require two-factor authentication |
| Organization secrets and variables | なし | あり |
| Installed GitHub Apps | あり | あり |
| Third-party application access policy | あり | あり |
Two-factor authentication が両方の Organization で既に強制されているのは良かったです。
仮に negocia Organization 側で強制されていない場合などは、まずは Two-factor authentication を設定していただくところから始めなければならなかったですが、ひとつ手間を省けたのは幸いでした。
その他で気になる点で言えば Organization secrets and variables Installed GitHub Apps Third-party application access policy あたりでしょうか。
Organization レベルで設定されている Secrets, Variables や App は移行作業が必要となります。
上記に記載しているもの以外にも Repository、Project の利用有無や数、Actions Runner など確認すべき点は多々ありますが省略しています。
*) Organization secrets and variables : Managing development environment secrets for your repository or organization
*) Installed GitHub Apps : Reviewing and modifying installed GitHub Apps
*) Third-party application access policy : Enabling OAuth app access restrictions for your organization
影響の確認
統合のメイン作業は Repository の Transfer になりますが、Repository を Organization 間で Transfer した時の影響については、公式のドキュメントが参考になります。
ポイントをピックアップすると、以下あたりでしょうか。
When you transfer a repository, its issues, pull requests, wiki, stars, and watchers are also transferred. If the transferred repository contains webhooks, services, secrets, or deploy keys, they will remain associated after the transfer is complete.
Transfer をすると Issue や Pull Request など、ほぼすべての情報が引き継がれます。
All links to the previous repository location are automatically redirected to the new location.
Transfer をすると Repository の URL が変わりますが、旧 URL へのリクエストは新 URL へリダイレクトされます。
こちらは検証をしましたが、Transfer 元の Organization の Seat を剥奪して、もとの Organization へアクセスできなくなっても正常にリダイレクトが行われます。
To transfer repositories to an organization, you must have permission to create repositories in the receiving organization, and to transfer repositories out of the origin organization.
Transfer を実施するには、
- Transfer 元の Organization で Transfer できる権限
- Transfer 先の Organization で Repository を作成できる権限
それぞれが必要となります。
統合の方針
統合の方針というのは、最終的にどの Organization へ集約させるのかという点です。
基本的には以下の 2 案になるかと思います。
- 一方の Organization へ移行する
- 新しく Organization を作成し、両方の Organization を移行する
検討した結果、以下の理由から 一方の Organization へ移行する の案となりました。
- 新しい Organization への移行だと、2 つの Organization 全てのリソースが移行対象となるが、一方へ寄せる形の場合は 1 つの Organization の移行で済むため。
- 新しい Organization への移行だと、移行期間に Seats の重複コストが多く発生する。
では、どちらの Organization を正として移行するかですが、Organization 内のリソース規模として negocia Organization よりも旧 IREP Organization の方が大きかったため、negocia Organization の内容を旧 IREP Organization へ移行させる方針としました。
Organization 統合
方針が固まったので、統合に向けての作業をリストアップしスケジュールを組み立てていきます。
すべてではないですが、ざっくりと以下のようなことを行なっていく必要があります。
タスクに起こし、タイムラインを引いて、それぞれのタスクを SRE なのか、プロダクト開発メンバーなのか、誰が作業を行うのか割り振りを行なっていきました。
- 統合事前作業
- 移行対象となる Repository や GitHub App などのリストアップ
- 移行順序のために、Repository 間などの依存関係の確認
- Organization Settings の差分の確認
- 担当の割り振り
- 移行タイムラインの設定
- ・・・
- 統合作業
- GitHub Actions の上限の引き上げ
- GitHub App のインストール
- OAuth App policy の設定
- Workflow permissions の設定と対応
- Repository などの移管作業とテスト
- ・・・
- 統合事後作業
- negocia Organization（統合元） からの Remove Seats
- negocia Organization（統合元）の閉鎖
- ・・・
統合の事前作業
Repository などを Transfer する前に Organization Settings の差から事前にいくつか作業を行なっておかなければならないものもありました。
いくつかピックアップしてご紹介します。
Organization secrets and variables
negocia Organization（統合元）では Organization Level の Secrets と Variables が定義され利用されていました。
もちろん 1 つ定義すれば使いまわせるので便利ではあるのですが、設定するには Organization Owner の権限が必要となります。
Owner 権限はあまりにも強いので、GitHub の管理を行っている SRE 内の、さらに一部のメンバーにしか付与していません。
Organization Secrets および Variables の設定のために Owner 権限を渡すことはできませんし、都度依頼をもらって対応するのも双方にそれなりな負担となります。
そのため、統合前に Organization Secrets, Variables を利用している箇所はすべて Repository Secrets, Variables に移行していただきました。
Workflow permissions
negocia Organization（統合元）では 「Read and write permissions」 が設定されており、すべての Actions で GITHUB_TOKEN が書き込み権限を持っていました。
一方、旧 IREP Organization（統合先）は「Read repository contents and packages permissions」です。
そのため、Repository の Transfer 後に CI/CD が権限不足で停止しないよう対応を行いました。
Workflow permissions は Repository Settings で Repository Level でも設定ができるため、Transfer 前までに、一度「Read repository contents and packages permissions」に変更して CI/CD をテストし、必要に応じて Actions で Permission を明示していただくようにしました。
ちなみに、対象の action でどの permissions の指定が必要になるかは、以下のツールを使うことでも調べることができます。
Organization アカウントの閉鎖
the organization name becomes available for use on a new user or organization account.
If the account namespace includes any public repositories that contain an action listed on GitHub Marketplace, or that had more than 100 clones or more than 100 uses of GitHub Actions in the week prior to deletion, GitHub permanently retires the owner name and repository name combination (
OWNER/REPOSITORY-NAME) when you delete your account.
ドキュメントにも記載がありますが Organization アカウントは削除して 90 日が経過すると、同じ Organization Name を利用できるようになります。
Organization Name と Repository Name の組み合わせ (OWNER/REPOSITORY-NAME) も条件によりますが再利用が可能となっています。
もともとは統合が完了したら移行元の Organization Account は削除しようと考えていたのですが、以下の理由から削除せずに残すこととしました。
- negocia という名前の Organization を再び利用したくなる可能性は 0 ではないので確保しておきたい。
OWNER/REPOSITORY-NAMEの組み合わせが再利用できるケースで、悪意ある第三者に同名の組み合わせを作成された場合に、Repository URL などを書き換えていない社内ユーザーやシステムがリスクを受ける可能性がある。
ただ、Team Plan のままだと Organization に残している数人分の Seats コストが発生してしまうため、Free Plan へダウングレードを実施し完了としました。
Organization 統合中の課題
Private Forks
統合作業を進めていく中で Transfer を実施するとエラーとなる Repository が存在しました。
そちらは Private Repository からフォークされた Repository であり、
Single repositories forked from a private upstream network cannot be transferred.
と、公式ドキュメントにもあるように、Private Repository からフォークされた Repository は Transfer できません。
すっかり見落としておりました。公式のドキュメントはしっかり読むべきですね。
こちらは Fork を解除することで Transfer できるようになりますが、Fork もとに解除してもらう必要があります。
今回は統合先の Organization に Repository を新たに作成し、Clone した上で新たに Push を行い、移行を完了させました。
既に使われていない Repository でしたし、Issue など特に他に移管しなければならない資産もほぼ無かったので楽な手法を選択した感じです。
New Repositories
統合期間の後半で、移行元の Organization に見慣れない Repository が見つかりました。
Repository の作成者に確認してみると、統合の案内を見落としていたことで、移行元の Organization で Repository 作成を行ってしまっていたようでした。
まだ、Repository を作成しただけの時点だったため、統合先の Organization で Repository を作成しなおしてもらい、そちらで作業を進めていただくことで解決しました。
弊社ではコミュニケーションツールで Slack を利用していますが、Slack で案内を出しても見落としてしまう人が出てくる可能性もあるため、周知の方法はチームリーダー経由でメンバーにも周知していただくなど、改善の余地があったと反省しています。
おわりに
今回の統合作業では特段大きな問題も発生せず完了できたのは良かったと思っています。
組織をまたいだツールの統合には多くの配慮が必要ですが、その経験から得られた知見は他プロジェクトにも活かせるものと感じています。
今後もこうした取り組みを積極的に発信していきたいと思います。
最後までお読みいただき、ありがとうございました 🐙