前回 に引き続き、第2回Jenkins勉強会が2月25日に開催されました。今回はニフティエンジニアサポート様の協力のもと80名余りの参加者が集い、「 JavaプロジェクトにおけるJenkinsの運用について」をテーマに8名の方に発表していただきました。
なお、当日のUstreamをはじめ、各発表者の発表資料や参加者の感想ブログは下記サイトにまとめられています。本レポートの補足として参照ください。
プロジェクト名称変更に関する経緯
まず始めに、Jenkins/Hudsonの創始者で現在はCloudBees所属の川口氏 から、HudsonからJenkinsへ名称変更した経緯について報告がありました。
Hudsonの歴史
Hudsonは、2004年に川口氏の個人プロジェクトから始まりました。氏が所属していたSun Mycrosystemsの内部でHudsonが使われるに伴い、Hudson開発が正式に川口氏の仕事の一部となりました。Hudsonの運営は川口氏と複数の有志によるコミュニティ主導で行われており、SunがOracleに買収されてからもその運営方法は基本的に変更ありませんでした。
Hudsonの開発はSunの開発インフラ上で進められていましたが、より利便性の高い外部のプロダクトを採用しようという意見がコミュニティの間であがってきました。その第一歩として、まずBTSがjava.netからJIRAに移行され、2010年11月にはメーリングリストをGoogle Groupに移動するという提案があがりました。メーリングリスト移行の話と並行して、java.net側でも新しいインフラへの移行が行われていたのですが、インフラ移行の最中にHudsonプロジェクトがロックされるという事態が起こりました。このことを機会にリポジトリもGitHubに移行しようという提案がなされ、実際にリポジトリの移行が間近だったのですが、Oracle側から「Hudsonの商標はOracleが所有しているため、Oracleの許可無くソースコードを移管することは許されない」という意見が出されました[1]
Oracleとの交渉決裂・プロジェクトのフォーク
上記の商標問題は、短期的にはGitHubへの移行という問題ですが、中長期的にはプロジェクトの自律性という観点が考慮されました。上述した通り、Hudsonプロジェクトの運営はコミュニティが中心となって行っており、Hudsonに対するOracleの貢献はあまり大きなものではありませんでした。そのため、Oracleが商標の所有を通じてプロジェクトの運営の最終決定を独占するという統治モデルにはコミュニティからも反発が起き、プロジェクトをフォークすべきという声もあがっていました。
ただし、Hudsonコミュニティの主要メンバーは、フォークした際の影響度を考慮して、Oracleと調整していこうという立場を通していました。そこで、2010年12月頃から主要メンバーとOracleの間で交渉が始まりました。
交渉に当たって、コミュニティ側からの意見は下記の点でした。
商標を中立の財団などの第3者機関に委託して、プロジェクト参加者間の平等を保ちたい
プロジェクトへの貢献度合いに応じて、発言権があるというOSSのポリシーを尊重して欲しい
対して、Oracleの要求は主に下記の2点でした。
プロジェクトの統治モデルを確立させたい
コードの変更を確実にレビュー・追跡したい
残念ながら、2ヶ月に及ぶこの交渉は決裂しました。Oracleとしては、商標を第3者に委託するという要求は受け入れられないという点が決定的になったようです。また、コミュニティ側の主要メンバーとOracleとの間で、交渉を通してよりよい人間関係・信頼関係を構築できなかったということも、交渉決裂の一因として取り上げられていました。
交渉が決裂したことにより、コミュニティ内メンバーの投票を経て、HudsonプロジェクトはJenkinsプロジェクトとしてフォークされました。Jenkinsプロジェクトを始めるに当たって、今回の反省点を踏まえて下記の点が考慮されました。
役員会を選出して、プロジェクトの統治モデルを確立させて安定運用を目指す
第3者機関に商標を委託し、ソースコードのライセンス管理を第3者機関で行う
Jenkinsプロジェクトの現況
コア・プラグインともにHudson開発者の大多数はJenkinsへ移行しており、有志が集計したデータの統計的にも裏付けされています。よって、プロジェクトの運営と今後の開発に関して、今まで同様まったく問題なく継続して行えるでしょう。
また、プロジェクト名称の変更と合わせて、Jenkinsの新しいロゴを決めるコンテストがつい先日の3月4日まで行われていました。そう遠くないうちに、新しいロゴをお披露目できるかと思います。
HudsonからJenkinsへのアップグレードは、非常に簡単に行えます。Debianパッケージなどの一部のパッケージでは若干設定ファイルの修正が必要になることもありますが、既に検証されている方もいますのでそう難しくはないでしょう。アップグレードの際には、下記リンクも参考にしてください。
Sun Java EE部隊のJenkins運用例
プロジェクト名称変更に関する経緯報告が行われた後、引き続き川口氏からSunでのGlassFish開発時にJenkinsを活用した事例が紹介されました。
GlassFishは複数チームによって多数のコンポーネントが同時開発で進むというスタイルで、その際に各コンポーネントのインテグレーションを効率よく進めるためにJenkinsを利用していたということです。具体例として、プラグインを活用してテストをパスしたコンポーネントにのみマークをつけたり、Jenkinsでのビルド時に下流コンポーネントも含めてテストを行うことで、インテグレーション後に発覚する障害を減らすことができたと紹介されました。
また、「 Jenkinsをどのように各チームに浸透させていくか？」という話題も取り上げられていました。川口氏の経験談として、トップダウンで周知させていくやり方では押し付けがちになり、また関連する人が増えて説得に時間が取られるということでした。そこで、実際に現場で手を動かしている学習意欲の高い人を仲間にし、草の根的に展開していくボトムアップな方法を勧めていました。このような考え方は、Jenkinsに限らず各種ツールを新たに導入する際に参考になることでしょう。
Jenkins+Maven活用術
グルージェント所属の岡本氏 からは、氏がメインで使っているMavenと、Mavenに関連するJenkinsの活用について発表していただきました。
まず、Mavenで各環境に応じて設定を切り替える方法について、デモを交えた説明がありました。実際の開発プロジェクトでは本番環境やステージング環境に応じて、ログ設定やデータベース接続先の設定などを切り替える必要がありますが、この環境に応じた設定をMavenのプロファイルを用いて切り替えるというやり方です。また、カバレッジツールであるEmmaのMaven/Jenkinsプラグインを利用して、Maven実行時に1つオプションを追加するだけでコードカバレッジを取得する方法が紹介されました。
JenkinsのようなCIツールを効果的に使用するには、開発者のローカル環境とは別にCI環境でもビルドを行えるように設定する必要があります。その点を考慮しても、環境ごとに設定内容を切り替えるという考え方は重要です。
JenkinsエンジニアのためのGroovy入門
前回の勉強会でLT発表をしていただいた奥氏 からは、GroovyとJenkinsの連携についての発表です。
最初に、Javaで記述されたソースコードをGroovyに変換していく流れを通して、Groovyについて簡単な説明がありました。続いてGroovyとJenkinsの連携に関して、GroovyでJenkinsを管理する方法と、Jenkins上でGroovyを実行する方法の2通りの方法が紹介されました。GroovyでJenkinsを管理する方法としてブラウザ上から実行できるスクリプトコンソールやコマンドラインインターフェースを備えたJenkins CLIが、Jenkins上でGroovyを実行する方法としてGroovy Pluginがデモを交えながら説明されました。
Jenkins内部でGroovyが用いられていることもあり、GroovyとJenkinsの相性は他の言語よりよいものとなっています。Groovyをうまく活用することによって、Jenkinsをより一層効率的に使えるでしょう。
脅迫
LT発表の1人目は、TracLigntningの作者であるOかもと氏 です。
TracLightningにはJenkinsが同梱されておりインストールするとすぐに使用できるのですが、実は作成当初のCIツールにはApache Continuumが採用されていました。川口氏からの要請を受けてContinuumからJenkinsへ移行したとのことですが、そのときの経緯をOかもと氏独特のユーモアを交えた語りで説明していただきました。
開発環境を構成する要素として、CIツールやBTSが有用なことは広く認識されてきています。TracLightningのように、それらをまとめて提供するツールをうまく活用することで、より効率的に開発環境を構築できることでしょう。
Jenkins+Play!で気軽にCI!
シャノン所属の池田氏 からは、Play FrameworkでのCI事情とそれに関するJenkinsプラグインについてお話いただきました。
Play Frameworkに備わっているテスト機構では、Jenkins上でテストを実行しても結果が視覚的に分かりづらいことが欠点とのことでした。これは、テストの実行結果が独自のHTMLフォーマットで出力されるため、Jenkinsがテスト結果を解釈できないからです。そこで池田氏は、テスト結果をJenkins上で視覚的に表示するプラグインを開発することによって、この欠点を解消しようと試みたそうです。
残念ながら5分の時間内に収まらずプラグインの説明まではできなかったのですが、Play Frameworkと本発表に興味をお持ちの方も会場内には多かったようです。懇親会参加者に勉強会の感想を聞いたところ、池田氏の発表を最後まで聞きたかったという意見も多くあがりました。
プラグイン活用のススメ
続いては、Jenkinsプラグインの日本語化を積極的に進めているtyuki39氏 の発表です。
tyuki39氏からは、FindBugsやCheckstyleといったJava開発時に有用なプラグインをピックアップして紹介していただきました。また、上記で取り上げたプラグインを一括でインストール・初期設定を行うGantスクリプトを作成して検証されたようです。
Jenkinsの特徴の一つは豊富なプラグインにありますが、Jenkinsを初めて導入する方にとってはプラグインが多すぎて逆に判断できないという声もあります。そのような方にとって、tyuki39氏の発表はJenkins導入の手助けとなるでしょう。
JenkinsのSlave事情
ハピルス株式会社代表の藤川氏 からは、Jenkinsのスレーブに関連した発表を行ってもらいました。
まず、スレーブ構築時のはまりどころとして、実行コマンドのパスなど環境が異なっている場合やセキュリティ関連に注意すべきということが説明されました。続いてINTEROP 2010のクラウドコンピューティングコンペティションでDeNA賞を受賞した、Hadoopと組み合わせてJenkinsスレーブを100台以上に自動拡張するという事例が紹介されました。
藤川氏の発表の通り、Jenkinsでは様々な方法で容易にスレーブを構築できます。マスターとなるマシンに負荷がかかり過ぎている場合や複数の異なるビルド環境を用意する必要がある場合など、Jenkinsを本格的に運用される方はスレーブを用意することも検討してはいかがでしょうか。
Jenkinsでリグレッションを起こす方法
最後は、山本氏 からJenkins利用時のリグレッションに関する考察を話していただきました。
山本氏が携わっているTwitter4Jの開発では、Twitter APIの仕様変更に伴った修正の際にリグレッションを起こしてしまったそうです。その反省を踏まえて、どのビルドからテストが失敗したのかも合わせてテスト結果を確認する、実行済みテストケース数やコードカバレッジの遷移から不吉な兆候を検出するといった点を意識し始めたということでした。
Jenkinsでは過去のビルド情報を保存しておくことにより、テスト結果やカバレッジの遷移を時系列なデータとして表示することができます。この時系列データを分析することで、単独のビルド結果だけでは分からないプロジェクト全体の傾向を把握することができるでしょう。
最後に
詳細はまだ未定ですが、次回Jenkins勉強会は5月頃を予定してます。今回はJavaプロジェクトでの事例をテーマに取り上げましたが、次回からは「LL言語でのJenkins運用事例」や「Jenkinsプラグインの開発」「 初心者のためのJenkins導入講座」といったテーマでの開催も考えています。
皆様からの意見も取り入れていきたいので、本勉強会で取り上げてもらいたい内容をお持ちの方はメーリングリスト に参加して投稿していただければ幸いです。
