この記事はGMOペパボエンジニア Advent Calendar 2021の15日目の記事です。
昨日はToshifumi Tsutsumiさんの入社から一年、ペパボはどうですか？に答えるでした。
ペパボにいるとインプット、アウトプットが出来てる方々の集まりで本当に刺激的ですよね。…そして、評価資料がんばりましょう。
さて、今回、記事にするのは掲題の2つの「初めて」についてと、作成したGo製CLIツールの紹介です。
2つの「初めて」とは、1つ目はGo製CLIツールを自分で作成したこと、2つ目はそれをOSSとして公開したことです。
What is takolabel
まず、そのGo製CLIツールについて紹介します。
tnagatomi/takolabel
https://github.com/tnagatomi/takolabel
名前はtakolabelと言って、GitHubのマスコットであるOctocatがタコとネコの合体であることから（割と安易に）takoを、ラベルを操作するツールなのでlabelを取って、takolabelと名付けました。
後になって英語圏の人に伝わりにくいかもと少し後悔していたりもしますが、Kubernetesなんて名前のソフトウェアがあるぐらいなので良いかなと思ったりしています。
このツールが何をやってくれるか短く言うと、「複数のGitHubリポジトリに渡ってのラベル操作」です。
例えば、A、B、Cというリポジトリがあって、X、Y、Zというラベルをそれぞれのリポジトリに一括で作成したい、といった時にそれを実現してくれるというものです。YAMLにリポジトリとラベルを指定して操作します。GitHub Enterprise Serverにも対応しています。
ここでは、なぜそのようなツールが必要になったかについて説明します。
ツールが生まれたきっかけ
このツールが生まれたきっかけとしては、私が所属しているGMOペパボ ホスティング事業部 ISR (Internal System Reliability) チームにて、運用業務のコスト可視化というタスクがありました。
前提として、GMOペパボ ホスティング事業部では全パートナーが割り当てたタスクをGitHub Issues上で議論や過程を記録しながら進行させるのが基本になっています。そういうことから、コストを可視化するためにはIssue上で分類や消費時間を記録すれば計測できるのではないかとチームで話し合われました。
その結果、サービスや用途ごとに異なる複数のリポジトリにGitHub Issuesに計測用の分類、消費時間を表すラベルを貼った上で、Google Sheetsにエクスポート、それをさらにGoogle Data Studioに取り込みレポートを作成するという仕組みを実現しました（こちらについては別に改めて紹介できたらなと思っています）。
その過程の、GitHub Issuesにラベルを貼るという作業を手動で行うのは大変なので、それを自動化するために生まれたものです。
最終的には、思った通りにラベルを複数のリポジトリに一括で作成することができ、ツールとしての役目を無事果たすことができました。
Goについて
なぜこのツールにGoを選んだかということについては色々とありますが、ホスティング事業部として今後バックエンドを中心に採用していく言語であること、実行ファイルがシングルバイナリであることからCLIツールとして適していること、個人的に学んでみたい言語のリストに入っていたこと、が挙げられます。
結果として、ツールの作成を通じてDXとして非常に満足のいくものがありました。
まずは言語の売りである簡潔性がとにかく素晴らしいです。学習にかかる時間がかなり少なかったですし、覚えることが少ない分、コードも読みやすく仕上げることができます。
良く言及されるエラーハンドリングも個人的には何も苦ではない感じです。
IDEとの親和性も高く、ツールチェインについてもシンプルで、言語としての完成度の高さを嫌というほど実感しています。
そういうわけで、これから自分で書いていくプログラムで採用していくことも増えていくだろうなと思っています。CLIツール以外でも使ってみたいですね。
色んな言語を使ったり学んできて、使う言語にこだわりのない方なのですが、この言語については惚れてしまいました。
あとはGoルーチンを使った並行処理の強みについてはまだ活かせていないので、その辺りも勉強していきたいと思っています。
OSSとして
2つ目の初であるOSSとしてですが、こちらは主に2人の会社の先輩に助力をいただきました。
まずは、Fukuoka.go#17での発表でも触れましたが、CIフレンドリーなDBドキュメントツールであるtblsを代表プロダクトに持つk1lowに、環境変数の命名や設定ファイルの書き方といった点を中心に、様々なアドバイスをいただけました。このプロダクトを社内Slackで公開した時に、「え、めちゃいい！」と言っていただけたこと、非常に嬉しかったです。
次に、チームの先輩である、お手軽にTLS証明書の情報を引けるcertを作ったgenkiroidには設計のアドバイスをいただきました。現在のコードの状態を見て、自分ならこうするという例を提示していただき、責務の分離や構造体の定義、関数とメソッドの使い分けといったことを教えていただきました。仕事上でもいつも的確な意見をいただけていて、私の中でロールモデルな存在です。
お2人とも貴重なプライベートの時間を使ってプロダクトを見ていただいた上で助言をいただけて、最高の福利厚生だなと思っています。いや〜ほんとありがたいです。この場を借りてお礼させていただきます。
takolabelのこれから
そんなtakolabelですが、現在のところ必要ドリブンで、ラベルの作成、削除、空にする、という3つの操作ができるにとどまっています。これからも操作を拡張したり、使いやすくしたり、リファクタリングしていけたらと思っています。
もちろんPull Requestsもお待ちしております！
まとめ
この記事を通じて、1つの小さなプロダクトにも、物語があるのだということを感じ取っていただけたらなと思います。
そして、Goで書くことも、自身のOSSを持つことも、自分次第でなんとでもなることだと分かり、挑戦して良かったなと思っています。こうしてAdvent Calendarのネタにもなっていることですしね。
Who's next?
さて、明日のGMOペパボエンジニア Advent Calendar 2021の16日目の担当はAkihito Ikedaです。
彼はISUCON11でISUCONに初参加した時の盟友です。何を書いてくれるんでしょうね。楽しみです。
