Jenkins勉強会第二回

©2010 CloudBees, Inc. All Rights Reserved


Jenkins名称変更に関する経緯川口耕介


2©2010 CloudBees, Inc. All Rights Reserved

Hudsonの歴史• 2004 個人的な余暇プロジェクトとして開始–オープンソース

• 徐々に Sunの内部で使われだす• 2008 正式に仕事の一部になった– Sunでサポートなどを売り出す

• 2010/1 Oracleが Sunを買収• 2010/4 Oracle退社



余暇のプロジェクトなのか会社のものなのか

• 情報産業の企業の雇用契約– ジャイアニズム

• カリフォルニア州労働法 2870条– 従業員が自分の道具で自分の時間に作ったもので、– 会社のビジネスと関係ないものなら、– 従業員のもの

• どこまで僕個人のものでどこまで会社のものか不透明– ソースコードの一部には権利がありそうだ– 名前は？



プロジェクトの運営の実態• 僕個人+世界中の有志による運営–会社の正式プロジェクトといっても僕一人だけ

– Solaris, JBoss, GlassFishのようなモデルとは違う

• Oracle退社後は、 Oracle社内にはノウハウはなくなった–結果、 2010/4からは本当にコミュニティプロジェクトとして運営されていた



導火線 : インフラに関する不満• 2009/6 devリストで java.netへの不満が爆発、 JIRAを独自にホストする事に

• 2010/11/1 Oracleの技術者を java.netプロジェクト共同管理者にしてほしいとの依頼

• 11/17 メーリングリストを Google Codeに移動するという提案がなされる

• 11/22 java.netのインフラ移行に伴って Hudsonプロジェクトがロックされる



「商標は我々 Oracleのものである」• 11/23 リポジトリを GitHubへ移動する提案がなされ、広範に支持される

• 11/29 「 Hudsonの商標は我々 Oracleのものであり勝手にソースコードを移動してその名前を使うことは許されない」–後で分かるがこの時点では出願しただけ

(　ﾟ д ﾟ )　ﾎﾟｶｰﾝ



この時点での心配事• GitHub移行という直近の問題• 自立性という中長期的な問題–開発者達に開発の事を決める自由自立が今後もあるのか

– 1%以下の貢献しかしていない参加者が拒否権を持っているというのは不自然ではないか



この時点でのコミュニティの反応• フォークすべき派–圧倒的多数派。でも、ただ血を見たい人達も

– OpenOffice等、他のプロジェクトの前例もある

– Oracleのコードの貢献は非常に少ない• 妥協の道を探ろう派–少数派。でもプロジェクトの中核メンバーの多く

–フォークして Oracleが得するとは思えない。妥協の道があるはず



2010/12-2011/2

• オフラインで Oracleと交渉• コミュニティの要求–商標を中立の第三者組織に移管してほしい– 合意の形成は貢献の度合いに基づくべきで拒否権は認められない



Oracleとの交渉• Oracleの要求–プロジェクトの統治モデルを成文化させたい

– 最高意思決定機関として３人の役員会を作る• Oracleは改選なしの永久議席を持つ

–あらゆるコミットにはレビューを必須とする

–コードに変更を加える提案・承認プロセスを作る



交渉決裂へ• 交渉当事者間で信頼関係を作る事ができなかった– Ted Farrell という人が…

• コミュニティは Oracleの要求を全て受け入れる準備ができていた

• 「商標は我々 Oracleのものである」



2011/2 改名の提案• 中核メンバーの心配事– 交渉の経緯をみると、拒否権どころか一方的にプロジェクトの運営を変更する権限を振るうことになる

–今後同じ事が起こらないという保障がない– Hudsonという名前だけのためにそこまでするのか

• 現行のプロジェクト運営を継続するために、名前を変えるという提案を行った



2011/2 改名の投票• 提案内容– ３名の暫定役員会の選出• 投票ルールなどを決めて次の役員を選出するまで

– Software Freedom Conservancyへの移管• プロジェクトの資産を管理する第三者機関を選ぶ

• 214 vs 14で改名が可決– 投票権のない人達の間でも広範なサポートがあった

• Hudson→Jenkinsに名称変更



改名後• 開発者はほとんど Jenkinsへ–コア・プラグイン共に• コアコミット 166 vs 40

– Oracle Hudsonのプラグインコミットはほぼ 0

• メーリングリストの活動も Jenkinsへ– 563 vs 55

• 75%のユーザーは 2011 年中に Jenkinsに移行する予定



まとめ• プロジェクトの安定した運営を目指すために努力をしましたが、実りませんでした

• Hudson→Jenkinsに名前が変わりました– コードベースは同じです

• 同じチームが引き続き開発しています• これを機により成文化された安定運営を目

指す努力をしています

• なので Jenkinsをよろしくお願いします



Hudson→Jenkinsへのアップグレード• ドロップイン互換– jenkins.warを hudson.warと名前を変えて deployするだけ

• deb, rpmなどでは若干の作業が必要な場合も



GlassFish開発における Jenkinsに利用川口耕介



背景• 多数のコンポーネントチーム

• Subversion+Ant–依存ライブラリは Subversionにコミット

JAXP

StAX

JAXB

SAAJ

JAX-WS

WSIT JSR-109



インテグレーション問題• 全てのコンポーネントが同時に開発• チーム間のやりとりがある–下流チームのために上流に機能を追加–下流で発見されたバグの修正

• インテグレートを効率化したい–爆弾ビルドがインテグレートされないように

– 定期的にインテグレートしたい–手動インテグレートを避けたい



Jenkinsによる自動インテグレーション• CIビルドの下流にテストを接続した

JAXB

Unit test

SQE test

TCK test



Jenkinsによる自動インテグレーション• テストにパスしたらプロモートする

• Promoted-buildsプラグイン

JAXB

Unit test

SQE test

TCK test



Jenkinsによる自動インテグレーション• プロモートされたら結合テストをする– 候補ビルドと下流の最新版とを合わせてビルド・テストする --- “bleeding edge test”

• JAX-WSソースコードをチェックアウト–ビルド前に lib内の jarを候補で上書き• <get> タスクを使っていたが、今なら copy

artifact plugin

–そのままビルドして JAX-WSのテストを走らせる



Jenkinsによる自動インテグレーション• 全部のテストを走らせるのは面倒なので一部だけ

JAXB

Unit test

SQE test

TCK test

Bleeding edge

JAX-WS RI

JAX-WS RIunit test



Jenkinsによる自動インテグレーション• テストがパスしたら再プロモート

JAXB

Unit test

SQE test

TCK test

Bleeding edge

JAX-WS RI

JAX-WS RIunit test



Jenkinsによる自動インテグレーション• 再プロモートされたら下流の

Subversionリポジトリに自動コミット– Ant タスク–どの permalinkをダウンロードするかパラメタ化

download-jaxb-jenkins task

commit-jaxbtask



恩恵• インテグレーション後の障害が減った–問題があるビルドはインテグレーションされないようになっている

• どのビルドがインテグレートされたか記録が残る–個人の laptopでビルドされた野良ビルドはない

• fire-and-forget– 上流開発者はバグ修正をコミットしたら次の仕事に掛かれる



改善すべき点• インテグレーションが長い間失敗しても

通知が上がらない• ダイヤモンド依存関係問題



Jenkins 浸透作戦• より多くの人に使ってもうらにはどうするか– 特に部署を超えて

• トップダウンだとうまくいかなかった– 相手が防衛的になりがち– 説得する相手が増える– 高尾山に登る代わりに富士登山になってしまう



ボトムアップ作戦• 誰でも自由に使えるようにした– 計算機は出してもらった

• 実際に手を動かしている人に見せる–自分がやったものを見せる–導入も手伝ってあげる

• 既成事実を先に作る



ボトムアップ作戦• チームからチームへと口伝てに広がっていく–でも手助けしてあげないとやはり普及は遅い

• ある程度利用が大きくなるとマネージャにも話が通りやすくなる–この時点で自立を促す–その担当者が仲間になる

• 学習意欲の高い若者を丁稚として使う



まとめ• 千里の道も一歩から–徐々に自動化を進めていく– 大きな挑戦をしない• ビルドは本業ではないので

– 仲間を増やす• 大規模自動化の事例紹介–ビルドやテストだけ自動化して満足していま

せんか？

Documents

Jenkins勉強会第二回