Jenkinsユーザカンファレンスに行ってきた
1/11(日)に市ヶ谷の法政大学で行われたJenkinsユーザカンファレンスに行ってきました。
聴講したセッション
時間を1時間間違えてて、keynoteはほとんど聞けなかったので割愛。
はてなにおける継続的デプロイメントの現状と Docker の導入
- 株式会社はてな 信岡裕也 (@nobuoka)
はてなでは はてなブックマーク の開発や ジャンプルーキー という集英社がやっているサービスの開発を担当されているそうです。
Agenda
- はてなのサービス開発とJenkins
- ジャンプルーキーの開発フローとJenkins
- Dockerコンテナによる確認環境とJenkins
はてなのサービス開発とJenkins
はてなブックマーク
- テスト実行、静的ファイル生成、デプロイ等でJenkinsを活用
Mackerel
- Scalaなので、コンパイルとか、テストとかをJenkinsでやってる
- hakobeさんの資料が参考になる
各サービスとJenkins
- それぞれのサービスでJenkinsを活用している
- 一昔前は master/slave 構成のJenkinsを1組用意して全サービスで運用していた
- ライブラリの違いや、Jenkinsやプラグインのバージョン差異などで、トラブルが発生するようになったので、最近ではサービス毎にJenkinsを分けて運用している
なんのためにJenkins??
- ソフトウェア進化を継続するため
- テスト、ビルド、デプロイ
- 意識しなくてもテストが実行される環境を作るため
- 手順の自動化
- 特にテストは大事
- CIサーバ上に本番相当の環境を用意して実行
Jenkinsサーバ自体の管理
- Chefを使ってる
- 理由: 本番サーバもChefで構築しているから
ちなみに、一休ではJenkinsサーバの管理は手動。。。。イケてない部分ですね。
Jenkins使用の方針
- 設定を複雑にしない
- 秘伝のタレ状態を防ぐ
- だんだん設定が複雑化していくのは、めっちゃよく分かる
- Jenkinsジョブではシェルを実行するだけにしといて、シェルの内容はリポジトリに入れる とか
スマホとJenkins
- メモれなかった。。。
ジャンプルーキーの開発プロセスとJenkins
- 漫画家の卵的なユーザがマンガを投稿できて、エンドユーザはそれをタダで読めるサービス
- 開発・運用は「はてな」が担当
- ディレクター: 1人
- デザイナー: 1名
- エンジニア: 数名
最近のはてなでの開発・運用を踏襲・改善
ビルド・デプロイ
- gulp(node.js)
- Capistrano3(ruby)
- GHE
- Jenkins
-
- はてなグループ
- Slack
- Trello
プロセス
- スクラム(1splint 2week)
- リリースは毎週
- 自社サービスじゃないので
- ただ、masterは常にリリース出来る状態を保つようにしている
ブランチ戦略
- Git-flowに沿っている
- master / staging / devel の3ブランチ運用
pull request
- 開発中に作るかどうかは任意
- WIPを義務付けてはいない
- テスト結果を可視化
- pull request builderプラグイン?
- 失敗時にはチャット(Slack)に通知
- 開発中に作るかどうかは任意
良いところ
- push都度自動でテスト実行
- 失敗時の通知が来る
- ファイルの変更結果をコミット
- コマンド1つで確認用環境にデプロイできる
悪いところ
- 失敗が続くと慣れてしまう(オオカミ少年問題)
- ファイル変更とテスト実行が同じShellになってて管理しづらい
Staging/Production のデプロイ自動化はまだできていない
Jenkins Workflow Plugin
- イケてそうなので、試してみたいがまだできてない
Docker コンテナと開発環境
開発中の機能(branch)を自分以外のメンバーに公開したい
- ex. ブランチ名をサブドメインにして公開する
今まではNginxでブランチとポート番号を紐付けてProxyしてた
- ブランチとポート番号の管理がめんどい
- ライブラリを共有するので、ツラいときがある
そこでDocker
- 開発用サーバで複数のDockerコンテナを起動
- 別ポート番号を使用
- ポート番号の解決にはDockerAPIを使用
- ブランチからイメージをビルドするときにブランチ名に対応したタグをイメージにつける
- ホスト名からブランチ名を抽出
- DockerAPIにより、対応するタグ名のイメージのコンテナを探す
Jenkins上でのビルド・デプロイ
- 手動でブランチ名を指定してデプロイ
- ここも自動化したいところ
開発用サーバにJenkins
- CIサーバ上にコンテナが複数立ち上がってるという意味
- キャッシュが効いたり、いろいろいいことがある
クックパッドにおけるJenkinsの活用
- クックパッド株式会社 高井直人
- クックパッド技術部高井さんのセッション
master/slave
- サーバ構成管理はpuppet/Itamae
- クラウドとオンプレ
ラベルでノードを管理
- ラベルはカオスになりやすいが、頑張っている
ci-slave-ruby
- ci-slave-android/ios
- オフィスに置いてあるサーバ
- Androidは実機でテスト(サーバにUSBでぶら下がっている)
なぜ、CIしているのか
- 毎日の料理を楽しみにしたくてやってる
- いち早く、ユーザに価値を届けるため
- 要はリーン・スタートアップでいうMVPを可能な限り早く回すため
CIで守るべき価値
- 意図しない変更を予防できる
- 再現可能で自動化されている
- リソースや情報を集約できる
意図しない変更を予防できる
- ターンアラウンドを短くする
- すぐに失敗を伝える
- 不具合を放置させない
- 開発者は十分に傲慢なので、10分でイライラして、20分でキレる
ターンアラウンドを短くできる
- マルチプロセス化
- 分散化
- remote_spec
- rrrspec
- AWSスポットインスタンスを活用
- プロセス停止からの自動復帰
- 失敗したテストの自動再実行
- テスト実行順序の最適化
- 長時間かかるテストの投機的実行
- オープンソース
これで10分以内をキープしている
すぐに失敗を伝える
- 単に失敗を通知するだけでは、誰も見ない
- マジであるある。。
- jenkins-hipchat-publisher
- その場で通知しないと、すぐに風化して「あ〜、あれはたまにコケるんだよね」といって放置することにつながる
- その場で処理・対応することが大事
不具合を放置させない
- 偽陽性を避ける
- 偽陽性があると、エラーを気にしなくなってしまったり、本物のエラーを見逃してしまうリスクが高まる
- まじであるある
- CIで稀に失敗してしまうテストへの対処法が参考になる
- 全員がコードに対してオーナーシップを持つ
- ソースコードを共同所有する
再現可能で自動化されている
- マーティン・ファウラーの継続的デリバリー
- CIでの自動化
- アセットの生成と管理、テスト、デプロイ、通知
リソースや情報を集約できる
- メモれなかった。。
CIの価値を守る
- 意図しない変更を予防できる
- 再現可能で自動化されている
- リソースや情報を集約できる
コレが出来てないと、CIの価値が低下する
所感
はてな
- CIサーバの構成管理はやはりChef/Puppet/Ansibleなどを使うべき
- 一休ではまだできていない
- pull request時点でテストが走るのはやはり良い
- 一休ではUTが少ないのと、E2Eテストに少し時間がかかってしまうので、いまはやってない
- Dockerを使ってCIサーバ上にブランチ毎にコンテナを立ち上げて、確認用環境を作る
- すごく良さそうなので、試してみることにする
Cookpad
- 偽陽性を避ける、再現可能で自動化されてる など、散らかりがちな部分についての対応をしっかりされていて、さすがはCookpadさんだな、と感じた
- 全員がコードに対するオーナーシップを持つ、失敗したらすぐに対応するような通知や文化作りなど、組織・文化についても重要な部分だと再認識した
全体
- 2つしかセッションは聞いていませんが、TwitterのTLなど見てても、すでにJenkinsを導入していて、その上で発生する課題についてこう解決した、という内容が多かった気がしました
- 基本的にはJenkinsで テスト , st/productionへのデプロイ などを行っていて、+αとして、Dockerを使って特定ブランチをCIサーバ上にデプロイしたり、Chefを使った環境構築など、単純なデリバリーの道具からもう一歩先へ進んだ運用の事例紹介が多かったです
- 「Windowsはしんどい」という話がちらほら聞こえる中で、一休での取組みももう少し洗練して、活用事例として話せるレベルにしたいです
- Dockerについては「はてな」の事例が非常に参考になって、改めて開発基盤・CI周りでのDockerの重要性を再認識したので、3月までに今のミッションとして掲げている「Dockerを使った開発基盤の構築」を進めていこうと思いました
- あと、重要なこととして、1年前の我々からすると少しはモダンにやれてる実感が湧きました。自分達の取組みがそんなに間違っていないんだ、とちょっと自信も持てたので、これからも前進を続けていきます
- Jenkinsユーザカンファレンス2016があれば、その時にはスピーカーとして参加したいです!
運営について
まず、このような大きなイベントを企画・運営されたスタッフの方と、良い発表をしてくださったスピーカーの方々に御礼申し上げます。楽しい企画をありがとうございました! イベントをよりよくするために、参加していて感じた改善点をいくつか。
- セッションの始まりと終わりは運営スタッフによる一言があると、スピーカーの方は話をはじめやすいと思いました
- 質問によって意識が分断されてしまうのと、話がブレるので質疑応答などはセッションの最後にまとめてするようにしてほしいな、と思いました