Jenkins ユーザ・カンファレンス 2012 東京のメモ
あとでまとめます。
Jenkinsプロジェクト現状報告とこれから(さったホール)
1000人超え!
現状
プラグインの拡大
本体のチケット総数・解決済みチケットも増加
世界中で使われている(アフリカやハワイでも)
新機能
週1でリリースしている
UIの改善
リンクホバーでのメニュー表示(ワンクリックで目的の動作)
ヘッダ・フッタの固定(ページが長くなっても目的の動作をすぐできる)
プラグイン画面
検索機能
機能をインストールしたらすぐ使える
バックエンドの改善
REST APIの改善
コマンドラインクライアントの改善
→プラグイン開発を便利にするため
BuildHive
GitHubとJenkinsの連携
OAuthでログインすると、プロジェクトが出てくる
ある程度自動的にプロジェクトを判定してくれる
法律関係の整備
Software in the Public Interestに加盟
寄付金集め
ライセンス関係などの明文化
今後の展望
プラグイン開発者を助ける
スイートスポットの拡大
より大規模環境で快適に
導入を簡単に
増え続けるプラグインへの対応
Amazonのようにおすすめ機能
Java開発用などのセット
計算機を湯水のように使えるようにしたい(中長期的に)
SIerのJenkins事情(S406)
NTTデータ社内展開
・自動ビルド
・静的コード解析
・自動テスト
・カバレッジ
・自動デプロイ
・規模計測
目論見
・品質向上
・コスト削減
・プロジェクト状況の見える化
取り組み
・SDワークベンチという社内ブランドとして展開
開発環境ツールセットにJenkinsを追加した
事例
10年間の長期運用
1.2Mstep
Java
ウォータフォール
月一のリリース
経緯
自動化を推進したい
リスクヘッジ
定常リリースに影響が少ないところで実施したい
結果
お客様に気に入ってもらえた
テスト自動化により品質担保・業務効率化
結果の見える化
長期運用案件では、定常業務に影響を少なくする
仕組み
SVNから取得し、解析などを行う
デプロイなどは従来通り(手作業)
工夫した点
動作環境の違い
ジョブごとにミドル環境を設定
Seleniumでブラウザテストを自動化
自動化範囲の選択
ビジネスへのインパクトが大きな機能
結果レポートの共有
品質管理チームが開発LANから切り離されていたため、Web画面を直接参照できない
レポートのポータビリティが必要
今後の展開
テストにブラウザバリエーションを拡大
自動デプロイ
→お客様の理解を得れたので進めていける
- プロジェクトK
3〜4ヶ月
120人
250kstep
Java
ウォーターフォール
使い方
ビルド・リリース・デプロイで利用
ポイント
Maven+Nexusで共有
ライブラリの共有・管理
定期的なビルド→リリース
各アプリのビルドをジョブとして管理
テスト環境へデプロイ
SCPで資材転送→リモートコマンドでデプロイ
デプロイ先が20面
1面に対して1日4,5回
担当者2名
効果
速度向上とコスト削減
ビルド・リリースの自動化
テスト環境へのデプロイの自動化
自動化で1回のビルド→デプロイのスピードが向上
- プロジェクトB
2年10ヶ月
1200人
4Mstep
Java
ウォータフォール
経緯
最初は計画していなかった
共通業務などの自動化
ビルドスクリプト作成などによる自動化
開発会社は複数
結合テスト
Jenkinsで各ビルドスクリプトを整理
結合テストに入り、内部リリースの頻度が増大した
→自動化が必須になった
各ビルドスクリプト用のジョブを作成
Jenkins用にカスタマイズ
実行条件・スケジュールをJenkinsで制御
使い方
ファイル転送・デプロイで利用
運用
1日4回の定時デプロイ
間に合った修正のみデプロイ
ビルド作業の効率化
小さなスクリプトが多数あった
ビルドラインの制御
40台位上のマシンへのデプロイを制御
作業待ち時間が大幅に削減
ジョブが開始してから1時間後にデプロイ完了
ビルド失敗の影響は大きいのでは?
段階的なリリース
まず1つの環境にデプロイ
30分動かして問題なければ全環境にデプロイ
貸し出し返却について
凍結された資材を取得することを貸出という
修正した資材を管理対象の資材に登録することを返却という
目的
構成管理対象物に意図しない変更を検知・防ぐ
デメリット
スピードの劣化
防げるエラーが限定的
ファイル名・ファイル数・ファイルサイズなどが主な確認ポイント
貸出返却を撤去した
1000人規模で防げるエラーが2件しか発生しなかった
うまくいった点
リリース頻度の向上
段階的なリリース
貸出返却の撤廃
まとめ
目論見に対して
ビルドとテスト環境へのデプロイで活用された
テスト環境の面数が多数存在
メトリクス自動取得やテストの自動化から導入を始めた
既存プロセス
ポータビリティがある結果レポート
SIの現状に合うプラクティスを取り入れていけば、開発スピードはまだまだ上がる
目的にあわせてプロジェクトに入れやすい形を模索していこう
愛されるJenkins氏になるために(S406)
ゲームで使用されている技術と課題
・サーバ
Perl
MobaSiF
・クライアント
JavaScript
ngCore
課題
超高速リリース
iOS特有の制限によるスケジュールの縛り
歴史的経緯のソースコード
全サポート端末で安定性の確保
Jenkinsの導入
・発端
手動テストの限界
各自の環境でサーバサイドの自動テスト
他の環境でバグが出たり・・・
とりあえず、自動テストを常に流す
自動テストの活用の改善
複数ブランチでの並行開発
イベント=ブランチ
安定ブランチに対してジョブを実行していた
git-flowによる解決策
→無理でした
全部ランチの自動テストをJenkinsで実施
iPadをXFDに(一覧で見やすいものを)
直列ジョブ詰まる問題への対応
Build-timeout Plugin
誰でも簡単に作れるジョブ
ブランチ名を変更すればOK
落ちるテストの対処
DBスキーマに依存するテストコード
落ちているテストは一旦無効化
テストごとにスキーマとフィクスチャを作成
→グリーンにすることが重要!
クラスとテストをテンプレート化し、自動生成
新しいソースは綺麗に作ろう
XFDによる即座の修正
必ずテストを書く
自分でJenkinsのジョブを書く
Jenkinsへの要望が増えた
サーバの状態監視
最初の改善
Perlcritic on Jenkins
アーキテクトUさんの改善
既存のコードは直さないという割り切り
新規はテストに組み込む
ベストプラクティスは守っておいたほうがいいよね、という認識への変化
今後やっていきたいこと
・自動テストの並列実行
Catalyst+proveで実験
・クライアントサイドの自動テスト
jasmine-node
マルチステージ型継続的インテグレーションのすすめ
テクマトリックス株式会社
継続的インテグレーションのメリット
・手戻りの削減・品質の維持
・いつでもリリースが可能
・作業コストの削減
・属人性の排除
・開発データの蓄積
バグ予測
メリットを享受できていますか?
・結合ビルドで行う
複数チームで複数モジュール
それぞれで結合までの手順が異なる
ビルドエラーの影響が他チームに及ぶ
結合できるレベルでないソースが構成管理に格納されている
→改善策
次の視点で見直すことが必要
・チーム・モジュール構成
・開発プロセス
デモムービーによる説明
サイトで確認できるらしい
おわりに
毎日が憧れの新築、反復可能なデリバリーによる常時新築システム(さったホール)
富士通研究所
背景
エクセルでの手順化より、人間が実行している
構築などは1回しかやらない
手順書の間違い・変更が更新されない
cleanの既存プラクティス
make all→make clean all
数ヶ月おきにOSクリーンインストール
運用でも適用したい
PaaSの環境開発
愚直に自動化
Chef Solo
手順書を記載
Rubyで記述
セットアップが簡単
パッケージの集約
OSバージョンとビットごとにビルドサーバを用意
Matrix Jobでビルド
ビルド後にパッケージ集約ジョブを呼び出す
Parameterized Trigger Plugin
ビルドジョブからアーティファクトをコピー
Copy Artifact Plugin
マシンの用意
各種Cloud Plugin
任意のタイミングでのVM制御が必要
デプロイ手順としてリブート
Java, Git, Ruby, Chef-soloをインストールしたテンプレートVMを用意
テンプレートからVMを作り、そこにデプロイ
電源を入れるジョブの例
Power CLIより実行
デプロイの実行
ノードをまたがって逐次実行するジョブ
Parameterized Trigger Plugin + NodeLabel Parameter Plugin
スローデプロイ問題
デプロイに60分かかる
スローテスト問題は、テストケースを分割して並列実行が1つの解
デプロイ所要時間の分析
・VMスナップショットへの復元
10分→3分
制約は増えるが速度のほうが重要
・インターネットからの分離
rpmやgemのダウンロードが遅いので、事前にアーティファクト化
45分から2分に
yum -y install --downloadonly libxml2
...
createrepo
外部影響の原因追求
インターネット接続がない環境へのデプロイ
・自前と既成の分割と冪等性
f(f(x)) = f(x)
・自前パッケージ
自分のソースからビルドするパッケージ
・既成パッケージ
他者が作ったパッケージ
更新頻度・インストール所要時間に違いがある
・デプロイスクリプトを分割
・冪等なデプロイスクリプトを作成する
自動化と高速化による変化
・早い失敗を目指す
パイプラインのなるべく早い段階でエラーとなるように
Fail fast
設定ファイルではなく、設定ファイル作成プログラム
設定ファイルの入力チェックなどを行える
・環境の使い捨て
本番と同じ環境で開発
高速なデプロイと冪等なスクリプトのおかげ
・ブランチごとにデプロイ
毎回新規に作られる環境による安心感
デプロイまで行うので試用ができる
まとめ
自動化できるものは自動化
・デリバリーも自動化しましょう
・クリーンと冪等で反復可能に
自動化をより高速に
・高速化の検討すべき
・迅速なフィードバック
・速ければ使い方も変わる
執事のJenkinsさんは万能
・CI以外もこなせる
・執事を遣い倒そう
LT大会:書籍執筆における継続的デリバリー
Kinect本執筆時の話
SPHINX
Pythonで動く
テキストベース
PDFにはビルドが必要
→Jenkinsを利用
どこで動かす?
CloudBees
基本Javaのみ動作
Virtual Pythonというのがあるらしい
githubへpush→CloudBeesでePubへ→編集者が確認
時間切れ。。。
LT大会:英語Jenkinsコミュニティの解説
(スライドなかったので、話を聞いてるとメモとれなかった)
英語コミュニティにぜひ参加してください
LT大会:Flash(ActionScript3.0)開発でもJenkinsを導入しよう
antがあれば何でもできる
でも大変。
Maven3プロジェクト
Flexmojos
コンパイルオプション、依存関係はpom.xml
JenkinsサーバにFlash Playerインストール
新規ジョブにMavenを
Xがないと動作しない
xvfb上でFlash Playerを実行
64bitOS上での動作が不安定
Flash自体の動作が不安定
実行時間が遅い
時間切れ。。。
LT大会:普通のSIerのJenkinsのある暮らし
ビルドパイプライン
社内フレームワーク
サポートしている環境の組み合わせが多い
(JDKは1.5〜7、DBも複数製品・複数バージョン)
組み合わせはマルチ構成
Join Plugin
自動デプロイ
Antを実行しているだけ
組み合わせによるバグを検出できる
自動化することで精神的に安定する
LT大会:運用でも使えるJenkins
Jenkinsのイメージ
開発に使う
ビルドに使う
バッチ処理
DBダンプ
ファイルのバックアップ
とか定時実行
→cron
エラーに気づかない
Jenkinsでできる
メールはもちろん
結果も
履歴も
REST APIで処理時間
スレーブ機能の活用
ちょっとしたジョブフロー
Join Plugin Build Flow Plugin
運用の手間が減らせる