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 >

  1. はてなのサービス開発とJenkins
  2. ジャンプルーキーの開発フローとJenkins
  3. 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万ダウンロード

開発規模と環境

  • 開発・運用:はてな
    - ディレクター1人、デザイナ1人
    - エンジニア数名(開発・運用)
    - 最近のはてなでの開発・運用を踏襲/改善

  • サーバサイド

    • 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での自動化

    • テストの自動化
    • アセットの生成と管理
  • 1日あたり10デプロイくらい

  • デプロイはhubot経由で

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

  • アセットの生成と管理

    • コンパイルはrrrspecで実施している
  • 静的解析

  • 記録と可視化

    • GrowthForecastでsuccess rateなどを管理

質疑応答

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

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

< Agenda >

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

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

  • 女性向け恋愛ソーシャルゲームの開発

    • 9コンテンツ/40サイトを自社運用
    • イベントなどで急増するアクセス
    • chefまわりは以前の発表がある。「slideshare autoscale ゲーム」で検索
  • 構成管理ツールだけに頼ってた時の課題

    • コードの複雑化
    • Cookbook同士が疎結合になってない / 自動化できないので漏れ発生
    • 実行結果を追跡しづらい
  • Provisioning Toolchainでサーバ構築を概念化

    • Bootstrapping
    • Configuration
    • Orchestration

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

  1. Bootstrapping

    • OSインストールとサーバ起動
  2. Configuration

    • ミドルウェアの設定
    • サーバの役割に基づいた設定
  3. Orchestartion

    • GlusterFSのClusterに追加
    • zabbix-agentの起動
    • jeninsからソースコードデプロイ
  4. 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にほとんど仕込んでいるので最新のコードを引っ張ってくるのみで5分くらい。
  • 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から勉強したい人はこちらから。
12436288584_94d6bc46d2_b.jpg
GitHubでチーム開発なんて考えだすと、commitやpushだけではレビューをする時にもどかしさを感じることがあるかと思います。 GitHubやGitコマンドは使ったことあるけど、Pull Requestは使ったことない。という人向けに簡単に使い方をメモしておきます。 GitHubの基本的な使い方から学びたい場合は…

Jenkins実践入門 ~ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)
佐藤 聖規 和田 貴久 河村 雅人 米沢 弘樹 山岸 啓
技術評論社
売り上げランキング: 32,766
チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)
池田 尚史 藤倉 和明 井上 史彰
技術評論社
売り上げランキング: 5,606

 シェアして頂けると嬉しいです

参考になったという方がいれば是非お願いしますm(_ _ )m
モチベーション維持の観点で非常に励みになります。