第二回Jenkins勉強会でした発表です

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

2. Hudsonの歴史 2004 個人的な余暇プロジェクトとして開始 オープンソース 徐々にSunの内部で使われだす 2008 正式に仕事の一部になった Sunでサポートなどを売り出す 2010/1 OracleがSunを買収 2010/4 Oracle退社

3. 余暇のプロジェクトなのか会社のものなのか 情報産業の企業の雇用契約 ジャイアニズム カリフォルニア州労働法2870条 従業員が自分の道具で自分の時間に作ったもので、 会社のビジネスと関係ないものなら、 従業員のもの どこまで僕個人のものでどこまで会社のものか不透明 ソースコードの一部には権利がありそうだ 名前は？

4. プロジェクトの運営の実態 僕個人+世界中の有志による運営 会社の正式プロジェクトといっても僕一人だけ Solaris, JBoss, GlassFishのようなモデルとは違う Oracle退社後は、Oracle社内にはノウハウはなくなった 結果、2010/4からは本当にコミュニティプロジェクトとして運営されていた

5. 導火線: インフラに関する不満 2009/6 devリストでjava.netへの不満が爆発、JIRAを独自にホストする事に 2010/11/1 Oracleの技術者をjava.netプロジェクト共同管理者にしてほしいとの依頼 11/17 メーリングリストをGoogle Codeに移動するという提案がなされる 11/22 java.netのインフラ移行に伴ってHudsonプロジェクトがロックされる

6. 「商標は我々Oracleのものである」 11/23 リポジトリをGitHubへ移動する提案がなされ、広範に支持される 11/29 「Hudsonの商標は我々Oracleのものであり勝手にソースコードを移動してその名前を使うことは許されない」 後で分かるがこの時点では出願しただけ ( ﾟдﾟ) ﾎﾟｶｰﾝ

7. この時点での心配事 GitHub移行という直近の問題 自立性という中長期的な問題 開発者達に開発の事を決める自由自立が今後もあるのか 1%以下の貢献しかしていない参加者が拒否権を持っているというのは不自然ではないか

8. この時点でのコミュニティの反応 フォークすべき派 圧倒的多数派。でも、ただ血を見たい人達も OpenOffice等、他のプロジェクトの前例もある Oracleのコードの貢献は非常に少ない 妥協の道を探ろう派 少数派。でもプロジェクトの中核メンバーの多く フォークしてOracleが得するとは思えない。妥協の道があるはず

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

10. Oracleとの交渉 Oracleの要求 プロジェクトの統治モデルを成文化させたい 最高意思決定機関として３人の役員会を作る Oracleは改選なしの永久議席を持つ あらゆるコミットにはレビューを必須とする コードに変更を加える提案・承認プロセスを作る

11. 交渉決裂へ 交渉当事者間で信頼関係を作る事ができなかった Ted Farrell という人が… コミュニティはOracleの要求を全て受け入れる準備ができていた 「商標は我々Oracleのものである」

12. 2011/2 改名の提案 中核メンバーの心配事 交渉の経緯をみると、拒否権どころか一方的にプロジェクトの運営を変更する権限を振るうことになる 今後同じ事が起こらないという保障がない Hudsonという名前だけのためにそこまでするのか 現行のプロジェクト運営を継続するために、名前を変えるという提案を行った

13. 2011/2 改名の投票 提案内容 ３名の暫定役員会の選出 投票ルールなどを決めて次の役員を選出するまで Software Freedom Conservancyへの移管 プロジェクトの資産を管理する第三者機関を選ぶ 214 vs 14で改名が可決 投票権のない人達の間でも広範なサポートがあった Hudson->Jenkinsに名称変更

14. 改名後 開発者はほとんどJenkinsへ コア・プラグイン共に コアコミット 166 vs 40 Oracle Hudsonのプラグインコミットはほぼ0 メーリングリストの活動もJenkinsへ 563 vs 55 75%のユーザーは2011年中にJenkinsに移行する予定

15. まとめ プロジェクトの安定した運営を目指すために努力をしましたが、実りませんでした Hudson->Jenkinsに名前が変わりました コードベースは同じです 同じチームが引き続き開発しています これを機により成文化された安定運営を目指す努力をしています なのでJenkinsをよろしくお願いします

16. Hudson->Jenkinsへのアップグレード ドロップイン互換 jenkins.warをhudson.warと名前を変えてdeployするだけ deb, rpmなどでは若干の作業が必要な場合も

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

18. 背景 多数のコンポーネントチーム Subversion+Ant 依存ライブラリはSubversionにコミット JAXP JAXB JAX-WS StAX SAAJ WSIT JSR-109

19. インテグレーション問題 全てのコンポーネントが同時に開発 チーム間のやりとりがある 下流チームのために上流に機能を追加 下流で発見されたバグの修正 インテグレートを効率化したい 爆弾ビルドがインテグレートされないように 定期的にインテグレートしたい 手動インテグレートを避けたい

20. Jenkinsによる自動インテグレーション CIビルドの下流にテストを接続した Unit test JAXB SQE test TCK test

21. Jenkinsによる自動インテグレーション テストにパスしたらプロモートする Promoted-buildsプラグイン Unit test JAXB SQE test TCK test

22. Jenkinsによる自動インテグレーション プロモートされたら結合テストをする 候補ビルドと下流の最新版とを合わせてビルド・テストする --- “bleeding edge test” JAX-WSソースコードをチェックアウト ビルド前にlib内のjarを候補で上書き <get>タスクを使っていたが、今ならcopy artifact plugin そのままビルドしてJAX-WSのテストを走らせる

23. Jenkinsによる自動インテグレーション 全部のテストを走らせるのは面倒なので一部だけ Unit test JAXB SQE test TCK test Bleeding edgeJAX-WS RI JAX-WS RI unit test

24. Jenkinsによる自動インテグレーション テストがパスしたら再プロモート Unit test JAXB SQE test TCK test Bleeding edgeJAX-WS RI JAX-WS RI unit test

25. Jenkinsによる自動インテグレーション 再プロモートされたら下流のSubversionリポジトリに自動コミット Antタスク どのpermalinkをダウンロードするかパラメタ化 download-jaxb-jenkins task commit-jaxb task

26. 恩恵 インテグレーション後の障害が減った 問題があるビルドはインテグレーションされないようになっている どのビルドがインテグレートされたか記録が残る 個人のlaptopでビルドされた野良ビルドはない fire-and-forget 上流開発者はバグ修正をコミットしたら次の仕事に掛かれる

27. 改善すべき点 インテグレーションが長い間失敗しても通知が上がらない ダイヤモンド依存関係問題

28. Jenkins浸透作戦 より多くの人に使ってもうらにはどうするか 特に部署を超えて トップダウンだとうまくいかなかった 相手が防衛的になりがち 説得する相手が増える 高尾山に登る代わりに富士登山になってしまう

29. ボトムアップ作戦 誰でも自由に使えるようにした 計算機は出してもらった 実際に手を動かしている人に見せる 自分がやったものを見せる 導入も手伝ってあげる 既成事実を先に作る

30. ボトムアップ作戦 チームからチームへと口伝てに広がっていく でも手助けしてあげないとやはり普及は遅い ある程度利用が大きくなるとマネージャにも話が通りやすくなる この時点で自立を促す その担当者が仲間になる 学習意欲の高い若者を丁稚として使う

31. まとめ 千里の道も一歩から 徐々に自動化を進めていく 大きな挑戦をしない ビルドは本業ではないので 仲間を増やす 大規模自動化の事例紹介 ビルドやテストだけ自動化して満足していませんか？