http://connpass.com/event/467/
Jenkins ユーザ・カンファレンス 2012 東京
http://build-shokunin.org/juc2012/
2012/07/29Jenkins ユーザ・カンファレンス 2012 東京 Vol.1 #juc2012
http://togetter.com/li/346310
2012/07/29 Jenkins ユーザ・カンファレンス 2012 東京 Vol.2 #juc2012
http://togetter.com/li/346736
きっかけ
本格的にJenkinsを使い出したきっかけは、TDDBC横浜でコミットフックでビルドからレポートまで自動で行われていたのを見てからです。
仕事で使うツールを作っていた時、カバレッジを取るためにCoberturaを使っていたのですが、マシンが非力なため欲しい時にすぐに見れないというもどかしさがありました。
JenkinsならSCMと連携してコミットフックスクリプトからジョブを起動することができます。
これで、重たいビルドやレポート処理を別のマシンに任せることが出来、結果、テストの漏れや他のテストを壊していないか確認しながら進めることが出来ました。
その他にも、シェルスクリプトが書けるので、DBのバックアップを定時処理やwgetを実行して任意のタイミングで取る等に利用しています。
そんなに便利なJenkinsさんを使い倒している人たちが集まるカンファレンスなので、自分の知らない使い方を知ることが出来ると思い、参加しました。
仕事で使うツールを作っていた時、カバレッジを取るためにCoberturaを使っていたのですが、マシンが非力なため欲しい時にすぐに見れないというもどかしさがありました。
JenkinsならSCMと連携してコミットフックスクリプトからジョブを起動することができます。
これで、重たいビルドやレポート処理を別のマシンに任せることが出来、結果、テストの漏れや他のテストを壊していないか確認しながら進めることが出来ました。
その他にも、シェルスクリプトが書けるので、DBのバックアップを定時処理やwgetを実行して任意のタイミングで取る等に利用しています。
そんなに便利なJenkinsさんを使い倒している人たちが集まるカンファレンスなので、自分の知らない使い方を知ることが出来ると思い、参加しました。
セッション
当日は、以下のセッションを受講しました。
特に印象的だったのは、Githubと連携してJenkinsがbuildを開始するデモにおける@kohsukekawaさんのタイプスピードでした。
その他には、プラグインの拡張ポイントの拡充や、Rubyによるプラグイン開発を可能にしたりとよりプラグインを使いやすくしたりする方向にシフトしているとのことです。
また、UIもVersion up毎に変わっていたのを感じていましたが、よりUXを充実したものにしようとする試みがなされていてとても使いやすくなってきています。
継続的デリバリーの話は、@ryuzeeさんの講演でいろいろ聞いていましたので英語でも分からないことが少なくてよかったです。
受け入れテストをコードで書くのは、SpockなりGebなりでやってみようと思います。
Jenkinsさんは、プロセスを改善する際に現状の把握と手助けをしてくれます。
そして、現実と戦うためにはやらないことや優先順位の低いものとして割り切らなければならない選択が必要になってきます。その選択を手伝ってくれるのもJenkinsさんです。
仮想化が出来るようになったおかげで、環境構築のテストも自動化の対象とすることが出来るようになりました。
Chef soloの実運用の話が聞けたのは、とても有意義でした。特に冪等性の話は、一度だけではなく何度でも実行できるようにしておくことで、フィードバックループを早く回せることが出来るので、スクリプトを組む際は考慮して行こうと思いました。
- Jenkinsプロジェクト現状報告とこれから (基調講演)
- Jenkinsによる自動受け入れテストから継続的デリバリーまで
- 愛されるJenkins氏になるために
- マルチステージ型継続的インテグレーションのすすめ
- 毎日が憧れの新築、反復可能なデリバリーによる常時新築システム
特に印象的だったのは、Githubと連携してJenkinsがbuildを開始するデモにおける@kohsukekawaさんのタイプスピードでした。
その他には、プラグインの拡張ポイントの拡充や、Rubyによるプラグイン開発を可能にしたりとよりプラグインを使いやすくしたりする方向にシフトしているとのことです。
また、UIもVersion up毎に変わっていたのを感じていましたが、よりUXを充実したものにしようとする試みがなされていてとても使いやすくなってきています。
継続的デリバリーの話は、@ryuzeeさんの講演でいろいろ聞いていましたので英語でも分からないことが少なくてよかったです。
受け入れテストをコードで書くのは、SpockなりGebなりでやってみようと思います。
Jenkinsさんは、プロセスを改善する際に現状の把握と手助けをしてくれます。
そして、現実と戦うためにはやらないことや優先順位の低いものとして割り切らなければならない選択が必要になってきます。その選択を手伝ってくれるのもJenkinsさんです。
仮想化が出来るようになったおかげで、環境構築のテストも自動化の対象とすることが出来るようになりました。
Chef soloの実運用の話が聞けたのは、とても有意義でした。特に冪等性の話は、一度だけではなく何度でも実行できるようにしておくことで、フィードバックループを早く回せることが出来るので、スクリプトを組む際は考慮して行こうと思いました。
最後に
基調講演でも紹介されたbuildhiveに先日のTDD in Actionで利用したプロジェクトを試しに追加してみました。
自動的にgradleのプロジェクトとして認識されて、普通にtestまで出来てしまいました。
まだgradleでカバレッジ系のプラグインを試していないのですが、多分普通に使えるのでは無いかなと思っているので、試してみたいと思います。
レポジトリにpushされるたびにビルドが実行されるので、pull requestとの相性もバッチリです。
Jenkinsさんを世に出してくれた@kohsukekawaさん、リアルJenkinsさんである@ikikkoさん、講演者の方々、スタッフの皆様、会場を提供してくださった法政大学様ありがとうございました。
自動的にgradleのプロジェクトとして認識されて、普通にtestまで出来てしまいました。
まだgradleでカバレッジ系のプラグインを試していないのですが、多分普通に使えるのでは無いかなと思っているので、試してみたいと思います。
レポジトリにpushされるたびにビルドが実行されるので、pull requestとの相性もバッチリです。
Jenkinsさんを世に出してくれた@kohsukekawaさん、リアルJenkinsさんである@ikikkoさん、講演者の方々、スタッフの皆様、会場を提供してくださった法政大学様ありがとうございました。
