日時 ：2015/01/11 (日)
場所：法政大学 市ヶ谷キャンパス 外濠校舎
主催：日本Jenkinsユーザ会
http://build-shokunin.org/juc2015/
概要
Jenkins自体の話ではなく、Jenkinsを利用した開発プロセスのモデル紹介が主だった。
ジョブを自動実行したり、リポジトリなどの外部サービスとの連携はプラグインなどでひと通り出来てしまう。
それらを利用してどのような開発フローを作成していくかが話題となっていた。
単体テスト、結合テスト用のビルド程度までしか自動化できていない自分としては非常に参考になった。
組み込み開発で結合テスト以降は実機操作が必要になると言う言い訳に甘んじているが、QA部隊へのリリースの自動化など、所属をまたぐ部分についても自動デプロイが出来ないか模索する必要がある。
また、12年新卒入社の方が3名も発表していたなど、登壇者の若さにも刺激を受けた。
参加者アンケート集計結果
使い始めて1年未満、プロジェクト数5未満が半数を占めていた。国内は普及が始まったという感じ。
海外はもっと利用されているよう。
Jenkinsプロジェクトの現状とワークフロー
川口耕介 (@kohsukekawa)
http://www.slideshare.net/kohsuke/jenkins-user-conference-2015
主にworkflow-pluguinの紹介。Groovyを利用して、1ジョブで継続的デリバリーを行うためのエンタープライズの各ステージのビルドを実現する。
その他Jenkinsの近況、DotCI、ファイル指紋追跡、JenkinsとDocker etc...
参考URL
workflow-plugin
DotCI
はてなにおける継続的デプロイメントの現状とDockerの導入
株式会社はてな 信岡 裕也 (@nobuoka)
http://www.slideshare.net/YuNobuoka/docker-43489941
はてな内の開発・リリースプロセスとJenkinsが担っている役割。
Jenkins、GitHub;Enterprise、Docker、Git-flowブランチモデルを利用したリリースプロセス。
JenkinsとPuppet+ServerspecでインフラCI
GMOペパボ株式会社 常松 伸哉 (@tnmt)
https://speakerdeck.com/tnmt/jenkins-puppet-serverspec-infra-ci
Jenkins、GitHub;Enterprise、Puppet、ServerSpec、Vagrant、Virtual Boxを利用したインフラ構築の継続的デリバリー
「Infrastructure as a CodeにおけるJenkinsの役割」 〜環境構築も継続的インテグレーションを行う時代です〜
株式会社サイバード 本田 恭(@Altsencturely)
株式会社サイバード 藤原 涼(@megadreams14)
https://drive.google.com/file/d/0Bywu6GCI_-U4WC02M3lZaE5XTjA/view
ソーシャルゲームのためのChefとJenkinsを利用したサーバ構築自動管理。
Provisioning Toolchainをベースに第4レイヤを追加して運用。
参考URL
サーバプロビジョニングのこれまでとこれから
Provisioning Toolchain by lee Thompson at Velocity 2010
LT
脆弱性検証の自動化、金融系内でのJenkins自動化、定常業務の自動化の話など。
発表メモ
前座資料・アンケート集計結果
参加者の使用言語はJavaが400人以上、PHP、Ruby、JavaScriptが200人以上、C/C++は150人弱と組み込み開発社は少ない印象。
アップデートを行なっている人は少ない #承認や関係者通知が面倒？
マシン利用台数は0-3台までが50%以上。川口さんによるとアメリカでは200台規模の案件もあるとのこと。
Jenkinsプロジェクトの現状とワークフロー
川口耕介 (@kohsukekawa)
最近のJenkinsについて。
前年比インストール数34%増加、ジョブの数も76%増加。ユーザーも増加しているし、１ユーザの利用方法を多様化している。
AWSやGoogleも利用している。TVにも出て認知度、重要度は大きくなっている。
プラグインの数も1000を突破した。
DotCI
DotCIとは
- GitHub専用のJenkinsディストロ
- １リポジトリ = １ジョブ
- .ci.yamlによるバージョン管理されて設定
- Docker
- バックエンドとしてMongoDB
UIリフレッシュ
見た目の刷新。レスポンシブデザイン
UI/UXのカイゼンをプライオリティ高くやっている
ファイル指紋によるファイルの追跡も行なっている。
ChefやPuppetの中に入って、ファイル指紋をえる
いつ、なにが、どこにデプロイされたのか？を知ることができる
Ansibleなどにも対応していきたい。
Dockerコンテナ内で使い捨てスレーブを走らせる
DOckerにJenkinsの公式イメージがあるので
Dokcer runするだけでJenkinsを立ち上げることもデキル。
ワークフロープラグイン
https://github.com/jenkinsci/workflow-plugin
https://github.com/jenkinsci/workflow-plugin/blob/master/TUTORIAL.md
DevからQA、Buisinessまで各工程のビルドを繋げたい
今までの、複数のジョブを作成しそれらをつなげるの、ではなく一つのジョブで実現する。
複雑な開発活動の指揮を簡単にJnekinsから行う
- 多段階の継続的デプロイメントパイプライン
- 一次サーバを活用したビルド
- 青緑デプロイメント＋自動コミット・アボート
- テストの並列実行と自動的sharering
サポートした処理の特徴
- 多段の処理を含む複雑なパイプライン
- ループや並列処理を含む非直線的な処理
- 再起動をまたぐ長時間ビルドのサポート
- 中断、確認、分岐などの人間との対話
- 一過性のエラーなどに便利な途中からの再開
- ジョブ間・組織間の処理の再利用
- 一箇所で処理を完結に記述
今までのリリース用ビルドはひとつひとつの工程をジョブにしてつないでいる。
ジョブが多くなりすぎり、（buildflow-pluginなどもあるが）つながりもよくわからない。
ワークフロープラグインを利用すればひとつのジョブで再現できる。
Groovyを利用して処理を記述することができる。
途中でスレーブが再起動などしても、中断処理から復帰することができる。
ワークフロープラグインではチェックポイントを設定することで、処理の途中から完結に復帰することができる。
ジョブの設定としては、ワークフロージョブとして設定する。
ジョブの中にパイプラインビューのようなステージングビューが表示されている。
- 複雑なリリース活動を簡潔に指揮、記述できる
- ひとつのジョブでDev、QA、デプロイまで開発工程の全てステージを記述
- GraoovyによるDSL
- JVMのロスや再起動に耐えるデザイン
- 拡張性も視野に入っている。Ansibleなどにも対応したい。
githubにDocker用のデモもある
https://github.com/jenkinsci/workflow-plugin/blob/master/demo/README.md
はてなにおける継続的デプロイメントの現状とDockerの導入
株式会社はてな 信岡 裕也 (@nobuoka)
http://www.slideshare.net/YuNobuoka/docker-43489941
12年入社。12-14年ははてブチームでアプリエンジニア
2014年は少年ジャンプルーキーというサービス開発
1.はてなのサービス開発とJenkins
はてブやブログは主にPerlで書かれている
コンパイルのプロセスは基本的に不要
テストの実行や静的ファイル生成デプロイなどでJenkinsを活用している
はてなブログの開発プロセスに関しては１４年に数回発表されている
各サービスとJenkins
それぞれのサービスでJenkinsを活用
最近はサービスごとにJenkinsを用意されている。サービスごとに環境が異なるため。
関係者が少ないほうがメンテナンスしやすい。
何のためのJenkinsか
ソフトウェア進化を継続するため
はてなダイアリーは１０年超、はてなブクマも１０年近くリリースしている
テスト、ビルド、デプロイのため
意識しなくてもテストが実行される環境である
面倒なデプロイ手順の自動化
特にテスト
本番に近い環境でのテスト実行、自動で全テスト実行。
Jenkinsの管理
ChefでJenkinsの環境を構築。（本番サーバもChefで実行）
Jenkins使用の方針
Jenkinsの設定を複雑にしないようにしている。
例えば、書士の内容はShellスクリプトファイルに記述してプロジェクトのリポジトリに入れている。
スマフォアプリとJenkins
Andoroidアプリ→Gradleが標準になり、ビルドやテストの自動化がしやすく
Jenkins上でのテスト実行はエミュレータープラグイン
iOSアプリなどはまだこれから。
少年ジャンプルーキー
漫画の投稿サービス。アプリは250万DL
開発。運用 はてな
ディレクターひとり、デザイナー一人。エンジニアは数名
最近のはてなでの開発・運用を強襲・カイゼン
サーバサイド：Perl
フロントエンド
HTMLはなま。TypeScript。LESS。
TypeScriptは開発者の手元＋Jenkinsでビルドしている。LESSは開発者の手元でビルド
ビルドツールやデプロイツール
ビルドツール：gulp(Node.js)
デプロイ：capistrano3(Ruby)
バージョン管理：Git(GitHubEnterprise)
開発ツール
はてグループ（内作ツール。日記＋Wikiシステム）
Slack, Trello, GitHub;Enterprise, Jenkins
開発プロセス
スクラム２週間１スプリント
リリースは毎週
ブランチモデル
Git-flowモデルの派生
master/staging/devel/develを切ってfeatureブランチ
develは常にデプロイできるように保つ
新機能開発プロセス
pull requestを作成
開発中に立てるかどうかは任意(コードレビューは必須）
開発中の様子が見えやすい
開発中のコードについて議論しやすい
Jenkinsの役割
- Pushされるごとにライブラリ更新 JS minigy
- Pushされるごとにテストの実行（失敗時はSlackなどに通知）
- 動作確認のために開発用ホストにデプロイ
- JenkinsのGitHub plugin/server hookを利用
- 処理内容はシェルスクリプトに記述
- GH;Eのコミットへの通知
- シェルスクリプトの中に通知
- Slackへの通知はSlackのIntegrations/JenkinsのSlack notification plugin
良い所
pushしたら自動でテスト実行
失敗時の通知がされる
SlackとGH;Eだけなので弱い→XFDを使うべき？
GH;Eへの通知がビルド処理の中にある（シェルスクリプトの中に）
ファイルの変更結果をコミット
ファイル変更とテストの実行が同じスクリプトになっているので管理しづらい
開発が完了したらコードレビュー
問題がある場所は修正・変更
ここでのJenkinsの役割は開発時と同じ
レビュー後develブランチにマージ
GHのPRのマージボタンでマージ
コンフリクト解消ミスをしづらい・テスト失敗時にわかりやすい
デプロイ
本番リリース用のpull request作成
- staging系列のブランチを作成。テスト
- masterブランチに向けたPRを作成
- PRにはチェックリストのテンプレが用意されている
JenkinsとGH;Eの活用、連携
テストの自動実行
ファイル変更処理
今後はJenkins Workflow Pluginの導入を考えている
Dockerコンテナによる動作確認とJenkins
要求
- 開発した機能の確認が遅れると困る
- 無駄な手戻り
- 開発スピードの低下(特にUI/UX周り)
- 開発中の機能を確認できる環境は便利
- チーム内(非開発者、遠隔地メンバー)で動作確認をしながら開発したい
- 時にはステークホルダーにも確認していただきたい。
develshot:
featureブランチやdevelブランチの動作が確認できる
- 既存の方法では開発用サーバで複数アプリ起動
- 別ポートを使用
- ポート番号の解決はNginx上のLuaで
課題
同じ環境を複数アプリが使用するので
ファイルシステムやライブラリの共有が課題
→Docker Engineで解決した
Docker Engineとは？
コンテナ型の仮想化技術
ゲストの状態をイメージとしてバージョン管理
dockerfileにビルド処理を記述してDockerイメージを記載
開発用サーバで複数Dockerコンテナ起動
別ポートを使用。ポート番号の解決はDocker APIを使用。
今後
develブランチの自動デプロイ
プルリク
ビルド後にコンテナ内でテストしてそれからデプロイ
まとめ
HEへのプッシュに応じたテスト自動実行や確認用ホストへのデプロイなど
開発プロセスの中でビルドやテストの実行を指揮する大切な役割を果たしている
JenkinsでDockerビルドを利用して。。うんちゃら
JenkinsとPuppet+ServerspecでインフラCI
GMOペパボ株式会社 常松 伸哉 (@tnmt)
https://speakerdeck.com/tnmt/jenkins-puppet-serverspec-infra-ci
Puppetとは
- Configuration Management Framework
- 構成管理ツール
- Infrasutructure as Code
- インフラをコード化する。
- インフラをコードで記述する
Puppetの役割
既にほぼ全ロール（役割）分の構築に関してマニフェスト化が完了している
最初にスクラッチするまでは割りと工数がかかっている（半年以上）
新規構築・機能追加における手間が大幅に軽減できた
2013年当時
マニフェストの検証
作成したマニフェストや設定ファイルの検証は社内KVMなどで
シンタックスエラーはないか
仕様通りにサービスは稼働しているか ←目視…
Nagiosで認識しているか
Serverspec
サーバに対する単体テストフレームワーク。サーバの状態を簡潔なコードで記述してテストするための仕組み。
RSpecで記述
Serverspecの活躍シーン
- ディストリビューションのバージョンアップなどは新旧ディストリビューションの
- 設定がきちんとされているかわかる
- 既存のPuppetマニフェストのリファクタリングの保証
機能追加・リファクタリング時に怖いこと
- 既にある定義とバッティングする
- Puppetで行なっているサーバのロールは３０を超えており、これらのサーバについて１マニフェストの変更ごとにテストするのは辛い
- 各ロールのServerspecテストを自動化する
CIの流れ
PuppetマニフェストのGitHub;Eリポジトリをポーリング
機能追加変更の流れ
specファイル変更
テスト実行（failを確認）
puppetマニフェスト修正、前述のコマンドで適用
テスト実行
結果がOKであればマニフェストとspecをコミット
Gemfile
gemfileでserverspecのバージョンは固定
Rekefile
serverspec実行に必要
バージョンは違うが2.xよう設定についてはペパボで使っているものが公開されているのでそちらを見れる
Vagrantfile
各ロールごとにVMを定義
１ロール１VM以上を定義する
２つ以上のVMは例えばディストリのバージョンごとに作ったりする
vagrant statusして得られるVMの一覧がロールの一覧と思ってもらっても良い。
specディレクトリ
ロールごとのサブディレクトリ
マニフェストに対応したテストケースを用意する。
「Infrastructure as a CodeにおけるJenkinsの役割」 〜環境構築も継続的インテグレーションを行う時代です〜
株式会社サイバード 本田 恭(@Altsencturely)
株式会社サイバード 藤原 涼(@megadreams14)
https://drive.google.com/file/d/0Bywu6GCI_-U4WC02M3lZaE5XTjA/view
参考URL
サーバプロビジョニングのこれまでとこれから
Provisioning Toolchain by lee Thompson at Velocity 2010
サービスの特徴
女性向け恋愛ソーシャルゲームの開発・運用
急激なアクセス増加によるサーバ負荷に耐える必要がある。
Chefを導入するまでの苦労
手動サーバ構築
スケールアウトに時間が掛かる
サーバ構築手順がまとまっていない
Chef導入
サーバ構築を自動化
構築手順の目各課
迅速なスケールアップ
オートスケールの導入
Chef serverの導入
今までのサーバ情報はWikiで管理
オートスケール対応
Chefの問題
1.構成管理ツールに全て任せている
Chefのレシピのコード複雑化
外部サービスとの連携
2.運用上の問題
Chef serverとの接続エラー
実行結果がをついせきしずらい
コンテンツ毎のCHefServerの運用
サーバ構築の概念化
Provisioning Toolchainを参考にした。
サーバ構築を３つのレイヤ化。
Bootstrapping
OSのプロビジョニング
OSのインストールとサーバ起動
Configurationを実行するための準備
Configuration
システム構成のプロビジョニング
Chefなどが得意とするレイヤ。
Orchestraion
アプリのプロビジョニング
デプロイツールなどが得意な領域。サーバ単体では完結しない処理を担う。
第４のレイヤ。Releasalization
サービス提供のプロビジョニング
Orchestraionの処理内容をテスト。Serverspec
サーバを本番環境に投入。
サーバ構築におけるJenkinsの役割
- 今まではソースコードのDeploy。UnitTestのCI。基本的にはデプロイ管理のみ
- 今回はサーバ構築の自動化処理も行うようにした。
- Jenkinsがツールチェインの各レイヤを管理
- 設定が違うサーバの構築制御
- ConfigレイヤはサーバごとのロールをJenkisがChefに渡している。
- Build Flow PluginでJenkinsに管理を委任。
まとめ
Configurationのまとめ
- Provisiioning Tools開発はDocker使うのが良い
- 開発/検証が早くなる
- パッケージ入れ忘れがなくなるのでレシピの品質が向上
Orchestraionのまとめ
- serfのおかげ感がすごい
- バイナリ置くだけですぐ使い始められる
- 柔軟で設定もシンプル
- SSH経由からSerf経由に
Releasalizationのまとめ
- 本番投入前のテスト大事
- serverspec便利
Jenkinsのまとめ
- レイヤーが明確化する
- ジョブのログが残る
- Build Flowを途中で止められる
- Jenkinsは止められない。Jenkins自体が止まると詰むので冗長構成を組んである。
- 執事というよりもはや指揮官
LT
Jenkinsを使った継続的Webセキュリティテスト
http://www.slideshare.net/ichikaway/jenkins-and-vaddy
セキュリティテストは損害賠償、二次被害などのリスクがある。
リリースのたびに外部に脆弱性診断をするのはコストや時間がかかる
継続的にセキュリティテストを行うサービス。Jenkinsと連携することも可能。
http://vaddy.net
Jenkinsおじさん、お堅いメガバンクに就職
時間切れで途中で終了。
Jenkinsおじさんと楽しい連携ツールたち
https://speakerdeck.com/toshihirock/jenkinsozisantole-siilian-xi-turutati
Slack * GitLub
ゲーム業界の人がJenkinsさん3Dモデルで遊んでみた
https://github.com/KokawaTakashi/jenkins3d-unity-sample
JenkinsおじさんのポリゴンをUnityに突っ込んでみた話。
CI”じゃない方”のJenkins
http://www.slideshare.net/MiuraKatsu/ci-43396873
定常処理も自動化する話。バッチ処理などをJenkinsで行うことで、コントロールパネルのように用いる。
定常処理ほど単純作業であり人がやる必要は無い