日本の知人からJenkinsの使い方について相談したいというありがたいお話を頂いたので、具体的な話をはじめる前に自分が考えている総論についてまとめておきます。
なお私のJenkins歴は長くないですしコミュニティに対する貢献も残念ながら皆無です。ガキ大将が戦略論を語っているようなものだと思って気軽に読み流してください。
はじめる前に
ゴール設定をしましょう。
Jenkinsは使い始めるのは簡単ですが、使用によって一定の効果を得るには意思が必要です。実際「1日になんどもビルドする」ことによる恩恵ってパッと思いつかない方が多いのでは？その状況で使い始めてもフェードアウトして終わりです。
「テストをすべてグリーンにする」「カバレッジを各メンバーが頻繁に確認できる状況を作る」「コンパイルエラーなコードをコミットする輩を血祭りにあげる」など何でもいいので決めて、チームで合意を得ておきましょう。
メンバーとのコミュニケーションコストを覚悟する
Jenkinsに限った話ではないですが、新しい取り組みをチームに定着させるにはメンバーの理解が必要不可欠です。新人を含むチームはもちろん、例えメンバーの技術力が総じて高くても、CI・品質・開発プロセスに対する思いが違えばすれ違いは生まれます。
効果を検証する
ビルドが壊れたときにメールを投げれば気づいて対応するだろう……と思っていたら迷惑メール扱いされていた、という経験はJenkins管理者ならば必ず通る道です。面倒でも検証しましょう。できれば効果があるとわかった時点で自動化・テンプレ化を行い、次に楽できるようにしたいものです。
自動化について
Jenkinsによって自動化できることは非常に多彩です。コンパイル、テストによるエンバグ確認、カバレッジ算出とレポート作成、JavaScriptの結合と圧縮、Seleniumによるインテグレーションテストなどはすぐにできます。チーム開発ではCheckstyleやPMDによるコーディングルールの確認も有効です。
この辺はJenkinsがスゴい部分とビルドツール（Mavenなど）がスゴい部分があり、最終的には両方を学ぶ必要があります。
プラグインに迷ったら（Java開発編）
Naginator PluginとGroovy Postbuild Pluginはお世話になる機会が多いのではと思いますが、迷うくらいなら入れないでOKです。必要になったら入れましょう。
マシンリソースを期待できる場合
SonarをインストールしてSonarプラグインを入れましょう。コード解析結果をこれでもかと出してくれます。正直最初は出てきた情報の10分の1も活用できないと思いますが、それで問題ありません。というか解析結果を100％活用するのはいろいろ無駄なことが多いです。
導入当初はカバレッジと警告だけ注視すればOKです。警告はPMD・Findbugs・Checkstyleの3種がデフォルトで入っていますので、開発チームの現状にあわせて使うものを選んでください。デフォルトで不足する場合はルールを自作することも可能です。自分はSLF4Jのルールセットを作って使っています。
- GitHub - KengoTODA/ruleset-for-SLF4J: Deprecated - use findbugs-slf4j instead.
- http://pmd.sourceforge.net/howtowritearule.html
リファクタリングすべき箇所をあぶり出すときはLCOM4とパッケージ依存関係の循環も使えます。もちろん自分の直感を信じていいですが、大量のコードから問題箇所を浮き上がらせるには頼れる手法です。
そのうち困るであろうこと
Jenkinsが帰らぬ人に
手法は問わないのでバックアップを取りましょう。専用プラグインもあります。
ビルドキューが満杯
Jobが増えるとこうなります。スケールアップかスケールアウトどちらかを選択することになるでしょう。
ビルドがなかなか終わらない
テストが増えるとそうなります。ディスクアクセスが問題ならRAMディスクなどで緩和できますが、最終的には分割実行の必要が出てきます。「頻繁に実行すべきテスト」と「夜間に実行すれば充分なテスト」に分割するのも有効です。
