CI/CDとHuskyの役割分担

ESLintのruleを充実させたエントリでも書いた通り、弊社の開発チームではレビュアーがボトルネックとなり、開発スピードが上がらない場面がよくあります。 そこで、レビューコストをできるだけ下げ、レビュアーがボトルネックにならないようにする取り組みを行っています。

レビューコストを下げるために、自動的にチェックできることはなるべく機械に任せ、レビュアーが本質的なレビューに集中できる環境を整えています。現在はCI/CDとHuskyを導入しており、どのチェックをどこで行うべきかを明確にしました。

Huskyとは

Huskyは、Gitのフック機能を活用してコード品質を保証するためのツールです。Gitのフックとは、Gitコマンドが実行される際に自動的に実行されるスクリプトのことを指します。Huskyを使うことで、コミット前にテストを実行したり、コミットメッセージのフォーマットを確認したりすることが可能になります。

現在行なっているチェック

Next.jsを使っているプロジェクトを例にすると、自動的にチェックできることとして、現在は ・ESLint ・Prettier ・CSpell ・tsc ・next build を走らせています。（その他にもテストやデプロイのCI/CDも走っていますが、こちらは今回の議論の対象ではないので省きます。）

ESLint, Prettier, CSpellでコードの品質を担保し、tscとnext buildでコードの動作を担保しています。 この5つをHuskyとCI/CDのどちらでやるべきかを整理しました。

どのチェックをどこでやるべきか

上記の5つはすべてCI/CDで実行してもよいのですが、Huskyも併用している理由は、commitをきれいに保ちたいのと、CI/CDが実行されるのを待つ時間を減らしたいからです。

Huskyの目的はcommitをきれいに保つことであり、コードの品質は担保したいですが、コードの動作をチェックするためではないです。コーディング規約に沿っていないコードはcommitしたくありませんが、動かないコードはcommitできてもよいと考えました。

そこで、結論としては、Huskyでは ・ESLint ・Prettier ・CSpell をチェックし、CI/CD側で ・tsc ・next build をチェックしようということに決まりました。

Git-flowを採用しているため、mainブランチやdevelopブランチは常に動くコードにしておきますが、作業ブランチは動かないコードでもよいと思いました。 コードの動作はpull requestをマージするタイミングで保証されていればよいため、tscやnext buildはCI/CDで実行し、Huskyの範囲ではないという棲み分けになりました。

さいごに

これまでなんとなくで設定していたCI/CDやHuskyですが、今回明確に役割分担を決められました。 今後もレビューコストを下げる仕組みを導入する際はこちらの基準に沿って考えていければと思います。