ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

第6回テックヒルズ『Let’ study Jenkins~さまざまなケーススタディ』レポート

はじめに

第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を入れているのは止めるのに時間がかかるため。

AimingでのJenkinsの使い方紹介

結果の通知はSkypeやパトランプで行った。
みんなに迷惑がかかるというプレッシャーがあると解決が早くなる。

検索基盤開発のための結合テスト環境の自動化

①背景

ソフトウェア開発において、コンポーネントの結合が最大の難しさ。

コンポーネント間の相互作用は仮説を立てるしかない。

仮説でよくあるのがバグがないという仮説。
MySQLのような成熟したコンポーネントはともかく、まだ成熟していないコンポーネントではこの仮説は当てはまらない。

Martin Fowlerの提唱する"Continuous Integration"での自動テストは単体テスト相当。
【参考】
Martin Fowlerの"Continuous Integration"
Continuous Integration

楽天はCI(Continuous Integration)のライフサイクルに結合テストも含めた。

検索精度の改善にも仮説を持って取り組んでいる。

自動化によりテスト実行のコストを下げることができる。

開発者の仮説の検証をテストで行う。

②課題

プレゼン資料にある『テストの基本に則り品質を積み上げる』とは単体テスト等をおろそかにしない、ということ。

結合テストフレームワークがない。
そこでNgautoという独自のフレームワークを作った。
JSON形式でテストを記述できる。そのため保守しやすい。

全てのテストをシーケンスに実行すると15時間ぐらいかかってしまう。
そのため、Smoke Testをパスしたもののみ、結合テストを実行する。
結合テストは大体一晩で終わるようにしている。

Smoke Testは最初単純なものだったが、その後はバグの傾向を見ながら調整している。
ただ、開発者が気軽に実行できるよう、時間が長くならないように気をつけている。

連続したテスト実行のためのシステムの状態差異とは:
・ゾンビプロセスが次のテストに影響してしまう
・異常テストのおかしなプロセスが残る
これらの解決方法として、クリーンアップ&インストールをお勧めする。
時間はかかるが影響を抑えることができるため。

開発プロセス

システムテストは手動がメインだが、少しずつ自動化を進めている。

Smoke Testの成果としてversion.jsonを出力している。

④効果

開発初期から結合バグが見つかり、明確な結合期間を設ける必要がなくなった。

自動化することで、サービスの高付加価値なテストをQA期間に実施できる。

Smoke Testは実行時間比で非常に効率良くバグを見つける。

CROOZにおけるJenkins活用事例

開発・保守・運用の諸問題

コーディングスタイルや運用をかなりガチガチに決めている。
これを実現するための自社フレームワークを用意している。

ここ1年でコーディングスタイルの属人化が進んでしまった。

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を使っている。

Jenkins + GitHub Enterprise(株式会社ミクシィ 大塚氏)


こちらは参加できなかったので、スライドだけ掲載しておきます。

書籍

Jenkins実践入門 ?ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)

Jenkins実践入門 ?ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)


Jenkins

Jenkins


入門Jenkins―実践「継続的インテグレーション」

入門Jenkins―実践「継続的インテグレーション」