Jenkins ユーザ・カンファレンス 2012 東京まとめ
Jenkinsプロジェクト現状報告とこれから(さったホール)
世界中で利用されている
開発も活発(本体もプラグインも)
週1でのリリース
長期安定版(Long-Term Support Release)もある
BuildHiveが便利そう
GitHubとJenkinsの連携
今後の展望
プラグイン開発者を助ける
REST APIの改善などなど
スイートスポットの拡大
小さいプロジェクトから大きなプロジェクトまで適用可能に
増え続けるプラグインへの対応
Amazonのように、レコメンド機能
開発言語に合わせたセットの作成
SIerのJenkins事情(S406)
Jenkinsで実施すること
- 自動ビルド
- 静的コード解析
- 自動テスト
- カバレッジ
- 自動デプロイ
- 規模計測
目論見
- 品質向上
- コスト削減
- プロジェクト状況の見える化
取り組み
SDワークベンチという社内ブランドとして展開
開発環境ツールセットにJenkinsを追加した
事例A
10年間の長期運用
1.2Mstep
Java
ウォータフォール
月一のリリース
・既に運用が進んでいるため、影響が少ないところから始める
デプロイは従来通り手作業
テスト自動化・コードの静的解析をJenkinsにて実行
・動作環境が古いと、ジョブごとにミドルウェアの変更が必要な場合がある
・ビジネスへのインパクトが大きい機能を自動テスト
・品質管理チームが開発LANから切り離されていると、レポートのポータビリティが重要
・お客様の理解が得られたので、今後はデプロイなども自動化していく
事例K
3〜4ヶ月
120人
250kstep
Java
ウォーターフォール
・Maven+Nexusで共有
ライブラリの共有・管理
・デプロイ先が20面、1面に対して1日4,5回、担当者2名
自動化しないと対応できない
事例B
2年10ヶ月
1200人
4Mstep
Java
ウォータフォール
・最初は計画していなかった
それぞれのチームでビルドスクリプトなどは作成されていた
・結合テストに入り、内部リリースの頻度が増大した
対象マシンも40台位上
頻度・数が多く、自動化が必要
1つの環境にデプロイし、30分動作が確認できれば全環境にデプロイ
・各チームのビルドスクリプトをJenkinsでまとめて管理
・貸出返却は意味が無い
1000人規模で防げるエラーが2件だけだった
→撤廃
まとめ
ビルド・テスト環境へのデプロイで活用された
テスト環境面が多数存在した場合に効果を発揮
メトリクス自動取得・テストの自動化から導入を始めた
既存プロセスがある場合はそこから始めるのがよい
ポータビリティがある結果レポートが必要
SIの現状に合うプラクティスを取り入れていけば、開発スピードはまだまだ上がる
目的にあわせてプロジェクトに入れやすい形を模索していこう
愛されるJenkins氏になるために(S406)
ゲームで使用されている技術と課題
技術
- サーバ
- クライアント
- JavaScript
- ngCore
課題
超高速リリース
iOS特有の制限によるスケジュールの縛り
歴史的経緯のソースコード
全サポート端末で安定性の確保
複数ブランチ(ゲームイベント毎ぐらいで作られる)の並行開発
マスターブランチに自動テストを流す
→あんまり意味ない
git-flowによる解決策
→無理でした
全ブランチに対して自動テストを実行
iPadをXFDに(全ブランチの結果を一覧化)
→赤くなったら修正する!
落ちるテストの問題
200程度のテストで落ちていたが、一旦無効化
→グリーンに保つことが大事(エラーケースはDBスキーマ依存などだった)
既存コードは諦める
新規ソースはがんばる
ベストプラクティスは守っておいたほうがいいよね、という認識への変化
今後やっていきたいこと
・自動テストの並列実行
・クライアントサイドの自動テスト
マルチステージ型継続的インテグレーションのすすめ(S406)
テクマトリックス株式会社
マルチステージ型=複数箇所で継続的インテグレーションを行う
複数のチームがある場合、それぞれでCIを回し、結合する際には同程度の成熟度にする。
商用製品を使っての説明だったので、個人的にあんまり興味を持てなかった。
毎日が憧れの新築、反復可能なデリバリーによる常時新築システム(さったホール)
http://www.slideshare.net/ohtaketomohiro/ss-13793834
富士通研究所
環境構築は1回やって終わりのことが多い
その後は手順書を修正しながらだったり、修正されなかったり・・・
PaaSの環境構築の時の話
元々はデプロイに8人日(+アルファ)かかっていた
愚直に自動化
環境構築も自動化しよう
Chef Soloを利用
・パッケージの集約
アーキテクチャ毎にビルドサーバを用意しビルド
その後、集約ジョブを実行
・マシンの用意
Java, Git, Ruby, Chef-soloをインストールしたテンプレートVMを用意
テンプレートからVMを作り、そこにデプロイ
電源投入などもジョブとして実行
・デプロイの実行
ノードをまたがって逐次実行
master -> powercli -> slave
slaveは複数台
スローデプロイ問題
自動化してもデプロイに60分かかる
スローテスト問題は、テストケースを分割して並列実行が1つの解
→デプロイは並列実行ができない
・VMスナップショットへの復元
10分→3分
制約は増えるが速度は改善
・インターネットからの分離
rpmやgemのダウンロードを内部化
45分→2分
インターネット接続が無い環境へのデプロイが可能に
・自前と既成の分割と冪等性
冪等性:f(f(x)) = f(x)
・自前(自分のソースからビルド)
・既成(他人が作ったもの)
更新頻度・インストール所要時間に違いがある
→デプロイスクリプトを自前・既成に分割
→冪等(何度実行しても同じ)なデプロイスクリプトを作成する
自動化と高速化による変化
・早い失敗を目指す
テストでのエラーより、デプロイ時のエラー
設定ファイルではなく、設定ファイル作成スクリプト
→設定値の入力チェックなどを行える
・環境の使い捨て
本番と同じ環境で開発
・ブランチごとにデプロイ
毎回新規に作られる安心感
まとめ
自動化できるものは自動化
・デリバリーも自動化しましょう
・クリーンと冪等で反復可能に
自動化をより高速に
・高速化の検討すべき
・迅速なフィードバック
・速ければ使い方も変わる
執事のJenkinsさんは万能
・CI以外もこなせる
・執事を遣い倒そう
LT大会:書籍執筆における継続的デリバリー(さったホール)
Kinect本執筆時の話
SPHINX
Pythonで動く
テキストベース(バージョン管理しやすい)
PDFにはビルドが必要
→Jenkinsを利用
どこで動かす?
CloudBees
githubへpush→CloudBeesでePubへ→編集者が確認
。。。時間終了
LT大会:英語Jenkinsコミュニティの解説(さったホール)
(逐次通訳だったので聞くのに忙しかった)
結論:英語コミュニティにぜひ参加してください
LT大会:Flash(ActionScript3.0)開発でもJenkinsを導入しよう(さったホール)
antがあれば何でもできる(猪木風)
→でも大変。
Maven3で
JenkinsサーバにFlash Playerをインストール
Xが無いと動作しない
xvfb(仮想ディスプレイ)上でFlash Playerを実行
問題点
64bitOS上で、Flash自体の動作が不安定
実行時間が長い
。。。時間終了
LT大会:普通のSIerのJenkinsのある暮らし(さったホール)
社内フレームワーク開発の話
サポートする環境の組み合わせが多い
(JDKは1.5〜7、DBも複数製品・複数バージョン)
自動デプロイ
Antを実行
複数環境で自動テストを行うことで、バージョン組み合わせのバグを検出できる
自動化することで精神的に安定する
。。。無事終了
LT大会:運用でも使えるJenkins(さったホール)
Jenkinsは開発でのみ使うものではない
Jenkinsはなんでもできる
定期バッチ
定時でのDBダンプ
定時でのファイルバックアップ
→全部Jenkinsでできる
エラーメールの送信
結果レポート
実行履歴管理
→全部Jenkinsでできる
運用でもJenkinsを使おう!
感想
まとめ書くのに疲れた。。。