読者です 読者をやめる 読者になる 読者になる

Jenkins ユーザ・カンファレンス 2012 東京まとめ

Jenkins 勉強会

Jenkinsプロジェクト現状報告とこれから(さったホール)

世界中で利用されている
開発も活発(本体もプラグインも)
 週1でのリリース
 長期安定版(Long-Term Support Release)もある
BuildHiveが便利そう
 GitHubとJenkinsの連携
今後の展望
 プラグイン開発者を助ける
  REST APIの改善などなど
 スイートスポットの拡大
  小さいプロジェクトから大きなプロジェクトまで適用可能に
 増え続けるプラグインへの対応
  Amazonのように、レコメンド機能
  開発言語に合わせたセットの作成

SIerのJenkins事情(S406)

NTTデータ

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)


DeNA

ゲームで使用されている技術と課題

技術

課題
 超高速リリース
 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大会:書籍執筆における継続的デリバリー(さったホール)

http://www.slideshare.net/kaorun55/jenkins-13791448?ref=http://forza.cocolog-nifty.com/blog/2012/07/post-2e13.html

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を使おう!


感想

まとめ書くのに疲れた。。。