Jenkinsユーザ・カンファレンス2015東京に参加してきた

日本Jenkinsユーザ会主催のJenkinsユーザ・カンファレンス2015東京に参加してきましたので、そのメモです。登録人数は723人でした。400人くらい来てた(運営談)

< 概要 >

日時 2015/01/11 (日)
場所法政大学市ヶ谷キャンパス外濠校舎
セッション/LT

http://build-shokunin.org/juc2015/

< タイムテーブル >

12:10~13:00 基調講演
- Jenkinsプロジェクトの現状とワークフロー
13:30~14:20
- 組み込み環境でのJenkinsによる多段階CIシステムask the speaker(川口耕介)
- はてなにおける継続的デプロイメントの現状とDockerの導入
- JenkinsとSeleniumの活用事例：試験自動化のプロジェクトへの導入
14:30~15:20
- JenkinsとPuppet+ServerspecでインフラCI
- クックパッドにおけるJenkinsの活用
- Jenkinsを使ったコンシューマゲームでのデプロイとテスト
15:40~16:30
- 「Infrastructure as a CodeにおけるJenkinsの役割」〜環境構築も継続的インテグレーションを行う時代です〜
- Jenkins導入する本当の理由を考えてみた
- おばかXFDコンテスト
16:30~17:20 LT大会

基調講演 Jenkinsプロジェクトの現状とワークフロー

参加できず・・・

情報募集中

13:30~14:20 はてなにおける継続的デプロイメントの現状とDockerの導入

< Agenda >

はてなのサービス開発とJenkins
ジャンプルーキーの開発フローとJenkins
Dockerコンテナによる環境開発とJenkins

1. はてなのサービス開発とJenkins

利用しているサービスについて

ブックマーク・ブログなど
- Perlで書かれている。そのためコンパイルは不要。
- テストの実行や静的ファイル生成、デプロイなどでJenkinsを活用
Mackerel
- サーバ管理サービス
- Scaraで書かれている
- 過去のプレゼン資料がsperkerdockに上がっている

Jenkinsの活用方法について

各サービスとjenkins
- サービスごとにJenkinsを準備
- あるサービス用の変更による別のサービスのテストが動かなくなる
- 関係者が少ない方がメンテしやすい
なんのためのJenkins??
- ソフトウェア進化を継続するため
- 意識しなくてもテストが実行される環境
- 面倒な手順の自動化
特にテスト
- 開発は各自のマシンで
- 本番に近い環境でのテストの実行と自動化のためにJenkins
Jenkins自体の管理
- Chefで環境構築
- プロダクトの本番サーバも同じ
Jenkins使用の方針
- Jenkinsの設定を複雑にしない（秘伝のタレ問題）
- シェルスクリプトをリポジトリに入れてJenkinsから誰でも実行できるように
スマホアプリとJenkins
- AndroidはGradleが標準になり、ビルドとテストがしやすくなった
- Android emulater pluginを使用

2. ジャンプルーキーの開発フローとJenkins

少年ジャンプルーキーって？

2014年リリース
漫画投稿サービス
250万ダウンロード

開発規模と環境

開発・運用：はてな
-　ディレクター１人、デザイナ１人
-　エンジニア数名（開発・運用）
-　最近のはてなでの開発・運用を踏襲／改善
サーバサイド
- perl
- mysql
- redis
フロント
- htmlは生
- TypeScript -> JS -> minified JS(ビルドプロセスが必要（開発者の手元＋Jenkins))
- LESS -> CSS(ビルドプロセスが必要（開発者の手元＋Jenkins))
ビルドツールやデプロイツール
ビルドツール
- gulp(Node.jp)
- TS -> JSやLESS -> CSS
- JSテスト実行
- 静的ファイルにダイジェストハッシュ付与デプロイツール
- デプロイ：Capistrano3(Ruby)
- Github Enterprise

開発プロセス

開発に用いるツール
- 日記+Wiki
- Slack
- Trello
- Github Enterprise
- Jenkins
開発プロセス
- スクラム、2週間①スクリプト
- リリースは毎週。とはいえ常に最新をリリースできるようにはしておく。
ブランチモデル
- GitFlowに近い
- master / staging /devel / features
- 基本はdevelブランチから切る。緊急リリースはmaterからブランチを切る
- Pull Requestはとりあえず開発中でも上げておく(議論のため)

開発時のJenkins

Jenkinsでやっていること
- pushされるごとにライブラリ更新、JS minify
- pushされるごとにテストとを実行
- 動作確認のために開発用ホスト(doceker)にデプロイ
- Github Plugin + script/jenkins.sh
- GH;Eの通知はシェルスクリプト内
課題
- slackとGH;Eだけなので弱い？->XFD?
- GH;Eへの通知がビルド処理の中にある

その他

開発が完了したらコードレビュー(develブランチ)
- Pull Requestに残す
- レビュアにとってテスト結果がGH;Eで通ったかが確認できるのは楽
デプロイ
- 本番リリース用のpull requestを作成(devel -> staging -> prod)
- リリースチェックリストをpull request
今後
- Jenkins Workflow Plugin（scripted control flow、ユーザのインタラクション機能もある）を検討

3. Dockerコンテナによる環境開発とJenkins

背景と利用環境

開発した機能の確認が遅れると困る
- 無駄な手戻り
- 開発スピードの低下
- 特にUI/UX
目的
- 開発中の機能(develブランチにマージする前)の動作やUIを手軽に確認したい
Devhostは誰のため？
- 開発者以外のチームメンバー
- 社外のメンバー（ドメインを用意する必要性）
既存の方法
- 1ホストに複数環境をデプロイ
- Nginxでドメイン別にポート番号ごとに振り分け
- ポート管理が手間、ライブラリが共有・・・
DockerによるDevhost
- Proxy用Plackアプリケーション+DockerAPIでポート番号を解決
- ゲストは80番で待ち受け
- ブランチからイメージをビルドする際にタグを付けておき、ドメイン名からブランチ名を取得->APIを叩いて対応するタグのポート番号を取得

やっていること

課題と対策
- dockerイメージのビルドに時間がかかる
- Dockerイメージのビルドにキャッシュが効く（プロジェクト全体をコピーする前に初期化スクリプトを実行しておく）
Jenkins上でのビルドとデプロイ
- Jenkins上でdocker build、docker rm -f(同じブランチのコンテナを止める)、docker run
- 実際のコマンドはrakeタスクにしてある
- タグを認識して変換する必要がある
- ビルド開始方法は現在手動(ブランチ名はビルドパラメータで受け渡し)
なぜJenkinsでビルドするのか
- 同じ環境でビルド処理を行わせたい
今後
- develブランチの手動でプロ胃
- pull requestとの関連付けの強めたい（コメントから作成、マージ後に自動破棄）
その他
- faviconで確認環境と他の環境を視覚的に変える

質疑応答

dockerでコンテナを作った時のテストデータはどうしているのか？
- ->データベースは一つを共有。スキーマ変更もやっている。
Pull Request時に何をテストしているのか？
- ->マージ後のものをJenkinsで実行はしていない

14:30~15:20 クックパッドにおけるJenkinsの活用

はじめに

宣伝：クックパッドのプレミアム会員になろう。レシピ意外にもサービス色々あるよ。

Ruby 2.0 + Ruby on Rails 4.1
Amazon Web Service

難しい事はしていないので、シンプルに説明をしていく

クックパッドでのJenkinsの使用環境

※ jenkinsではなく「おむきんす」を使用している

マスタースレーブ構成
- Puppet / Itamae(独自:Lightweightなchefを目指す)
- クラウドとオンプレミス(MAC OS/IOS環境のビルドなど)管理
- ラベルでノードを管理
ci-slave-ruby
- AWS上で6ノード、夜間は2ノードに縮退
- rbenvを使用
- テストはrspec
ci-slave-docker
- microserviceを進めている背景
- Go + Docker Engine用のCI環境
- ビルド・テスト・レジストリ登録
- GitHub Enterpriseを使用
ci-slave-android/ios
- オフィスのサーバルーム
- Androidは実機、Xcodeのバージョン管理で苦慮

なぜCIをしているのか？

< ユーザの要求を手元に届けるまでのサイクルを圧倒的なスピードで回したい >

CIで守れる価値
1. 意図しない変更を予防
2. 再現可能で自動化されている
3. リソースや情報を集約できる

意図しない変更を予防

意図しない変更が起きた時に開発者がすぐ取り組む文化が必要。

CIツールの速度改善への取り組み
- マルチプロセス化 -> 分散化 -> rrrspec(開発者ブログ参照)
通知について
- Failしたらhipchatへ通知する
- その通知時にmentionも使っている
- 誰がどこを失敗させたのか
- HipChat Pluginではなくjenkins-hipchat-publisher（独自）を使用している。失敗時のメンションと成功ビルドを通知しない機能
偽陽性を避ける
- 時間に依存するもの
- 組み合わせに依存するもの
- 性能に依存するもの
偽陽性があると・・・
- エラーを気にしなくなってしまう
- 本物のエラーを見逃してしまう
偽陽性への対処
- 最後に成功したビルドを夜間に繰り返し実行してみる
- 翌月初にシステム時間を変更して実行してみる
- 失敗したテストを再実行してみる

再現可能で自動化されている

CIでの自動化
- テストの自動化
- アセットの生成と管理
１日あたり10デプロイくらい
デプロイはhubot経由で

リソースや情報を集約できる

アセットの生成と管理
- コンパイルはrrrspecで実施している
静的解析
記録と可視化
- GrowthForecastでsuccess rateなどを管理

質疑応答

デプロイが１日１０回というのはどの範囲？
- -> 全社でフロントだけでなくバッチなども含む

15:40~16:30「Infrastructure as a CodeにおけるJenkinsの役割」〜環境構築も継続的インテグレーションを行う時代です〜

< Agenda >

サーバ構築フローとJenkinsの役割
サーバ構築の実践例とCI環境

サーバ構築フローとJenkinsの役割

女性向け恋愛ソーシャルゲームの開発
- 9コンテンツ／40サイトを自社運用
- イベントなどで急増するアクセス
- chefまわりは以前の発表がある。「slideshare autoscale ゲーム」で検索
構成管理ツールだけに頼ってた時の課題
- コードの複雑化
- Cookbook同士が疎結合になってない / 自動化できないので漏れ発生
- 実行結果を追跡しづらい
Provisioning Toolchainでサーバ構築を概念化
- Bootstrapping
- Configuration
- Orchestration

各レイヤーでやっていること

Bootstrapping
- OSインストールとサーバ起動
Configuration
- ミドルウェアの設定
- サーバの役割に基づいた設定
Orchestartion
- GlusterFSのClusterに追加
- zabbix-agentの起動
- jeninsからソースコードデプロイ
Releasalization (独自)
- 外部サービスとの連携
- LBへの追加など
- 変なサーバを本番環境に入れないようにする

Jenkinsの役割

ソースコードのデプロイ管理
ユニットテスト
サーバ構築の全体管理(new)

構築管理の変化

chefのRoleをJenkinsにパラメータとして渡しJOBの条件分岐
Build Flow Pluginを使用して可視化

サーバ構築の実践例とCI環境

各レイヤーについて

configration
- chef-soloを使っている。jenkinsからknife soloを打つ。
- jenkinsでGUI化できて楽になった
- chef実行結果のログを集約
- jenkins + serf(Go言語製オーケストレーションツール)
- serf はnodeでやりたい処理を実行
- jenkinsはイベント検知(serf join)とビルド
orachestation
- configuration -> orchestrationの橋渡しもserf(+tag)
- serfのtagはRoleをjson形式で要約
- serf queryで成功/失敗の判断と処理中断
- SSHが必要ない
Releasalization
- orchestationの内容をテスト
- 問題なければLBに追加して本番に入るようにしている
- serverspec

課題と改善策

chefのテストが簡単に行えない問題
- まっさらな状態がすぐ作りたい
- serverspecですぐテストしたい
改善策
- dcoker + chef zero
- jenkins pullrequest builder plugin
- feature = role名
- chef repoをmount

冗長化
- serfで通知
- jenkins起動
- EIP変更
- heartbeatなどは使用していない。100台のclusterで2秒(?)

Jenkinsでやってみた結果

JenkinsでChefの役割をシンプルにできた
ビルドの使い方次第でレイヤーが明確化される
JOBのログが残る/可視化
Build Flowを途中で止められる/不完全なものを本番に入れない

質疑応答

Auto Scaleは全体でどのくらい時間かかる？
- 前は20分くらいかかってた。AWSはAMIにほとんど仕込んでいるので最新のコードを引っ張ってくるのみで５分くらい。
Jenkinsの冗長構成のデータ同期は？
- GlusterFSはうまくいかなかった。Lsyncdを検討。今は同じ設定にしている。
今後やりたいことは？
- Autoscaleをもっと早くしたい

16:30~17:20 LT大会

1. Jenkinsを使った継続的Webセキュリティテスト

セキュリティテスト(脆弱性)
継続的なセキュリティテストを実施すべき
vaddy
- 無料プランのみ、何度でも
- SQLインジェクション、XSS
- Jenkinsプラグイン提供中
MeetUp 2/19(木) 新宿(doorkeeper)

2. Jenkinsおじさん、お堅いメガバンクに就職

配布ソフト(有償)が参照するレポジトリにプッシュしている
知識がない人でも簡単に作業が出来るようになった

3. Jenkinsおじさんと楽しい連携ツールたち

slackでビルド結果の通知を行う
- Emojiで少し工夫
Gitlab
- MergeRequestでmasterにマージする前にビルド、静的解析、テスト
- GitLab MergeRequest Builder Plugin
deploygate
- iOS/Androidアプリのテスト版アプリの配信
- gradle-deploygate-plugin(proxy使えるようになった)

4. ゲーム業界の人がJenkinsさん3Dモデルで遊んでみた

3Dロゴが出た
3D空間に出してみたのデモ
実際の画面でみないとわからないでのメモ断念。高級感溢れるおじさん。増えるおじさん。爆発するおじさん。REST API経由で赤く光るJenkinsおじさん。

5. CI”じゃない方”のJenkins

パッチ処理
- 結果の履歴残る
- cronより柔軟
- ssh/scpも不要
多システムの連携
- APIあればコントロールできる
負荷テストツール
- インスタンス + jmeter

秘蔵のシェルスクリプトをJenkins登録して表に出そう。

プルリクとかGitHub Flowから勉強したい人はこちらから。

GitHubでPull Requestを使わないのはもったいないと思ったので簡単な使い方をメモしておく - ぽぽぽぽーんのネットワークとOSS

GitHubでチーム開発なんて考えだすと、commitやpushだけではレビューをする時にもどかしさを感じることがあるかと思います。 GitHubやGitコマンドは使ったことあるけど、Pull Requestは使ったことない。という人向けに簡単に使い方をメモしておきます。 GitHubの基本的な使い方から学びたい場合は…