Jenkins ユーザ・カンファレンス 2012 東京 に行ってきた！！
jenkins!!
ノベルティもたくさん
こんな感じの広い講堂でやりました。
本体サイト
» Jenkins ユーザ・カンファレンス 2012 東京 日本Jenkinsユーザ会
タイムテーブル
» Jenkins ユーザ・カンファレンス 2012 東京 – セッション 日本Jenkinsユーザ会
自分が見たセッションは
- Jenkinsプロジェクト現状報告とこれから
- SIerのJenkins事情 〜CI実践プロジェクト事例から超大規模プロジェクトの活用事例まで〜
- 飛行機を飛ばしながら直す方法教えます：JenkinsとGerritによる継続的デプロイメントの実践
- Jenkins に XFD を追加してみると？
- 開発者とディレクターの視点を変えていく方法
夕方頃にはお腹いっぱいでしたね。
ということでメモ
■Jenkins勉強会 ●Jenkinsプロジェクト現状報告とこれから ・JenkinsのUIめっちゃ改善してるから使ってね ・Rubyでプラグインを開発できるようにしました ・JenkinsHiveを使うとgithubにあるプロジェクトに対して無料でJenkinsを仕様できる ●SlerのJenkins事情〜CI実践プロジェクト事例から超大規模プロジェクトの活用事例まで〜 ・NTTDATAさん ・オライリーじゃない方のJenkins本の人らしい ・自動ビルド ・静的コード解析 ・自動テスト ・カバレッジ ・自動デブロイ ・規模計測 ・品質向上 ・自動テストの繰り返し、品質維持 ・自動化で作業ミスをなくす ・属人性をなくす ・ビルド職人に任せていると、その人を捕まえることとが難しかったり、他人がやって失敗したりする ・コスト削減 ・バグの早期発見で手戻りを最小化 ・自動化は作業コストを抑える ・プロジェクトの見える化 ・解析結果、テスト結果をレポート出力する ・SDワークベンチという社内ブランドとして展開 ・Jenkins+Plugin ・利用マニュアル→が本になった ・セミナー・ハンズオン ・QAsupport ・導入コンサル ・導入事例A ・長期の追加開発案件 ・Java、ウォーターフォール ・導入事例をつくって見たかった、そのテストケースとして行った ・自動化したことによってお客さんからも喜ばれた ・短期間リリースなのに品質の担保 ・仕組みが見えやすいようになっていた ・定常業務とは分離して行なっていた ・Jenkinsが勝手にSVNをCheakoutして解析 ・JDKのバージョンが合わなかったのでジョブ単位でヴァージョンを分けた ・Seleniumでブラウザテストを自動化 ・自動化の範囲はクリティカルな部分、インパクトの大きな部分 ・結果のレポート共有 ・品質管理チームがJenkinsを運営してる ・基本はWebページを見る ・導入事例K ・Java, ウォーターフォール、120人で開発 ・Nexus＋Mavenでライブラリの共有・管理を効率化した ・Jenkinsでデブロイ用のジョブを作成 ・効果 ・開発速度向上 ・１日100近くのデブロイ時間が減り、結果開発に集中できた ・導入事例B ・指原？ ・プロジェクト計画〜製造 ・結合テスト ・ビルドスクリプトをJenkins用にカスタマイズした ・Jenkinsは指揮者 ・デプロイは定時デプロイ ・1日4回 ・間に合わなかったら次に回される ・Jenkinsの与えたインパクト ・ビルド作業の効率化 ・多数のマシンへのデプロイを制御 ・作業待ち時間が大幅に削減 ・カナリアリリース ・一部のユーザーにだけリリースを行い、良かったらリリースを行う ・貸出返却？ ・凍結したリポジトリに対して、変更したい内容があったら貸出して修正、修正が正しかったら返却処理が行われる、そんなん ・変な修正が行われないかを防ぐため ・ただめっちゃ時間かかる！！ ・1000規模のプロジェクトでも、不正だエラーは2件しかなかった、結果やめた ・まとめ ・開発スピードが上がる！ ・導入は目的に合わせて模索していこう！ ●飛行機を飛ばしながら直す方法教えます ・Puppertを用いたJenkinsのインストラクトはじめるぜ！ ・Lookoutという会社に務めているお！ ・僕外人だお！ ・Androidはセキュリティがくそだよね！ ・それはともかく継続的デプロイメントの話 ・ワンクリックでリリースできてしまうが、リリースを早くすることが全てじゃない ・間違いがあったらそれだけで何万、何十万の顧客が迷惑を被る ・受け入れテストを自動化するってことはQAチームがいらなくなるってことじゃないだ ・バグはできるだけ早期で見つけたほうが、下流でみつけるよりもコストがかからないよ ・まとめると、早く、そして安全だという確信を持つことが大切 ・デプロイ後はユーザーからのフィードバックの仕組みも自動化しておくべき ・それが継続的デプロイメントの鍵なんだ ・うちではSVNベースのリリースプロセスを構築している ・ブランチを切って10~18日様子を見て問題なかったらリリースする ・コードレビューは対面式だとトラックできなくて不便 ・Jenkinsの導入 ・（悲しんでいる猫） ・一日平均68コミットあるがそのうち62％のコミットがスリップ（延期、中止）する ・バグがあるのにいつ修正できるのかわからない状況は不都合だ ・開発を続けながらそのプロセスを改善していく必要があった ・これまではビルドに失敗しても個人が頑張って復旧する必要があった、そしてそのフィードバックもない ・Jenkinsを導入すればフィードバックがある ・自動化はそれを導入して終わりでなく、継続して改善していく仕組みを提供する、より良いツールの導入によって ・SVNやーめた ・実はスキジャナイんだよね ・Gerritが対応してないし ・Gitに決めたよ ・Gitの登場 ・チームや個人にコミットやマージの責任を持たせるようにした ・GitとGerritを導入することで（SVN的な）集中的なオペレーションを避ける事ができる ・開発を分散化させることでコラボレーションが可能になった ・Gerritは他のディベロッパーがレビューすることを可能にする ・JenkinsのGerritプラギンがあり、連携している ・自動でコミット時にコミットレビュー要員に通知を送ることが可能 ・upstreamにpushされる if テストが通る && 他人からのコードレビューでOKがでる ・DEMO ・だめコードをJenkinsに上げる→怒られる→ごめんとコメントして再びテスト→テスト通った！けどレビュー待ち→「OK、YOUR CODE IS VERY GREAT WORK!!（問題ないらしい）」→中央ブランチにマージされた（このへんはGitを運用する際には色んなフローがあるね） ・こういった運用ルールを一度つくるのは大変そうだけどGerritを使えばだいたい自動化できた簡単だよ！ ・Jenkinsの問題 ・jenkinsだけで運用すると後々問題がおきるかもしれない、 ・ユニットテストだけでなく、使用環境でのテストもしよう ・SeleniumとかJazz（？）とかでさ ・ここまで自動化するとだいぶスケーラブルになるね ・スタートアップとしてはこのへんの自動化に腐心しているよ ・手動と自動化の混在 ・自動化プロセスの中にコードレビューなどの人間系の概念が取り込まれている ・自動でやってくれるロボットも大量にほしいね ・ディベロッパー個人が任意のビルドを任意の環境にGerritやPuppertをつかてデプロイして確認することができる ・継続的デプロイは導入したらそれで終わりではない ・今後の課題 ・自動的にロールバックする仕組みがない ・フィードバックの仕組みもだめだった報告だけでなく「いいね！」的なやつがほしい ・SeleniumやAndroidのエミュレートされた環境でのテストは行なっているが、実際にプロダクトでのテスト環境がない ・あとテストが遅いのも課題 ・並列化しても一度に15分かかる ・本番環境で問題があったときにデブロイのために15分も待たされるってことだからね！！！ ・これはビジネス的にクリティカルなに遅い！ ・成果 ・自動化の結果デプロイメントの失敗は2%にまで減った ・スリップは3%にまで減った ・イテレーションのサイクルも短くなった ・（大喜びする猫） ・Q＆A Q. コードレビューを導入しているそうですが、それによって開発が停滞することはないですか？ A. （開発の速い）上級者の方ではなく勉強中のビギナーたちに押し付けてるから大丈夫さ（え Q. 実機でのテスト環境が不足しているという話でしたが何か今後導入するためのヒントのようなものはないですか？ A. 残念ながらその回答に対する銀の弾丸はなく手探りでがんばっていくしかないぜ。 Q. Rubyはマイグレーションしてると思いますが、ロールバックなど導入してトランザクションさせると顧客のデータなどに問題が発生しませんか？もしくはデータベーステストのベストプラクティスは？ A. マイグレーションに関わる部分はできるだけ頻度を少なくしている。テストに関係するデータは少ないはずなので人間の目で確認するしかないんじゃないかな？ Q. Gerritを使う時のユーザーは統一しているか？それとも複数のユーザーで管理しているのか？ A. Jenkinsはひとつのユーザーで管理している。ただコミットユーザーとかの情報は見れるようになっているよ。 ●JenkinsにXFDを追加してみると？ ・普段はスクラム道場とか ・今日はeXtreme Feedback Device(XDF)の話 ・資料共有されるからあまりめもらない ・あんどん知ってるって聞いて会場の半分くらい手をあげて引いた ・引っ張ると工場の全行程が止まるらしい（社会でやったような？ ●開発ディレクターの視点を変えていく方法 ・Jenkinsを導入していく時の戦略 ・GREEでの開発スタイル ・Jenkins導入前 ・iOSの場合 ・ディレクターがエンジニアに依頼してビルド→デザイナーがレビュー ・ディレクターとデザイナーでレビューしているバージョンが違ったり ・導入前の問題 ・作業の属人化 ・成果物の管理 ・残課題管理が手薄 ・JIRA使ってるお！ ・Jenkins導入後 ・JIRA＋Jenkinsのコンボ ・Jenkinsでビルドに責任を持たせる＋JIRAでIssueを管理 ・導入のポイント１ ・早期なメリットを実感できること ・ディレクターやデザイナーはが実感できるメリットを享受させる ・Jenkinsなら開発、ステージング、本番、リリースなどの欲しいバージョンのビルドをボタン一発で作成できる ・社内ベータなどを配布しやすい ・導入のポイント２ ・迅速なsupportを行う ・専属が必要じゃない？ ・一人でJenkinsSupportを行っていると破綻するのでやっぱり専属の人を用意していた ・JenkinsMLやチャットを用意していた ・過去事例についてもまとめていた ・さらなる導入 ・単体テスト、テストカバレッジ、静的解析、パフォーマンス調査… ・見える化しても活かされない場合は多かった ・あるべき論、精神論では変われない→ちゃんと仕組み化、制度化しないといけない ・改善のポイント ・制度化する ・問題 ・UnitTestの時間がかかりすぎてリリースが遅れる（許せるのは数分以内） ・jenkinsのスレーブを増やすとか ・リリースも仕組み化する ・テスト通ってないなら通さないなどの当たり前のものから ・パフォーマンスが半分になったらリリースできないとか ・コピペさせない仕組みをつくるとか ・コードの品質は時間とともに自然に低下するもの ・精神論だけでいいの？制度化しよう ・まとめ ・田中社長のコードもすごい汚かったけどJenkinsで指標を取って悪いことを証明してリファクタリングしたよ！
手抜きです。すいません。
以下感想
自動化ってここまで進んでいるのか！というのが素直に感動したことであり、これを導入できてない状態は素直に遅れているんだと思いました。
今回見た企業はほとんどが大企業でしたが、大企業だから管理と自動化をする必要があるわけでないので、小さいチームでもすぐにでも導入するべきだなと、むしろすぐ導入できると感じました。
GREEに関しても大抵が1〜3人チームくらいだと思うけどちゃんと導入して成果を上げているようだし、自社にもはやく適用したいなと。
また導入する前は低かったテストのカバレッジが導入して分析レポートが生成されるようになってから、カバレッジが上がっていったらしいので、それを見てもはやく自動化して自動テストを行う環境を整えてやるべきだなと思います。
やっぱりやった成果がそのまま数字やグラフになるのとならないのとでは効果が違うということでしょう。
Jenkinsは色んな言語をsupportしている（というか言語に依存しないで構築できるように配慮されている）ので元がJavaだってことは結構障壁にならないかなと。
Rubyでプラグインも書けるようですし、本格的に使っていきたいと思いました。
