Jenkins ユーザ・カンファレンス 2015 東京に行ってきた #jenkinsja #juc2015
» Jenkins ユーザ・カンファレンス 2015 東京 日本Jenkinsユーザ会
2015年最初の課外活動は Jenkins 。connpass のリマインドメールに 13 時開始とあったので、13 時めがけて向かったら川口さんの基調講演は 12 時半からだったみたい。現地に着いてから気づいたんだけど、他にもそういう人多かったみたいで、少し開始時間を遅らせていたよう。おかげで基調講演も半分くらいは聞くことができた。
カンファレンスの最後にもお詫びをしていたし、こういう大規模なイベントだとなかなか運営も大変だと思いますね。運営の方々、お疲れ様でした。
全体の感想とか雰囲気とか
数年前に参加した Jenkins カンファレンスだと、まだ導入しているところの方が少なくて、どうしたら導入できますかみたいな話が中心だったと思う。けど今日参加してみて、既にそういうフェーズは過ぎて、みんな現場で Jenkins 使って CI はしているけど、より効果的なユースケースや現場での工夫を聞いてみたい、躓いたことなどを他の現場はどういう風に解決しているのか、そういったことを聞きに来てる人が多かったように思う。各セッションの質問でも、質問者が実際にどう運用しているのかのイメージがあった上で実際にどうしているのか、みたいな質問が多かった気がする。
それは、Jenkins 単体の話ではなく、Chef や Docker などといった他のツールと Jenkins を組み合わせて問題を解決している、といったセッションが多かったことからも特に感じた。あと、インフラ構築やオーケストレーション、プロビジョニングといったインフラの分野でも Jenkins を中心として、サーバ構築のツールチェインとして使われているのが面白かった。Infrastructure as a Code が、今はもう実際の現場で工夫して当たり前のように構築されているし、Jenkins がその一端を担っているということを実感できたカンファレンスだった。
「Jenkinsがシステムの中心になりつつある」 #jenkinsja
— Kohsuke Kawaguchi (@kohsukekawa) 2015, 1月 11参加したセッション
» Jenkins ユーザ・カンファレンス 2015 東京 – セッション/LT 日本Jenkinsユーザ会
- Jenkinsプロジェクトの現状とワークフロー
- はてなにおける継続的デプロイメントの現状と Docker の導入
- クックパッドにおけるJenkinsの活用
- 「Infrastructure as a CodeにおけるJenkinsの役割」 〜環境構築も継続的インテグレーションを行う時代です〜
- LT大会
以下、それぞれのセッションで気になったこと、いいなと思ったことやメモなど。
Jenkinsプロジェクトの現状とワークフロー
途中からの聴講だったので、興味深かったところを。
- Jenkins Workflow Plugin
- ビルドジョブが増えてくると、全体のワークフローを制御したくなる、複雑化
- 失敗した場合に最初からやり直しするのは大きな時間のロス
- ジョブの再利用
- 人の承認・判断やインタラクションが途中に入る
- これらの問題を解決するのに、Groovy による DSL でワークフローを記述できるように作られた新しいプラグイン
- チェックポイントからの再実行
- プログラムの制御構造を使ってワークフローを記述
- ジョブの実行途中に人間とのインタラクションもできるように
- 通常のフリースタイルビルドと同じように設定ができる
- ビルドスクリプトも GitHub などで管理し、Jenkins はスクリプトを実行するだけ
はてなにおける継続的デプロイメントの現状と Docker の導入
テストについて
- できるだけ本番に近い状態でテスト
- 開発者のテストはローカルで実施、めんどくさいのでどうしてもサボりがち
- 本番に近い状態のテストは CI サーバで担保
Jenkins の運用方針
- 設定を複雑にしない、秘伝のタレ化させない
- コマンド一つで処理を実行できるように、
/bin/bash ./script/jenkins.shみたいに実行 - 失敗時に Slack に通知などしているが、そのままだと慣れが出てくるので、XFD などを使う
Jenkins と GitHub
ジョブの実行結果、テストの実行結果を Pull Request の画面に通知することで、レビュアーが GH;E 上でテスト結果を確認できる
- コンフリクトが先にわかるのでコンフリクトの解消ミスなどを減らせる
- テスト失敗しているのにマージすることがないので、開発ブランチをリリース可能な状態に保てる
リリース
- staging ブランチへの Pull Request はコマンド一発で送れるように
- 本番リリース用の Pull Request には、そのリリースに含まれるコミットをまとめたリリースノートが自動で作られる
Docker のユースケース
- 開発した機能の確認のために、開発中の機能を簡単に確認できる環境をすぐ作れるように
- 無駄な手戻り、開発スピードの低下を防止
- 特に UI/UX などの確認
- ブランチ名に対応するドメインで環境をすぐ作ることで、チームメンバー、社外の関係者、リモートメンバーなどのために確認出来る環境を提供
Docker build について
- 普通に実行すると 34 分かかっていた
- キャッシュを活用することで、2 分程度に
- プロジェクト全体をコピーする前に初期化処理用のファイルだけを COPY する
クックパッドにおけるJenkinsの活用
- ふつうにしている
- なぜ CI しているのか
- 毎日の料理を楽しみに
- 改善サイクルを爆速で回したい
CI で守るべき価値
- 意図しない変更を予防できる
- ターンアラウンドを短くする
- すぐに失敗を伝える
- 不具合を放置させない
- 再現可能で自働化されている
- リソースや情報を集約できる
通知
- ただ通知するだけだと誰も見ない
- 5W1H が分かるような通知をチャットへ
- メンションを飛ばす
- 開発者が全員参加してるチャットルームへ通知する
- 成功ビルドを通知しない
不具合を放置させない
- 開発者の文化と規律
- コードの共同所有（Collective Ownership）
- 偽陽性、割れ窓理論
- 時間に依存するもの
- 組合せに依存するもの
- 性能に依存するもの
- エラーを気にしなくなってしまう
- 本物のエラーを見逃してしまう、モラル低下、凶悪犯罪の多発
- 最後に成功したビルドを繰り返し実行してみる
- 翌月初にシステム時間を設定して実行してみる
CI を何のためにするのか
- 継続的デリバリーをゴールにすると、わかりやすくなる
- 自動化とは「自働化」
- トヨタの例：トヨタ | トヨタ生産方式 | 自働化について
記録する
- GrowthForecast で CI の成功率を記録している
ふつうにしているとは
- やるべきことをやる
- 常にそうあるようにする
「Infrastructure as a CodeにおけるJenkinsの役割」 〜環境構築も継続的インテグレーションを行う時代です〜
全体的に、問題の洗い出し、解決アプローチの再定義、役割分担、方法論・技術、ソリューションと、それぞれのステップ一つ一つをきちんと構築して、チームとして行えていることが凄いと思ったし、素晴らしいと思った。見習いたい。
Chef で全体管理していた時の問題点
- レシピの複雑化
- Cookbook が密結合
- 冪等性が担保されなくなる
- Chef Server のSPOF、同時接続数問題
- 実行結果のトレーサビリティ、ログが散らばる
サーバ構築の再定義
- Provisioning Toolchain に沿って再定義し、役割の明確化を進めた
- Bootstrapping
- Configuration
- Orchestration
- それに加え、Releasealization（造語）を定義
- サービス提供のプロビジョニング
- Orchestration の処理内容をテスト
- Serverspec
サーバ構築における Jenkins の役割
- 全体の制御・統制を行う
- Chef の役割が明確化した
- Chef の実行ログが一元管理できた
実践編
スライドが公開されたらもう一度見たい。Serf の万能感が際立っていた。
