こんにちは。インターンの id:sksat です。 衛星SW/HWの試験用シミュレータの開発や、今回紹介するような働きやすい環境の整備に取り組んでいます。
今回は、 前回の投稿 で少し触れたGitHubへの移行関連の裏話をしようと思います。
GitHub移行
元々、アークエッジ・スペースではGitLabが使われていました。 これは創業メンバーの出身研究室のソフトウェア開発でGitLabを使用していたところからの、 そのまま延長線上にあったからです。
とはいえ、GitLabのアカウントは社員全員に発行されており、誰でもGitLabにアクセスすることができました。 なんなら入社して最初のオンボーディングはIssueで管理されていました。 ソフトウェア開発をする人間はそれほど多くないのにも関わらず、です。
このような雰囲気はとてもよいものですが、GitLabはGitHubと比べると動作が遅く、
気軽にIssueを立てようという気力がじわじわと削がれていきます。
また、CI/CDを推し進めていこうと思っても、GitLab CIという仕組みは存在こそするものの、GitHub Actionsと比べるとあまりに素朴です。
その中で苦労してCIパイプラインを組んだところで、後に訪れるのは肥大化した .gitlab-ci.yml のメンテに追われる日々でしょう。
ということで、GitHubに移行したいという声が上がり、比較的すぐ移行が決まりました。
そんなことで決まったGitHub移行、一見とてつもない大事業のように思えます。 ですが、
- GitLabとはいっても gitlab.com だった(謎の環境でセルフホスティングされていない！)
- GitLabを使っていたのはあくまで歴史的経緯であり、特有の機能にあまり依存していない
- マネジメント側の意思決定の素早さ、柔軟さ(移行決定まで５日、使い始めるまで２週間！)
- 会社の規模が小さく、まだそこまでリポジトリ数が多くない(数十個程度)
といった状況により、移行における本質である、既に存在する資産と人間の移行にだけ集中することができ、迅速に移行を実施できました。 実際の作業の大部分は僕１人が行っていましたが、最終的に移行は３ヶ月かからずに完了しています。
準備
移行するとなったら、まずは準備です。弊社には「GitHubって何？」という人も多かったので、これは結構大事です。 とはいっても、できることは限られています。Slackで案内を流し、社内WikiにGitHubの使い方の記事を書くぐらいです。
そして、project-templateというテンプレートリポジトリを作りました。
ここには基本的に入っていてほしいリポジトリの設定などが詰まっています。
Issue templateやラベルを管理するGitHub Actions workflowなどですね。
これで新規リポジトリを簡単に作ることができるようになりました。
あとは慣れてもらうしかありません。でも、慣れてもらうための手伝いは惜しみません。 移行が終わった今でも、SlackでちょっとでもGitHubで困っていそうなことがあるとサポートに駆けつけるようにしています。 Slack huddleは便利。
移行作業
準備ができたら、あとはひたすら移行作業です。 とはいっても、一気にすべてのリポジトリを移行することはできません。 これはリポジトリの数がそこそこある上に、活発とはいえないにしてもIssue上でのコミュニケーションなどは常に発生していたからです。 やろうと思えば休日に一気に移行することもできたかもしれませんが、それでは人間の方がついてこられません。
また、ひとつだけ技術的な問題がありました。それはリポジトリの名前です。 GitHubを含む他の多くのGitホスティングサービスとは異なり、GitLabではリポジトリ名に日本語を使うことができます。 そして、実際ほぼすべてのリポジトリ名が日本語で命名されていました。
さらに、GitLabにはsubgroupという機能があります。 organizationの下にさらに小さなorganizationのようなものを作ることができるというものです。 これはとても便利で、部署ごと・プロジェクトごとに階層を切ることができます。
いざGitHubに移行するとなると、これは大きな障害となります。 移行先のリポジトリ名が一意に定まらないため、こちら側で勝手に移行しておきましたよ、ということができないわけです。 なんとなくの命名規則の提案はできますが、最終的な個々の命名はそのリポジトリのオーナーに決めてもらうべきでしょう。
そこで、実際の移行作業は以下のような形になりました。
移行のタイミングは週末に少しずつ、そして、リポジトリの命名とGitHubの練習を兼ねてリポジトリ作成まではリポジトリのオーナーにやってもらうことにしたわけです。 これにより、余計なコミュニケーションを発生させることなく、僕のやることは毎週の移行募集の呼びかけとIssueの移行作業だけとなりました。
Issueの移行
毎週末のIssueの移行には node-gitlab-2-github というスクリプトを使いました。 このスクリプトはIssue・Issue commentだけでなくlabelやmilestoneの移行もできる上、GitLabとGitHubのユーザ名の対応を設定に書いておけばassigneeの移行も行うことができます。
ただ、大量のIssueを移行するとsecondary API rate limitで弾かれてしまうことが分かったので、 Issueを作ってから次のIssueを作るまでのディレイを2000msから5000msに変更するパッチを当てて使いました。 移行さえできればよいのでちゃんとした確認を行ったわけではないですが、これで問題無く移行作業を行うことができました。
また、特に移行する必要の無いGitLab上でのイベント(changed the descriptionなど)がすべてIssue Commentになってしまうのは煩雑だったため、
こうした一部のイベントをスキップするパッチも当てました。
少々面倒だったのがGitLab/GitHubのトークンの用意です。 GitHub側のトークンにPersonal Access Tokenを使ってしまうと、トークンの管理が面倒なだけでなく、過去のあらゆる発言を僕のアカウントからやり直す形になってしまい非常に分かりにくいです。 そのため、専用のGitHub Appを作り、そこからトークンを生成して使用しました。
一方で、GitLab側のトークンは毎回各リポジトリでトークンを生成しなければいけませんでした。 そして、当初僕はトークンを生やす権限を持っていなかったため、毎週末僕が移行準備を整えてトークンの発行を要求して......ということになっていました。 これはあまりに煩雑だったため、途中から僕のGitLabの権限レベルを上げてもらうことになりました。
hubhook
リポジトリが増えてくると、日々どんなIssue/PRが生え、どのようなコメントが付いたのかを把握するのも一苦労です。 GitLabから移行したリポジトリ数は50個ほどでしたが、今はもうGitHub上のリポジトリ数は100個を越えています。 もちろんまだまだ人数の少ない会社なので、実際にその時その時で動きのあるリポジトリの数はそれほど多くはありません。 ですが、この調子でリポジトリと人数が増えていけばそうもいかないでしょう。 既に通知の量はSNSの通知地獄とGitHubに慣れていないと GitHub notifications だけでは処理しきれないものでしょう。
そんな時によくやるのが、webhookを使って通知を何かしらのチャットツールに流すことだと思います。
実際、弊社でも元々GitLabのwebhookを多用しており、Slackには #n_gitlab_hoge といったチャンネルがたくさん存在していました。*1
こうすることで、通知の文脈を区切った上で、「いつ・誰が何をしていたか」というタイムラインを作ることができます。
GitHubなら、Slackの GitHub App を使ってスラッシュコマンドで比較的簡単に通知を流すことができます。
しかし、リポジトリが増える度にGitHub・Slackをポチポチしてwebhookの設定をするのは非常に面倒です。*2 また、個々のチャンネルで通知が氾濫してしまうと、結局通知を見なくなってしまい、意味がありません。多すぎる通知は身を滅ぼします。
そして、あるリポジトリのすべてのIssueを通知してほしいとも限らないでしょう。 例えば、ある衛星プロジェクトのタスク管理のためのリポジトリがあった時に、 電源系のエンジニアがフライトソフトウェアに関する雑多なタスクについて確認したいでしょうか？ これは逆も然りです。GitHubを直接開いて「やってるな〜」と思うくらいはしたいかもしれません。*3 とはいえ、わざわざSlackから通知されたいとは思わないでしょう。
そこで、自分が見たい通知のみをSlackに流すためのhubhookというソフトウェアをRustで開発しました。 この記事の投稿に合わせてOSSとして公開したのでよかったら見てみてください。
これはCookpadさんのtokiteというソフトウェアからインスパイアされたものです。
https://github.com/cookpad/tokite
インスパイアと書いたものの、やりたいことはtokiteとほぼ同じです。 だったらtokiteをそのまま動かせばいいじゃないかという気もします。 ですが、実装言語であるRubyが得意な人間が社内に多いわけではないですし、 後述するように、もっとシンプルな実装ができるなということにも気付きました。 そのため、不慣れなRubyのコードベースをメンテしていくよりは書き直してしまった方がいいだろうという判断をしました。
hubhookの実装
hubhookの構成は非常にシンプルで、GitHub Appと本体のWebサーバからなります。 Webサーバ部分の実装のためのWebフレームワークにはactix-webを使用しました。 このWebサーバは 前回の投稿 で触れられていたKubernetesクラスタ上にデプロイされています。 簡単にデプロイできる環境があるとこういうツールをさっと作ってすぐデプロイできるので便利ですね。
GitHub Appではorganization内のあらゆるイベントを吸い上げてwebhookをトリガーするように設定してあります。 後は本体のWebサーバがwebhook payloadを受け取り、設定されたルールに従ってSlackの適切なチャンネルに通知を配送する、というわけです。
問題は各個人の設定の設定方法です。それこそtokiteでは設定画面を提供するWebアプリとしての側面が大きい実装になっていました。 しかし、よく考えてみると、我々の本当の要求は「GitHubの通知がいいかんじにSlackチャンネルに配送されてほしい」ということであって、 「そのための設定をポチポチするためのWebアプリ」ではありません。 また、各々の設定がリアルタイムに激しく変更されるわけでもないので、設定をDBに貯めておく必要もそこまでありません。
そこで、hubhookでは各々の設定をファイルに書くようにして、この設定ファイルをGitHubで管理してしまうことにしました。 実際の運用では、先述のKubernetesクラスタ用の設定が詰まったリポジトリ内に設定ファイルをcommitしてしまい、 コンテナにvolume mountする、という形になっています。 こうすることで、実装が非常にシンプルになるだけでなく、他の人の設定を真似して自分の設定を組むことができるようになりました。 また、この設定ファイルの編集もPull Requestベースで各自にやってもらうことで、社員のGitHubの練習の場の一つにもなっています。
hubhookの現状と今後
hubhookの今のところ一番多い使われ方は「呼ばれた！」で、 自分が呼ばれそうなIDや名前をクエリに入れておいて自分の分報に流す、というものです。
それくらいならちゃんとメンションするようにした上で GitHub notificationsの reason:mention を見ればよいのでは？と思ってしまいがちですが、 起きたらまずGitHub notifications(とTwitter)を開く、というような人間でもなければそうもいかないんですよね。 GitHub notificationsだとただの一覧になってしまうので、数が増えてくるとタイムライン状になっていた方が見やすい、というのもあります。
また、GitLab subgroupの代替としてリポジトリに設定できるtopicsで部署・チームを判別するようにしているのですが、 これもhubhookのクエリとして設定することができます。 そのため、自分が所属するチームのIssue commentを全部流す、というようなこともできます。 個人的にはこれを一番使っています。
もう少し使う人が増えてきたら要望を整理してこなれさせていきたいですね。
最近のGitHub体験
GitHubに移行したことで、働きやすさが格段に向上したように思います。 軽快な動作は気楽にIssueを立てる助けになりますし、個人的にはGitHub Actionsが大好きなので、 自動化できるな、と思ったら即座にworkflowを生やしにいくことができるのはとても体験がよいです。
また、hubhookとSlackのGitHub Appを併用しながら、ほとんどのGitHubのコメント通知をどこかしらのSlackチャンネルに流すようにしています。 これにより、Slackのスレッドで長大な議論を展開していたようなものをGitHubに誘導することができます。 もちろんSlackのスレッドで議論をするなとは言いませんが、 GitHubにIssueとして貯まっている方が後からの参照のしやすさが段違いですからね。 移行時の積極的な案内などの甲斐もあり、ソフトウェアエンジニア以外の社員のGitHubの活用は着実に増えてきていますし、 hubhookも少しずつ使われるようになってきました。
GitHub Projects (beta) が出てきたタイミングも非常によかったと思います。 もうbetaではないProjectsを使いたくないなと思う程には便利です。 GitHub Actionsなどもそうですが、こういった便利な機能が高速にリリースされていくのはGitHubの魅力的な点の一つです。
今後もGitHubをさらに活用していきつつ、色々な不便を自動化して生産性を上げていきたいですね。
アークエッジ・スペースでは、働きやすい会社をソフトウェアの力で作っていきたい仲間を募集しています。
