はじめに
第6回テックヒルズ『Let’ study Jenkins～さまざまなケーススタディ』のレポートを公開します。
今回のレポートの注意点。
スライド資料に無い説明を中心にまとめているため、発表によってはレポートが物足りないと思います。ぜひスライド資料を併せてご覧ください。
【参考】としている個所は私が挿入しています（補足や参考資料など）。発表者の意図したものではありませんので、その旨ご了承ください。
AimingにおけるJenkins活用事例
分割に便利なもの(1):ラベル付け
カテゴリ単位で分けても、カテゴリ毎の実行時間は均等にならない。
これをなるべく均等にするため、ラベルを活用した。
ノードの設定画面でラベルを設定し、ジョブの設定画面でラベル式を指定することで実行の振り分けを行った。
分割に便利なもの(2):Join Plugin
このプラグインを入れるとJoin Triggerというオプションが使える。
【参考】
Join Pluginの設定事例が掲載されています。また、Build Pipeline Pluginとも組み合わせています。
日々是精進。: Join Pluginを試す＆Build pipline Pluginで表示してみる
Gerrit
GerritはGitにレビューシステムを追加する。
GitとJenkinsの組み合わせにGerrit Trigger Pluginを使った。
Gerritレビューの流れ
スライドの黄色の円はレビュー依頼のイメージ。
レビュー依頼を提出した全ての変更を対象にテストが行われるため、
・既に追加修正されている変更までテスト対象になる
・レビュー提出が相次ぐとテストが間に合わない
その結果として、
・Jenkinsの完了を待たずにマージ
・テストが壊れる
といった状態に陥った。
この状況を解消するため、無駄なテスト実行を減らすことにした。
Jenkinsのジョブを中断
Jenkinsのテスト中断（灰色マーク）をexitコードで表現できるか調べたが、存在しなかった。
そこで、Webコンソールでの動作と同様に、所定のURLにgetリクエストすることで実現した。
sleepを入れているのは止めるのに時間がかかるため。
検索基盤開発のための結合テスト環境の自動化
①背景
ソフトウェア開発において、コンポーネントの結合が最大の難しさ。
コンポーネント間の相互作用は仮説を立てるしかない。
仮説でよくあるのがバグがないという仮説。
MySQLのような成熟したコンポーネントはともかく、まだ成熟していないコンポーネントではこの仮説は当てはまらない。
Martin Fowlerの提唱する"Continuous Integration"での自動テストは単体テスト相当。
【参考】
Martin Fowlerの"Continuous Integration"
Continuous Integration
楽天はCI(Continuous Integration)のライフサイクルに結合テストも含めた。
検索精度の改善にも仮説を持って取り組んでいる。
自動化によりテスト実行のコストを下げることができる。
開発者の仮説の検証をテストで行う。
②課題
プレゼン資料にある『テストの基本に則り品質を積み上げる』とは単体テスト等をおろそかにしない、ということ。
結合テストのフレームワークがない。
そこでNgautoという独自のフレームワークを作った。
JSON形式でテストを記述できる。そのため保守しやすい。
全てのテストをシーケンスに実行すると15時間ぐらいかかってしまう。
そのため、Smoke Testをパスしたもののみ、結合テストを実行する。
結合テストは大体一晩で終わるようにしている。
Smoke Testは最初単純なものだったが、その後はバグの傾向を見ながら調整している。
ただ、開発者が気軽に実行できるよう、時間が長くならないように気をつけている。
連続したテスト実行のためのシステムの状態差異とは：
・ゾンビプロセスが次のテストに影響してしまう
・異常テストのおかしなプロセスが残る
これらの解決方法として、クリーンアップ＆インストールをお勧めする。
時間はかかるが影響を抑えることができるため。
④効果
開発初期から結合バグが見つかり、明確な結合期間を設ける必要がなくなった。
自動化することで、サービスの高付加価値なテストをQA期間に実施できる。
Smoke Testは実行時間比で非常に効率良くバグを見つける。
CROOZにおけるJenkins活用事例
CROOZにおけるJENKINS活用事例
リポジトリサーバにコードと規約の設定ファイルを格納している。
エラーメッセージは日本語にしている。
Jenkinsでは潜在バグ（ネストが深いとか行数が大きすぎるとか）をチェックしている。
除外ファイルの更新漏れをJenkinsで差分通知をするようにした。
夜に実行され翌朝には確認できる。
毎回の差分通知もやってみたが、きつかったのでやめた。
同じようなことはリモートシェルでもできるが、管理のしやすさからJenkinsを選んだ。
導入効果
除外ファイルの更新漏れは体感で1/5以下になった。
僕とJenkinsおじさんの360日戦争
リリース時間を境にマスターブランチからリリースブランチに切り出す。
TAP(Test Anything Protocol)はシンプルゆえに他言語でも対応しやすい。
並列実行で共通のDBを参照していると不整合が発生する。
これを防ぐためにFixtureという仕組みを用意している。
⇒テスト毎に同一データから別DBを作成して、それを参照する。
テスト実行の高速化にリソースは有効だけど、Fixtureも効果はあるので今後調査したい。
remote test:
個人の開発環境でフルテストを実行するのは負荷が重すぎるので、
Jenkinsのノードを利用する。
アメーバピグとJenkinsと私
Case 1:コードの品質管理 -バグの発生を抑える-
面倒事を倒すため、ある程度は強制力を働かす。
強制力=リーダーからお達しを出してもらうなど。
Case 2:バッチ制御 -責務の分離・可視化-
Remote APIを使ってJenkins自体の監視を行っている。
キューイングをチェックすることで、動くべきバッチがキューに溜まって動けていない状況を避ける。
Case 3:オペレーションの自動化 -同じ過ちは繰り返さない-
チェックリストのチェックリスト問題:
チェックリストでチェックしたかをチェックするリスト。
金曜はタグ切りの日だが公休を忘れることも。。
そのリマインダとしてJenkinsを使っている。
リンク集
主催のクルーズ株式会社によるレポートです。
http://crooz.co.jp/archives/13397
http://crooz.co.jp/archives/13511
書籍
Jenkins実践入門 ～ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)
- 作者: 佐藤聖規,和田貴久,河村雅人,米沢弘樹,山岸啓,川口耕介
- 出版社/メーカー: 技術評論社
- 発売日: 2011/11/11
- メディア: 単行本（ソフトカバー）
- 購入: 26人 クリック: 496回
- この商品を含むブログ (64件) を見る
- 作者: John Ferguson Smart,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/02/22
- メディア: 大型本
- 購入: 12人 クリック: 345回
- この商品を含むブログ (38件) を見る
- 作者: 末広尚義,竹内一成,太田健一郎,西川茂伸
- 出版社/メーカー: 秀和システム
- 発売日: 2012/09/24
- メディア: 単行本
- 購入: 5人 クリック: 138回
- この商品を含むブログ (9件) を見る
