3つのGitHub Orgを1つに統合した話

Satoshi Tajima
Mar 5, 2020 · 8 min read

はじめに

こんにちは。Finatextでエンジニアをしている @s_tajima です。
今回は弊社で利用しているGitHubの3つのOrganizationを1つに統合した話です。

現在働いている環境で複数のGitHub Organizationがあって困っている方の参考になればいいなと思っています。

Organizationが複数あることの問題

さまざまな経緯により、Finatextグループには複数のGitHub Organizationの契約がありました。
具体的には、グループの子会社の単位で以下の3つがありました。

※数字は移行開始時点のものです。

複数のOrganizationを利用していることで、以下のような問題が起きていました。

他のOrganizationのソースコードを参照することができない

例えばNowcastのメンバーがFinatextのWebサーバーのソースコードを見たり、FinatextのメンバーがNowcastの機械学習のソースコードを見たりすることができない状態でした。
ソースコードを気軽に閲覧しあえる状況を作り、組織としてノウハウの共有をすることはとても重要ですが、そこにハードルがある状況でした。

重複した料金が発生する

前述のようにソースコードが閲覧できない状態だと業務上支障がある場合は、その人は当然複数のOrganizationに所属することになります。
これにより、Organizationが1つであれば発生しなかったコストが発生します。(このコストが心理的障壁になり、他のOrganizationに所属するのを躊躇するという例も見られました。)

設定の管理に手間がかかる

GitHub Organizationにおける、様々な設定(Two-factor authenticationの強制・Base permissionsの設定・Teams・GitHub Apps等)を、それぞれ個別に管理する必要がでてきます。1つ1つはそれほど大きな手間ではないのですが、毎回同じ設定を3箇所でやらなければいけないのは地味に面倒でした。

Organizationの統合

前述のような問題は、現時点では目を瞑れる程度のものかもしれませんが、組織が成長し、社員やリポジトリの数が増えれば増えるほど大きな問題となり、また対応も難しくなっていくのでこのタイミングで対処することにしました。
具体的には、Finatext Organizationに統合するという方針としました。

どのような順序でどのような事をしたかを書いていきます。

1. 権限の整理

「ソースコードを気軽に閲覧しあえる状況を作り、組織としてノウハウの共有をすることはとても重要」という根底の考え方はありつつも、「未公表の案件の開発を行っているリポジトリがある」「子会社単位での契約をしている業務委託の方もOrganizationに参加している」という状況から全員がすべてのリポジトリを閲覧できるという状況は避ける必要があり、最初に権限の整理を行いました。

具体的には

というのを行いました。

2. Finatext Org以外での新規リポジトリの作成禁止

Restricting repository creation in your organization の手順に従い、Finatext Org以外では新規のリポジトリを作成できないようにしました。これによって、いつまでたっても移行対象が減らないという自体を防ぎました。

個人的には、このステップが肝だと思っています。
この手の長期間かかる移行作業は、進捗がマイナス(今回でいうと移譲対象のリポジトリが増えてしまう事態)にならない状態を作るための工夫がとても大事です。

尚、当然いざとなればOwner権限でFinatext Org以外へのリポジトリ作成は可能な状態ではあります。

3. 既存リポジトリの移行

Organization統合の一番大変な部分です。
具体的な手順としては、 Transferring a repository に記載された方法でリポジトリを移譲していきます。

今回は、フェーズを大きく3つに分けて移行を行いました。

フェーズ1

このフェーズでは、以下の状態のリポジトリを対象に移譲を行いました。

  • アクティブに開発が行われていない

なぜ Goで書かれていない が選定基準に入っているかというと、Goのimport文には、リポジトリのOrgも含んだロケーションが記載されるためです。
まずは無難に進めるために、Goのリポジトリを除外することにしました。

このフェーズで移行したリポジトリはおそらく100リポジトリほどです。
開発への影響がほぼないリポジトリを選定しているので、僕一人の作業でがしがしと進めていけます。
どうせ一度だけの作業だということで、最初はGitHubのWebページで手でポチポチとやっていたのですが、さすがにリポジトリ数が多く大変だったので簡単なCLIツールを書きました。

フェーズ2

このフェーズでは、フェーズ1で対象にできなかったリポジトリを対象にしました。
フェーズ1と違い、移行時にGoのimport文を修正したり、CIの設定を切替えたり等の手直しをしながら進める必要がありました。

Goのimport文の修正や、CIの設定等、スクリプトを書いて自動的に進めることもできなくはないと思うのですが、予期せぬ不具合を警戒し、基本的には手作業で進めていました。

僕一人だけでなく、他のエンジニアの協力も得ながら進めていたのですが、この方法だとリポジトリを更新したいタイミングくらいしか移譲をしないので、結果として数リポジトリ分しか進みませんでした。そんな経緯もあり、フェーズ3が登場します。

フェーズ3

ある日付を決めて、フェーズ1, フェーズ2で移譲できなかったリポジトリを一斉に移譲しました。
一斉移譲を行う日を、Zatta Task Day と呼んで、同質の雑務系タスクを一気に片付けるというやり方をしました。(この日は、僕自身は別の作業を行い、リポジトリの移譲は他のメンバーにおまかせしました。)

この日に移譲したリポジトリについては、以下のような方針をとりました。

  • CIについては新しいOrganizationでも元のとおりにうごくようにする

このやり方をしたおかげで、この日に全てのリポジトリを移譲することができました。

4. 旧Organizationからユーザーの削除

これをやらないといつまでもコストがかかり続けてしまうので忘れずにやります。

Organizationの統合をやってみて

現時点では、大きなトラブルもなく開発は進んでいます。
GoのimportのPathの修正も、他の修正のついでに滞りなくやれているようです。

今回の取り組みで、(現時点でのメンバー数で計算すると)概算としては年間75万円ほどのコストを浮かすことができている状態になりました。
冒頭にも書いたとおり、組織の規模に比例して大きくなるこの問題に、このタイミングで対処ができてよかったなと思っています。

最後に

Finatextグループでは、一緒に働くエンジニアを募集しています。
全く新しい金融ビジネスプラットフォームを創造することに興味がある方、ぜひご連絡ください!

求人一覧はこちら

社員インタビューはこちら

Finatext

THE Finatext Tech Blog

Finatext

THE Finatext Tech Blog

Satoshi Tajima

Written by

Finatext

THE Finatext Tech Blog