Aiming 黒木さん
テストを毎日おこなうためにやったこと
あるプロジェクトでのJenkins
- テストの実行
- Rspec
- ci_reporter
- Rspecの実行結果をXML出力できる
- ci_reporter
- Jasmine
- Rspec
- テスト7000件越え
- 実行時間１時間越え
- 手元で全件実行が困難→自動テストの重要性が増す
- 分割して並行に実行
- カテゴリ分け → Jenkinsのラベル付けが便利
- Join Plugin
- Aが成功したらBとCを実行して、両方成功したらD…みたいなことができる
- Build Pipeline Plugin
- Gerrit レビューシステム
- Gerrit Trigger Plugin
- レビュー依頼が提出されたらJinkinsのジョブを実行
- Jenkinsの実行が開発のペースに追いつかない
- Jenkinsの完了を待たずにマージせざるを得ない
- 無駄なテスト実行を減らしたい
- 既にマージされている変更のテスト
- 既に修正再提出されている変更の元のテスト
- Jenkinsのジョブを中断にするには
- →Web UIの中断ボタンのURLをcurlで叩く
- そのあとsleepすることで次の実行を抑止
- Jenkinsがやってくれるのは自動化だけ
- Pluginのドキュメントをちゃんと読む
- なんだったらコードも読む
- ビルド
- Android, iOS
- ゲームサーバー
- テスト実行
- デプロイ
- サーバ再起動
- データチェック
- マスタデータにミスが有るとビルドが止まって困る
- 取り込む部分だけをジョブ化
- skypeにビルド結果を通知
- パトランプ
楽天 荻野さん
- ソフトウェア開発の困難なポイント → コンポーネントの結合
- コンポーネントの結合 ＝ 仮説の検証
- Continuous Integrationが有効
結合テストも自動化し、CIサイクルの中で回す！
結合テストの自動化 → ユーザに高付加価値をもたらす仮説の検証
- テストの複雑さ
- 複雑な内部状態などはUTで
- 原則ブラックボックステスト
- テストの実装コスト
- テストフレームワークを新たに開発 Ngauto
- テストの実行時間
- コミットビルドで10分のSmoke Test
- 実行時間は10分
- シンプルなテスト
- 結合テストのテストジョブは１時間で分割
- 50台のテスト環境でスケール
- 重要なテストを優先して実行
- コミットビルドで10分のSmoke Test
- テストの再現性
- 環境差異
- システムの状態差異
- 解決方法 クリーンアップ＆インストール
図で説明
- 早い段階からバグが発見できる！
- コミットビルドとしてのSmoke Testの重要性
結合テストの自動化とは
- 結合の検証までを自動化
- 結合バグを早期に発見
CROOZ 鈴木さん
Jenkinsをどのように活用し、日々の開発・保守・運用で抱える業務課題の解決に活用しているか紹介
リリースギリギリまで全社員一丸となりトライ・アンド・エラーを繰り返す
- コーディングスタイルの共通化
- 運用の共通化
- 上記を実現する自社フレームワークの構築
→開発リソースの移動が用意になり、ぎりぎりまでこだわることができる
- コーディングスタイルの共通化が行われにくい
- 共通化されているルールは複雑すぎる。古株の社員しか対応できない
- プログラマが急増した
- ルール違反をプログラマにフィードバックする仕組みがない
- 本来不要なファイルが誤って本番に上がってしまった
機械的に検知し、フィードバックする必要がある
そのためにJenkins！
- 構築が容易
- 各種プラグインが充実
- ジョブ管理ツール
- 実装言語によらず全社横断で利用可能
- ドキュメントが豊富
- 規約チェックの自動化
- PHP_Code Sniffer × VenusBaseによる規約チェック
- コーディング規約違反はIDE上で通知
- 除外ファイルの更新漏れの自動通知
- GitList
今回は割愛
- 規約チェックの自動化
- 規約違反が1/5に
- 既存のコードに対する自主的な改善が行われるようになった
- 結果として、ルールを覚えなくてもコーディングが可能に
- 除外ファイルの更新漏れの自動通知
- 除外漏れの発生が激減
- 目指すはテスト自動化
- 自動ビルドによるデグレ防止
将来的には
- 開発のオートメーション化
mixi 五嶋さん
- 言語：Perl
- ファイル数：18000
- テストケース：25万以上
Full Test実行に45min
時間がかかるとリリースが伸びる → 早くしたい！
- Jenkins * perl: テスト実行フローの理解
- Prove
- テストの並列実行・再帰的実行をサポート
- 失敗したテストだけを実行するなど多機能
- 多言語でも利用可能
- TAP
- Test Anything Protocol
- 成功ならok、失敗ならnot ok
- TAP
- 並列実行の問題とFixture: テスト実行方法の理解
- proveのオプションで並列にテストを処理
- 共通DB参照によるデータ不整合
- Fixture
- テスト毎に別DBを作成し、それを参照
- Fixtureによるテスト毎のDB作成・廃棄
- テスト毎のモジュール読み込み
解決策として考えられるのは
- モジュール読み込み時間を削る
- forkprove
- proveで並列実行する際にforkして子プロセスで行う
- forkprove
- Fixtureで生成したDBをキャッシュする
しかし
- モジュールを先読みすると不整合を生じるケースが有る
- DBをキャッシュする機構は実装がむずかしく、コストに見あうかわからない
そんな時に
テスト実行を複数ノードで
8minで終わるように！
- remote test
- 負荷のかかるテストはJenkinsを介して行う
- 問題点
- 前のテストの実行が終わるまで待たねばならない
- 同じタイミングで大量にテストが投げられるとマスターが高負荷に
サイバーエージェント 丸山さん
運用開始してそれなりに期間が経ったピグでの運用効率化について
バグの発生を抑える
- まずはtrunkをテスト
- 数千個のFindbugs警告
- CI環境の整備
- 危ないバグはみんなで修正
- その警告、本当に必要？
- 一部のコードは解析対象から除外
- 警告そのものを無効化
- IRC開いてないと通知に気づかない
- ガイドラインに沿ったコードになっているかのチェックを自動化
責務の分離と可視化
- cron起動＆SpringBatchが混在
- 新バッチサーバ＆旧バッチサーバ
- ジョブの実行状況が把握しづらい
- SpringBatch固有の問題
そこでJenkins！
- SpringBatchを捨てる
- ジョブ実行用のシンプルなFrameworkを作成
- cron起動していたジョブもJenkinsから実行
- Jenkinsでバッチを制御
- Remote APIを利用したリソース監視
- キューイングされているジョブがないか
- 同一ジョブの多重実行がないか
課題
- 権限問題
同じ過ちは繰り返さない
- 本番環境は２系統
- 毎週切り替え
- 本番／待機系でリリース物が異なってヒヤリ
- 管理画面がInternetに公開
- サーバの死活監視がされていない事件
などなど
- 人間が運用するとまたミスる
ので
- リリースの差分チェック
- リマインダ
今後の展望
- 自動化出来る範囲を広げる
- コードの品質管理
- バッチ制御
- オペレーションの自動化
途中から入れるとめんどくさいので__はじめから入れようぜ！__