はじめに
ビットキーでデバイスの開発プラットフォームの開発・運用を担当している、びやあきと申します。
Go Conference 2023（以下：gocon）関わったみなさん、お疲れ様でした。自社のブースで待機してましたが、今回の会場はどこからでもセッションが拝見できて退屈せずに過ごせました。
goconにてビンGoのクイズと解答を作成しましたが、その解説について開示する場がなかったため本記事にて後述します
開発環境周りの仕組みを説明する機会もないので、内部向けの紹介も兼ねています。
前提
ビンGoとは・・・
gocon参加者が事前に配布されたビンゴカードの各マスに記載の問題を解くゲーム
この問題は事前にgocon運営やスポンサーから集められている
ビットキーが用意したクイズとその解答
クイズ
- ビットキーにおけるGoの開発環境で、実現できていないことは次のうちどれでしょうか？
選択肢
- コンテナのホットリロード
- モノレポの import 間違いチェック
- コード自動生成の実行漏れチェック
- 複雑度の低いプルリクエストを作成した時にCIが褒めてくれる仕組み
解答
- 複雑度の低いプルリクエストを作成した時にCIが褒めてくれる仕組み
選択肢および解答の解説
️複雑度の低いプルリクエストを作成した時にCIが褒めてくれる仕組み
こちらが正解で、まだ実現できていません。
ただし、「行数が少ないプルリクエストを作成した時にCIが褒めてくれる仕組み」はあります。
Dangerを使って200行以下のPRにLGTMするようにしています。
# lgtm there is a small PR
lgtm.check_lgtm image_url: lgtm_gifs.sample if git.lines_of_code < 200
将来的にはcognitive complexity（以下：認知的複雑度）が10以下のような条件に変更してみたいと思っていて、認知的複雑度の静的解析ツールも作ってくれてたりするので、どこかで組み込みたいなと思っています。
以降はすでに実現済みの仕組みの紹介です
コンテナのホットリロード
ローカル開発ではDocker Compose, リモートの開発環境はk8sを利用しています。
ローカル開発の際には、手元のソースコードを変更するたびにコンテナをビルドしてスタートする手間があり、ホットリロードがないとつらいということで、創業初期くらいから整備されていました。
hmarui66/go-watchを利用しています。
以下のようなスクリプトを用意して、DockerfileのENTRYPOINTに指定して動かしています。
#!/bin/bash
cd $(dirname $0)
go install github.com/hmarui66/go-watch@latest
go-watch
go-watchは起動すると、ファイルシステムのイベントを監視して、変更があればgo buildし、ビルド生成物を実行してくれます。
モノレポの import 間違いチェック
ビットキーのバックエンドはいくつかのマイクロサービスをモノレポ運用にして開発しています。
モノレポで開発していると、サービス内のパッケージの名前が被ることがあり、IDEのインテリセンスがサービスAからサービスBのimportを提案してきたりして、よく注意していないと間違えてしまうことがあります。
こういった間違いは、PRレビューでも見逃されることがあるため、静的解析で対応しています。
GitHub Actionsでworkflowに以下のように書いて実行しています。
- name: Install linter
run: go install github.com/nrnrk/banimport/cmd/banimport@latest
- name: Import check
run: go vet -vettool=$(which banimport) -banimport.config="$(cat .banimport.json)" ./...
コード自動生成の実行漏れチェック
APIルーターの実装をOpenAPIの定義ファイルから自動生成していたり、mockやprotobufの自動生成をしていたり、自動生成されたコードというのはちょこちょこ入っているのですが、PRを出すときに自動生成分をコミット漏れすることがよくあります。
これもCIで自動チェックしていて、以下のようにGitHub Actionsに書いています。
- name: Generate files
id: generate-files
run: |
./gen.sh
- name: Detect unpushed changed
id: detect-unpushed
run: |
if [[ $(git status --short | wc -l) -gt 0 ]]; then git status; exit 1 ; fi
まとめ
以上、ビンGoの解答でした。
こういう内容は、「リポジトリのここ読むとわかるよ」って教えることがほとんどで、整理して文書化しておくことが少なかったので、良い資料になったような気がします。
上記の方法、「こっちのほうがいいですよ！」「このLinterでできますよ！」などあれば、ぜひコメントください。
備考
ビットキーのGo開発者（@_otakakot_）も、イベント参加者としてレポートを書いてくれているので、ぜひ読んでみてください。