5月20日（金）にNTTソフトウェア様の会場をお借りして，6名の発表者と80名超の参加者と共に「第3回Jenkins勉強会」を開催いたしました。本稿では，今回の勉強会の模様をレポートします。

今回のテーマは「LL言語プロジェクトにおけるJenkinsの運用について」です。Python, PHP, Rubyなど現在運用中の方々による事例報告やお役立ちプラグイン活用術などを発表していただき，発表中やその後の懇親会で活発な意見交換が行われました。

なお，当日のUstreamをはじめ，各発表者の発表資料や参加者の感想ブログはJenkins Wikiにまとめられています。本レポートの補足としてご参照ください。

• 第3回Jenkins勉強会 - 日本語 - Jenkins Wiki

Jenkinsプロジェクトの現状報告

当初の発表スケジュールには含めていなかったのですが，前回の勉強会以降でJenkinsを取り巻く状況が変わっていたため，Jenkinsプロジェクトをリードする川口氏にJenkinsプロジェクトの現状を報告をしていただきました。

プロジェクトの状況

数ヶ月前にHudsonからフォークされたJenkinsですが，フォーク後もますます活発に開発が行われています。これは，コミット件数や1リリースあたりの解決チケット数からも統計的に裏付けされています。また，開発者の大多数がJenkinsに移動しており，使用頻度が高いトップ25のプラグインもそのほとんどがJenkinsに移動してアップデートが加えられています。

ユーザ側の動向を見ても，ユーザMLのトラフィック数やダウンロード数はHudson側のそれと比較して数倍となっています。また，ApacheやJRuby，Scalaといった著名なプロジェクトもHudsonからJenkinsに移行しています。

Oracle，HudsonをEclipseへ

上記のように，Jenkinsプロジェクトは想定以上の成功を収めていると言えます。この状況を踏まえて，OracleはHudsonをEclipseへ移管することを発表しました。ここで，議論の対象として上がってくるのは，「⁠HudsonとJenkinsは再度合流するのか？」という点です。

同種のプロジェクトが複数ある場合の問題点は，開発リソースや情報の分散です。上述したように開発者の大多数はJenkins側に移っているため，開発リソースの分散という点は率直なところそれほどの問題とはなっていないという認識があります。ただし，ユーザ側からすると複数プロジェクトがあるとどちらを使ってよいかを悩むため，合流を望む声が多いのも事実です。

プロジェクトを合流することが目的でHudsonをEclipseへ移管したわけではないとOracle側は明言しており，今までの経緯も踏まえるとただちに合流することは困難でしょう。ただ，Hudson/Jenkinsを利用しているユーザのことも考慮した上で，Eclipseの下でプロジェクトの合流を果たすための条件や，Apacheへの移管も含めたその他の選択肢を現在探っているところです。

RubyによるJenkinsプラグイン開発

Jenkinsプロジェクトの現状報告に引き続き，RubyによってJenkinsプラグインを開発できるようにする取り組みについて，川口氏から発表を行っていただきました。

もともとこのプロジェクトはCharles Lowell氏が推進しているもので，その意図としてはRuby開発者がJavaを意識することなくRubyの知識だけでJenkinsを拡張できるようにしたいというところからきているそうです。発表内でデモが行われ，Rubyで記述されたコードが実際に動作している様子を見ることができました。技術的に困難な箇所は大体解決できており，今後は実用化に向けて必要な実装や調整を加えていく段階だということです。

このプロジェクトが実用化されればRubyのユーザ層をJenkinsの開発者層に取り込むことができ，そこからRuby開発に便利なプラグインが作成されて，Rubyユーザにとってより一層魅力的な環境が整うことになります。さらに推し進めていくと，Pythonなど他のスクリプト言語でも同様に拡張できるでしょう。Java開発だけでなく，あらゆるプロジェクトにおいてJenkinsが効果的に活用されることが期待されます。

Jenkinsと一緒にTracプラグイン開発 - UT/IT自動化のコツ -

NTTデータの和田氏からは，Jenkinsを利用してTracプラグイン開発のタスク自動化を推進している事例が紹介されました。

和田氏が業務で携わっているTracプラグインの開発では，機能はないがリリースできる状態から始める⁠”ゼロ機能リリース⁠”を念頭に置いて開発を進めているとのことです。ゼロ機能リリースを実現するために，ソースコードやSeleniumでの検証を含めたテストコード一式を雛形として用意しておき，その雛形をコピーすることによって即座に動くものがリリースできるようになります。合わせて，その状態で実行できるJenkinsのジョブを用意しておけば，テスト実行からデプロイまで自動化できるという説明がされました。

ゼロ機能リリースを実現できればプロジェクトの初期から動くものを提供できるため，開発者・ユーザ双方に安心感を与えることができます。ただし，動いているソースコードに対する変更は避けられないため，変更による影響を早期に検知するためにCIが必須となります。ゼロ機能リリースにJenkinsを組み合わせることにより，ユーザにとってより価値が高いものを提供できるようになるでしょう。