Jenkins ユーザ・カンファレンス 2012 東京に参加してきた

▲法政大学さったホールひ、広い！
ちょっと前の話になるのですが日本Jenkinsユーザ会主催のJenkins ユーザ・カンファレンス 2012 東京に参加してきました。
私のJenkinsレベルは @zephiransas が設定してくれたおかげでなんとなく使ってるといった感じ。
そんなゆるふわJenkinsユーザーの感想は以下のとおりです。

Jenkinsプロジェクト現状報告とこれから(川口耕介氏)

作者自らJenkinsの現状と新機能について説明してくださいました。
Ruby開発者が沢山使っているとのことで、Ruby系の人からの意見も取り入れているそうです。

・現在のインストール総数(マスターの数) 43,000
・新機能の紹介
マウスオーバーで機能が出てくる
ドラッグ＆ドロップで順序が変えられる。（点線の枠が出てくる）
ビルド後の処理がメニューから選べる
プラグインをインストールする画面で検索できるようにした
再起動しなくてもプラグインを利用可能

・REST APIの改善
json出力
=>URLの最後に/jsonをつけると結果をJSONで返してくれる

・ANSIカラーコード対応(Web上で文字に色がつく)
=>Ruby系の人は色がつくのが好き

・Rubyによるプラグイン開発
RubiestはJavaを触っているところを同僚にみられるとマズイ
GroovyによるHTML生成
拡張ポイントの拡充

・Jenkins CIAプログラム
Jenkinsについてどこかで発表すればTシャツとステッカーを送ってくれる

・今後の展望
プラグイン開発者を助ける

・拡張ポイントの充実
特にRubyの人たちが新しい考えを作ってくれたのでJava系の人にフィードバックしたい

・初期状態でCVS,Subversionしかないのを見直したい。
色々プラグインを入れないとまともに使えない状況になっている。

・プラグインのレビュー、インストール数
iTunesのプレイリストみたいにしたい

・テスト実行の並列化を助けたい
多数の計算機を跨ぐ作業を簡単にしたい

Jenkins.rbで始めるRubyでJenkinsプラグイン作成(ペーパーボーイ柴田博志氏)

岡山Ruby会議01にも来ていただいた柴田さんのお話。Javaを知らなくてもJenkinsPluginは作れるみたい。でもドキュメントが少なくちょっと難しそう。
Rubyと言えばrvmやrbenvなどで環境を取っ替えひっかえしてる人が多いと思うけどreleaseパッケージに固めた時点でJRubyが内包されるようで一安心。
RSpecのテストのために、ソースをベタ書きするのではなくclassを作成してその中に書くこと。

開発意外でのJenkins活用方法 (株式会社ニューキャスト奥清隆氏)

開発者以外にJenkinsを使ってもらう話ということでDTP作業の差分確認に利用しているとのこと。フロントエンドの画面は別に作成してJenkinsは裏で動かしてAPIを叩いているらしい。
単なるビルド・テストツール以外のJenkinsの可能性を感じた。

毎日が憧れの新築、反復可能なデリバリーによる常時新築システム (株式会社富士通研究所大嶽智裕氏)

Jenkinsを使用してPaaSのバックエンドシステムのインストールを高速・自動化したお話。
テストは並列化することで高速化できるが、環境構築は一連の流れを考慮する必要があるので高速化が難しい。処理の流れを解析してムダを省いて高速化するプロセスが興味深かった。
また、高速化することで設定変更してテストの繰り返しのサイクルが速くなり、開発者の意識が変わっていくというお話も。高速化は重要。

LT大会

@cynipeさんの「運用でも使えるjenkins」という話が面白かった。お客さんのサーバーで動いているcronは結果を通知しない。せっかく出力されるログも/dev/nullに放り込まれている。実行時間の推移も見ることができない。ならばJenkinsをつかえばいいじゃないかという流れ。Jenkinsはcronの超進化系だと感じた。

まとめ&私の課題

カンファレンスに参加して私のJenkins環境において2点の課題を感じた。

1.失敗が分かるのが遅い
せっかくテストでこけている箇所を修正してもテストの順番によっては後にならないと検出できない
=> テストの順番を替えるしかない。parallel_testsを捨て、Jenkinsを用いた分散テストフレームワークを構築する

2.全体のテストが遅い
テストが遅いのでリリースまで時間がかかる。
・JenkinsのMaster/Slaveを使用して並列化を行う。
=>並列用のマシンを増やして対応する。Parallel_testが不安定なこともあるし、細かい粒度のテストを複数サーバーに投げるような仕組みを構築したほうが良いように思う。
・毎回やらなくてもよい処理をやってないか？
=>DBの作成は低速なmigrateを使用して行なっている。migrateファイルに変更がなければDBは使いまわすことができるはず。処理の流れを見直す。