2013/06/18に 六本木ヒルズ 49F アカデミーヒルズで行われた
「第6回テックヒルズ Let’s study Jenkins ~さまざまなケーススタディ~」に参加して来ました
詳細)
700人を超える参加者で、テストへの開発現場の関心の高さが伺えるイベントでした
セッションは、タワーホールとスカイスタジオと2会場で 行われましたが
私は タワーホールのセッションのみ参加しました(単に移動がめんどくさかった( ° ω ° ; )
いろいろな 会社の方の導入ケースや、対策等のお話が聞けて、とても参考になった意義のあるセッションでした
以下は、個人的メモです
青文字は、わたくし追加の参考リンクです
「Aiming における Jenkins 活用事例(仮)」
株式会社Aiming / 黒木 慎介
増えていくテストで 自動でまわすためにおこなったこと
→ 黒木さん:railsエンジニア
テストの実行頻度と戦ったお話
・プロジェクト概要
RoR+coffeeScript+backbone.js+α
・テストツール
RoR:Rspec(ci_reporter→結果をXMLで出せる
js:Jasmine
参考)
・増えるテスト件数
テスト、最初は5分、10分で終わってた・・・
プロジェクトが進むにつれて、テスト7000件越え・・・
全件実行が難しい
・対策
分割して並行に実行
スレーブを 2台から6台に
●テストをカテゴリ別に分類する
→ラベル付
ジョブの設定画面でラベル式・・・ プロジェクトとカテゴリーを実行する みたいに設定できる
→join plugin(プラグイン)
実行に条件が付けられる
AとBが うまく行ったら Cを実行するみたいな
→build Pipeline(プラグイン)
実行を視覚化
●実行頻度との戦い
Gerrit Trigger Plugin
→変更箇所 すべてにはしらせるので 数が多いと問題
→無駄なテスト実行は減らしたい
変更されたものの、元ソースまではテストしたくない・・・など
・Jenkins心構え
Jenkinsがやってくれるのは自動化だけ
Pluginのドキュメントをちゃんと読むこと
→ Plugin wiki
→ それでもわからんとき・・ コードも読む インフォメーションからソースのrepositoryへ飛べる
★Jenkins運用の流れ参考
・ビルド
・テスト実行
・デプロイ
・サーバ再起動
・データチェック
Aimingさんのところでは、エラーのアラートはスカイプ、メールで飛んでくる( ・∀・)イイ!!
「検索基盤開発の為の統合テスト環境の自動化」
楽天株式会社 / 荻野 恒太郎
・コンポーネントの結合
→ =仮説の検証
・結合テストの自動化
【4つの課題】
複雑さ
単体:コンポーネント単位でテスト
結合:単体レベルでは行えないようなテスト
コスト
結合テストのためのフレームワーク開発をした
実行時間
テストを、細分化する
ちっちゃいテストをして、通ったものだけ 結合テストへ進める
結果の再現性
毎回テストごとに、環境のクリーンアップ・インストール・データの投入をしている
>毎回 環境を同じにする
>結果を保証する
使用プラグイン
Priority Sorter Plugin
→ テストの実行優先度を変えることができる
テスト自動化のメリット
>開発の早い段階から、結合レベルのバグを 発見することができる
>開発の最後の方は、より 密度の高いバグ対応に専念できる(序盤の方で、軽度のバグ対応がすんでしまうので)
>要件・仕様変更に 柔軟に対応できる
楽天さんでは、コミット前テストにパスしたものだけ コミットする仕組みを採用している。これはいいなと思った。
「CROOZにおけるJenkins活用事例(仮)」
クルーズ株式会社 / 鈴木 優一
日々の開発の中での、保守・運用 問題解決法のはなし
・コーディングスタイルの共通化は むずかしい
>どうしたって、 属人化が起こる
・ルール違反や オペミスを起こしそうな コード・設定を プログラマにフィードバックする仕組みが必要
>機械にやらせる=Jenkins
・Jenkinsの決め手
構築が容易
プラグインの充実
ジョブ管理ツールとしても使える
>リモートシェルとしても使える
テスト対象の実装言語は なんでもOK
ドキュメント豊富
・事例
規約チェックの自動化
>使用しているプラグインなど
PHP Code Sniffer(イクリプスにも プラグインある PDT)
VenusBase(びーなすべーす)・・・クルーズさん独自の定義ファイル
参考)
・GitList(PHP)
→ PHP製 Git ブラウザ
・運用の流れ
Eclipseで、コード規約チェック(PHP_CodeSniffer)を使用した開発を徹底。
その後、Jenkinsでさらに、規約チェックの他、問題になりそうなコードをチェック
アラートは開発者へフィードバック・・・というながれ。
・将来的に(・・・いろいろあった中で)
>修正箇所の、自動チケット化
↑これはいいかも
鈴木さんの発表スライド:
Croozにおけるjenkins活用事例20130618
「ぼくとJenkinsおじさんとの300日戦争(仮)」
株式会社ミクシィ / 五嶋 壮晃
・テスト高速化への取り組み
採用してるオプション
Prove
TAP
並列実行の問題と fixture
モジュール読み込み時間短縮
forkprove
fixtureで 生成したDBをキャッシュする
・・・などなど
↑色々模索中らしいです、が・・・
結局 今んとこの解決方法は 力技!!!w(テストのサーバを48台に・・・・)
ジェンキンスの問題
A(先行)とB(後行)のテストがあった時
Bが 先に実行終わっても、先に走ってるAの実行が続いてるので待たされる(らしい
おまけ)
mixiさんちの 1分ライブ宣伝ありました
>deploy gate フリープランあるよ
「piggとJenkinsと私(仮)」
株式会社サイバーエージェント / 丸山 隆司
【ケーススタディ】
・コードの品質管理
・バッチ制御
・オペレーションの自動化
・コードの品質管理
~バグの発生を抑える
CI環境の整備 ・・・基本的なこと
その警告ほんとうに必要??・・・
一部のコードは解析対象から外す
>DTO(getter/setterのみ)やテストコード
>コンストラクタでの フィールドの初期化
>javadoc
・バッチ制御
~責務の分離と可視化
57本のバッチが動いてる(2013年6月現在)
不要データ削除
ログの収集
【問題】
新旧バッチサーバ混在
ジョブの実行もバラバラ(クーロンだったり SpringBatchだったり)
↓
Jenkinsで対応 >Jenkinsからバッチをキックする
・スケジューリング
・実行記録の保持
・RemoteAPIを利用した Jenkinsそのものの監視(これはちょっと興味深い)
> キューイングされているジョブがないか?
> 同一ジョブの多重実行がないか??
今後の問題
Jenkinsの 権限の話
> 現状は 誰でもジョブが実行できる問題
・オペレーションの自動化
~同じ過ちは繰り返させない
本番リリースミスなどの、起こしてはならない 自体への対処
Jenkinsで サーバのモニタリング
・リソースの差分チェック
サーバ間のソースの差異をチェック
本番/待機系間のソースの差分をチェック
・リマインダ機能
今後の展望・・・・
シェルをゴリゴリ書けば、色々できるらしい・・・
>稼動系の切り替えとか
>デプロイ・リリースとか
最後に・・・
Jenkins・・・
途中から入れるのはめんどい・・・・「はじめから入れようぜ!!!」