1. 2012/05/29(火） @suzukij

2.  Jenkinsについて
 デモ
 CI 継続的インテグレーション
 CD 継続的デリバリー
 チームでの運用例
 まとめ

3.  Jenkinsを現場で使っている人？
◦ 自動ユニットテスト
◦ 自動ビルド
◦ 自動デプロイ
 Jenkinsに関する本読んだ人？

4.  世界で最も使われている
継続的インテグレーションツール
Continuous Integration （CI）
 Javaで書かれたOSSのCIサーバ
◦ warファイルで提供される
 導入、設定が簡単
◦ ほぼすべての設定をブラウザから操作できる

5.  Cron（スケジューラ）の強化版
◦ 人間が介在せずとも実行できるようなスクリプトを
自動で繰り返して実行し、結果を収集して表示
 CIの実践をサポートするツール
◦ 高い拡張性
◦ 豊富なプラグイン(450以上)

6. ①公式サイトからDL
http://jenkins-ci.org/
②起動 以下コマンドのみ
java –jar jenkins.war
③ブラウザからアクセス
http://localhost:8080/

7. とりあえずシンプルなデモ
①ジョブの作成
②ジョブの実行
③ジョブ結果の通知

8. なんとなく分かったところで
JavaソースからJar（war）ファイルを作成するところまでをデモ
①SVNリポジトリからソースを取得
②ユニットテスト
③ビルド（Maven）
④静的コード解析
FindBugs, PMD/CPD, CheckStyle,
Javadoc, emma

9. なんとなくイメージは掴めたでしょうか？
 Jenkinsでどんなことができるのか
 Jenkinsを実際のプロジェクトでどう使うのか

10.  もともとはXPの一部の「結合テストを頻繁に
実施する」という作法
 ビルド、テスト、コードの品質検査など、定型的
で反復可能な作業を自動化し、繰り返しこまめ
に実行することで省力化を図ること
 自動化による省力化によって開発者が設計をし
たりプログラムを書いたりというより創造的な作
業に集中できるようにする全般のこと

11. 繰り返し実行
実行を自動化
⇒省力化を図る

12.  すばやいフィードバック
◦ コミットのたびにテストやコードの品質検査をする
 問題を早期発見できる
 小さな修正を素早くおこなうことができる
⇒問題の発見、対応を先送りしない
⇒リリース直前まで
問題が溜め込まれるのを防ぐ

13.  見える化 気付ける化
◦ ユニットテストやビルドの結果を時系列に表示
◦ コード検査/カバレッジ取得の結果をグラフで表示
⇒プロジェクトの健康状態を把握
◦ ビルド手順、テスト手順をスクリプトとして集約
⇒Jenkinsで動くもののみが管理される
⇒長ったらしい手順書が陳腐化することもない
⇒属人化を防ぐ

14.  以上、CIの簡単な説明です。
 CIについての質問

15. アジャイルマニフェストの条文
「我々がもっとも価値を置くのは、価値のあるソフトウェ
アを早いうちから継続的にデリバリーすることを通じて
顧客を満足させることである」
なんだか難しそうだけど まず
CIを通じて出来上がったモジュールをテスト環境、本
番環境へ自動でリリースできるようにし、反復可能
なプロセスを構築する

16. いつでも、素早く、繰り返し可能なリリース
デプロイボタンを1度クリックするだけでテスト済み/
コード検証済みのモジュールが完全な状態でテスト
環境や本番環境へリリースすることができる。
数秒で完了させることができる。
望むバージョンを好きな環境へ
自分の望むバージョンのアプリケーションを好きな環
境に自分でリリースできる。
問題が発生してもすぐにリリース前に状態に戻せるよ
うにする。

17. リリースする権限はPJに関わるメンバに
開発者だけでなくチームに関わるメンバにリ
リースする権限を持たせる
（テスター、サポート担当者、運用担当者など）

18.  チーム間の作業を効率化
◦ 各チームメンバが自身でビルドできるようになるこ
とで正しいビルドが渡されるのを待つ必要がなくな
る （無駄なメールのやりとり、申請が不要に）
◦ リリースがボタンひとつで実行できる 例えば…
 テスター：アプリの旧バージョンと新バージョンの変更を
検証することができる とか
 サポート担当者：アプリをテスト環境にデプロイし、欠陥
を再現することができる とか
 運用担当者：ディザスタリカバリの演習の一環としてビル
ドを本番環境へデプロイできる など

19.  リリースの負担を減らす
◦ 小さく、早いサイクルでリリースができるようになる
◦ 手順書に従ってビクビクしながら手動でリリースす
る必要がなくなる
◦ リリース後に問題があった場合でも容易に前の状
態に戻すことができる
 素早いフィードバック
◦ CIと同様のメリット

20.  以上、CDの簡単な説明です。
 CDについての質問

21.  実行までを自動化
（主にビルド、デプロイ）
◦ 簡単に実行できるようにする
◦ 何度も繰り返せるようにする
◦ 手順やルールをJenkinsに寄せる
 属人化を防ぐ
 ○○さんしか知らない作業
 更新されていない手順書
↑×ダメ絶対

22.  素早くこまめに
◦ 統合の間隔は短く、小さく
◦ 問題の早期発見、早期対応
◦ 統合に関連するリスクを減らす

23. ビルド、デプロイ作業のよう
な単純で面倒で面白くない
タンポポワークは
Jenkinsさんに任せてしまえ
結果だけを教えてもらおう

24. 以上、駆け足でJenkinsとCI、CDについて簡
単に説明させてもらいました。
CI、特にCDはプロジェクトチーム全体に関
わることなので現実にはなかなか難しいと
思います。
ですが日頃から各プロセスについて改善を
続けていけば少しずつ導入できると思って
います。
（CI、CDは少しずつ一歩一歩が重要）

25. 初めての自動化には大きな痛みが伴い
ますが受ける恩恵は計り知れないくらい
大きいです。
2年以上CIを実践しているものの、いま
だにイケていないところがたくさんあるの
ですが導入する価値は大いにあると
思っています。

26. みなさんもJenkinsを使ってCI、CDに取り
組んでみてはいかがでしょうか？
Jenkinsを使った作業の自動化はすぐに
個人でも始めることができます。
まずはローカルで動かしてみません
か？

27. 以上、ご静聴ありがとうございました。

28. ■日程
2012/07/29(日) 11:30 – 17:30
■場所
法政大学 市ヶ谷キャンパス
http://connpass.com/event/467/

29. おすすめの書籍
 Jenkins実践入門 ビルド・テスト・デプロイを自動化する技術
 Jenkins（カエル本）
 継続的デリバリー

30.  ビルド
◦ Ant (ActionScriptをビルド→swf)
◦ Maven（Javaビルド→war、ユニットテスト、JavaDoc生成）
 コードの品質検査
◦ PMD/CPD（コードの重複、コピペ、DRY原則のチェック）
◦ FindBugs（潜在バグのチェック）
◦ CheckStyle（コーディングルールのチェック）
◦ タスクのチェック（ソースの ”TODO” や ”FIXME” を検出）
 テスト
◦ JUnit（ユニットテストの実行）
◦ Cobertura（テストカバレッジの取得）

31.  DB環境構築（Oracle10, 11, Postgres8, 9, SQLServer2005, 2008）
◦ テスト環境DBのテーブルをドロップ、作成、マスタ登録、テストデータ登録
 デプロイ(Tomcat6, 7, WebSphere8)
◦ Deploy（APサーバへのデプロイ、アプリ再起動）
 テスト環境に対してAPIのテスト(AP, DBの上記組み合わせ)
◦ AP 6 * DB 3 = 18パターン
◦ JUnitを実行し、テスト環境に対してHTTPリクエスト、期待するレスポンスの
XMLが返ってくるか検証
 通知
◦ メール通知（各ジョブが失敗した時のみ結果を通知）
◦ IRCプラグイン（各ジョブが完了した時に結果を通知）

32.  その他 ツール系
◦ テスト環境のヘルスチェック（スケジュールで5分おき）
◦ バックアップ（スケジュールで毎日）
◦ ER図をもとにDB定義書.xls、DB定義.htmlを生成（ワンクリック）