JJUG ナイトセミナ 「師走の Jenkins 祭り」に参加しました

2013/12/17(火) JJUG ナイトセミナ 「師走の Jenkins 祭り」に参加してきました。

DoorKeeper
http://jjug.doorkeeper.jp/events/7490

場所は日本オラクルさんです。
参加者は180人くらいでしょうか。

最近、仕事でJenkinsを使わざるを得ない立場になり、ちょうど良い機会、ということで参加しました。
以下、個人メモ。

---

■「Jenkins運用3年でわかったこと」
岡崎隆之氏 (@watermint / http://watermint.org/)


■@ITの記事を執筆
・継続的インテグレーションを始めるための基礎知識
　http://www.atmarkit.co.jp/ait/articles/1302/13/news030.html

■2011年
・マスターノードを１つ立ち上げた。
・iOS向けのビルドをやっていた。
・Jenkinsを入れる前はビルドも手作業だった。エンジニアが頼まれるたびにビルドを作って渡していた。
　→　エンジニアのところにタスクが集中し、ビルド依頼を受け取って渡す作業に忙殺される。
　→　Jenkinsを導入すると、そこを間に入ってやってくれるようになる。
・ビルドの仕方が秘伝のタレになっていたりで、Jenkinsに乗せるのが大変だった。
　→　最初に2ヶ月くらいはビルドが通らない。
・ビルドというわかりやすいところから導入して、社内でJenkinsの普及活動をした。
・この時代はJenkinsを知らない人も多くて、啓蒙して行かないとまずいな、と思った。
・Jenkinsをどこに立てようかと思って、リッチな環境がもらえなくて、非力なLinuxの仮想サーバでやってた。
　→　ビルドはスレーブサーバでやらせて、マスタサーバはビルドを監視するだけの構成とした。
　→　3年経って、今ふりかえって、この構成にして良かったと思っている。
・スレーブサーバを立てるとなると、Jenkinsを触らざるを得ない状況になる。
　→　みんながJenkinsを触るようになった。
　→　そうなると、ディスクが足りないとかの事象に遭遇するようになって、修正してもらえるように鳴った。


■2011年まとめ
(1) とにかくすぐわかるメリットを体感してもらう
　・大きな組織にJenkinsを適用しようとするほど、エンジニアでない人に「ボタン押せばビルドができるよ」ということから説明する。
　　→　失敗すると赤くなる、ということで、エンジニア以外の人にもメリットがわかりやすい。
　・使ってくれるユーザを増やす、育成する

(2) 使ってくれるユーザを増やす、育成する
　・やっぱ、使ってくれる人がいないと浸透しない。
　・スレーブを作るスクリーンショット付きの手順書を渡したりとか、ログを見てエラー直してあげたりとかして、育成した。


■2012年
・Master Nodeが3～10個くらいになって、自分でjenkins立てる人が増えた。
・半分くらいのプロダクトはjenkinsを使うようになった。
・2012年に大きかったのは、2011末にGithub Enterpriseを入れて、Jenkinsと連携して開発できるようになったこと。
・Githubで開発する場合は、パッチとどういう変更かの情報を一括で渡せるPull Requestが使える。
・Jenkinsを使ってGithubからPull Requestを送ると、JenkinsがPull Requestが正しいかをユニットテストしてくれる。
　→　それでテストが正しいかをJenkinsから通知する。
・簡単なテストはJenkinsの独立した環境で実行するようにした。
　→　忙しくなるとすごく効果が出た。
　→　いろんなPull Requestが来た時に、人手だと捌けないけど、これで行けるようになった。
・Jenkinsを開発以外にも導入するようにした。
　→　翻訳しないといけないものをスプレッドシートに書いてJenkinsに送ると、翻訳して返してくれるようにした。


■2012年まとめ
2012年はGithubも入ってきて、みんな工夫しはじめた。Pluginも多いので、いろんなことがサポートできる。

(1) なるべく多様なワークフローを許容する
(2) 事前説明を手厚く、サポートもしっかり



■2013年
・マスタノードは前年と同じくらいで、ジョブが倍増した。
・ほぼ新しいプロジェクトは、Jenkinsｗあらかじめ検討している。
・CIが何もない段階から、最初からテストをしよう、という風土ができた。最初から２年くらいかかった。
・浸透してきたとよくわかるのは、Jenkinsが落ちてるときに来るクレームがたくさんになったこと。
　→　いろんな人のワークフローに組み込まれているんだな、と思った。

■2013年は苦難の歴史
・事件簿をいくつか紹介する。

(1) 事件簿１：JenkinsからGithubへのDOS攻撃
・JenkinsがGithubをポーリングする設定にしたプロジェクトがあって、そのジョブをみんながコピーして使っていた。
　→　ジョブの数が増え、DOS攻撃のようになった。。。
・そのときはポーリングの感覚を調整して対応した。
・日々監視していくのが解決策の１つ。
・ジョブをスケジューリングする、というのをユーザに学んでもらわないといけない。
・ポーリングを短くしていた理由は、Github EnterpriseからJenkinsにフックを飛ばすのがわからなかったから。。。

(2) 事件簿２：バージョンに起因するバグ
・ある日、Jenkinsのバージョンを上げたら、GitからCloneできなくなった。
　→　GitのPluginが原因だった。泣きながらバージョン戻してみたりして解決した。
・Jenkinsをバージョンアップしたら、特定のジョブだけ見えなくなったことがあった。
・Rubyのpluginがおかしくて、依存性を正しく読み込めずRubyのプロジェクトがうまくロードされなかったのが原因。
　→　Pluginのバージョンをすこしづつ変えて対処した。


■2013年のまとめ
・チームごとの用件が多様化し、一元管理が難しくなってきた
　→　でも、禁止するとモチベーション下がるし、勝手にJenkinsを独自に立ち上げられたりするので、そうしないようにした。
　→　それでも多様性を失わない運用が必要


■2014年に何をしたいか
(1) JenkinsでJenkinsのCIをしたい
　・Infrastructures As a Code
　・Jenkinsのpluginのバージョンを上げても、Jenkinsでテストしてからリリースするようにしたい。
　・Vagrant + chefで試している。
　・うまく運用に乗ったらブログで公開したい。

(2) マスタをVagrantとかでバージョン管理した上で他のチームに引き渡すようにしたい。
　・チームの条件に応じていろんなバージョンを選択できるようにしたい。
　・Vagrantを組み合わせてチームごとのJenkinsを提供できるようにしたい。
―――

・３年経って、当たり前の進み方しかしない。
・現状の業務を止めずに変化を加えるには、年単位の時間が必要。
・良いツールがあると「全社で標準化しよう」という話が出るが、分割統治をして多様性を受け入れるのが大事だと思った。
・そうしないと反発を食らって使われなくなる。
・標準化してコストを下げるのではなく、多様性を受け入れて生産性を上げるのが良いのではないか。

―――
■質疑応答
Q1.
・Jenkins普及の専任部隊がいらなかったのは？

A1.
・専任にするほど大きな問題が起こってない。
・戦略的に生産性の基盤を変えよう、という話があれば専任もありかも。
・秘伝のタレを作ってる人は、CIには同意してもらえるけど、手を動かすとこまで手を貸してくれなかった。


Q2.
・多くの人がJenkinsを使い始めると、権限まわりはどうしたか。

A2.
・Jenkinsのユーザは、今は200人くらい。権限がフラットでもぎりぎり統治がとれてる人数。
・これからは、インスタンス単位で分割して他に影響がでないようにしたいと思っている。
・チームによって要件が違うので、適切なインスタンスを分割したいと思っている。


Q3.
・多様性を持たせて運用する、と言っていたが、ルールは決めたか。

A3.
・明確なルールは決めてない。
・pluginを入れるとか設定を変えるとかは、チャットで一言ください、としている。
・基本的に、これをインストールするの止めましょう、とはしていない。
・あと、アナウンスをしっかりしましょう、としている。
・サーバダウンとかアップデートとか、ノイズにならない程度にアナウンスするようにしている。


Q4.
・Jenkinsバージョンアップで動かなくなったと言っていたが、バージョンアップしたほうがいいのか。

A4.
・バージョンアップの動機はセキュリティだった。
・バージョンの差が離れすぎるとpluginのバージョン差が大きくて辛くなる。
・１ヶ月に１回くらいバージョンアップするようにしている。


Q5.
・Jenkinsの情報がなくて詰まっている。どこから情報を集めたのか。

A5.
・ググる。
・さっき述べた事件があったときは、JenkinsのJIRAで検索したりとかした。でも英語できないときついかも。
・Twitterでつぶやくと川口さんが拾ってくれたりとかしてもらった。
・Jenkins日本ユーザ会に入ってみて聞いてみるのが一番やりやすいかも。

---

Jenkinsにみる互換性を損なわないコードの保守テクニック
発表者 : 川口耕介氏 (@kohsukekawa / http://kohsuke.org/)

コードの互換性と進化の両立 from Kohsuke Kawaguchi

Jenkinsというよりも、Javaでライブラリを開発する際の黒魔術(？)についてがメインでした。
ここでは省略！

---

★感想：
私もどちらかと言えばJenkinsを導入する側なので、岡崎さんのお話は参考になりました。
まずはメリットを感じられるところから着手、標準化よりも多様化、教育や普及も大事、といったご意見はなるほどなぁ、と。

あと川口さんの講演は凄すぎて、ちょと俺のJavaレベルでは後半ついて行けなかった！
こーゆうスゲー人の話を聞くのは刺激的ですね。俺もあんなんなりたい。。。

勉強会関係者の皆様、ありがとうございました。