Jenkins ユーザ・カンファレンス 2012 東京のメモ

あとでまとめます。

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

1000人超え!

現状

プラグインの拡大
本体のチケット総数・解決済みチケットも増加
世界中で使われている(アフリカやハワイでも)

新機能

週1でリリースしている
UIの改善
 リンクホバーでのメニュー表示(ワンクリックで目的の動作)
 ヘッダ・フッタの固定(ページが長くなっても目的の動作をすぐできる)
プラグイン画面

 検索機能
 機能をインストールしたらすぐ使える

バックエンドの改善
 REST APIの改善

 コマンドラインクライアントの改善
  →プラグイン開発を便利にするため

プラグイン開発
 Rubyによる開発
 Java
  拡張ポイントの拡充

BuildHive

 GitHubとJenkinsの連携
 OAuthでログインすると、プロジェクトが出てくる
 ある程度自動的にプロジェクトを判定してくれる

法律関係の整備

 Software in the Public Interestに加盟
  寄付金集め
 ライセンス関係などの明文化

サーバインフラ

 長期サポートリリース
  3ヶ月に一度のペース

  通常リリースは週1
 セキュリティ勧告
  ML・RSSで発表
 サーバ管理のOSS化
  puppet化+オープンソース
 nagiosの利用

今後の展望

 プラグイン開発者を助ける
 スイートスポットの拡大
  より大規模環境で快適に
  導入を簡単に
 増え続けるプラグインへの対応
  Amazonのようにおすすめ機能
  Java開発用などのセット

 計算機を湯水のように使えるようにしたい(中長期的に)

SIerのJenkins事情(S406)

NTTデータ

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)

DeNA

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

・サーバ
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

運用の手間が減らせる