継続インテグレーション(CI)の基本

1. WordPressプラグイン開発で学ぶ
継続的インテグレーションの基本
瀬戸 貴弘
２０１５年9月13日

2. 瀬戸 貴弘
Twitter
WordPress暦： 2.6 からブログで使い始めました。
瀬戸 貴弘 （せと たかひろ）
：＠as_chachamaru
Facebook ：as.chachamaru
WordCamp Kansai 2014 副実行委員長、スピーカー。

3. アジェンダ
継続的インテグレーション（CI)による開発とは
WordPressプラグインをCIでつくる
継続的インテグレーション開発のメリット
【概要】
【実例】
【まとめ】

4. 【概要】
継続的インテグレーション（CI)による開発とは

5. こんな開発経験したことありませんか？
（従来開発の問題点を考えよう）
トラウマの方ごめんなさい…:(´◦ω◦｀):

6. 要件定義
仕様設計
開発(PG)
テスト
納品
きめ細かいスケジュール管理

7. 要件定義
仕様設計
開発(PG)
テスト
納品
テスト工程が最後の方にある

8. 要件定義
仕様設計
開発(PG)
テスト
納品
開発終了まで単体テストぐらいしかない。この状態で
テスト工程に入ると・・・

9. 要件定義
仕様設計
開発(PG)
テスト
納品
大量のバグが一気に発見される

10. 要件定義
仕様設計
開発(PG)
テスト
納品
完成プログラムは複雑・解析大変
どこでバグ起こって
るんだよ・・

11. 要件定義
仕様設計
開発(PG)
テスト
納品
バグの修正が広範囲に影響を
受けやすく、修正が難しい。
この修正で大丈夫かな。

12. 三つのデバグは一つのバグを産む。
これをバグのエンドレスループという。
プログラマー格言

13. テスト
さらにテストも種類が多い
単体テスト
(PT)
単体テスト
(PT)
結合テスト
(IT)
システムテスト
(ST)
運用テスト
(OT)

14. 自分のローカル環境で動作してたとしても・・・
単体テスト
(PT)
単体テスト
(PT)
結合テスト
(IT)
システムテスト
(ST)
運用テスト
(OT)
大体バグ取れてきたな

15. 本番に近い環境で動くとは限らない・・・
単体テスト
(PT)
単体テスト
(PT)
システムテスト
(ST)
運用テスト
(OT)
結合テスト
(IT)
自分の環境だと
動いてたよ

16. ただ動くだけじゃダメ！快適に動作するか
単体テスト
(PT)
単体テスト
(PT)
システムテスト
(ST)
運用テスト
(OT)
結合テスト
(IT)

17. いよいよ完成間近！
単体テスト
(PT)
単体テスト
(PT)
運用テスト
(OT)
完成がみえてきた。
先方にみてもらうか。
結合テスト
(IT)
システムテスト
(ST)

18. とは限らない。
仕様修正や仕様漏れが仕様書に反映されるとは限らな
い。（忙しいと後回しされ忘れ去られる）
単体テスト
(PT)
単体テスト
(PT)
運用テスト
(OT)
結合テスト
(IT)
システムテスト
(ST)
先方と認識ずれてた。
仕様書漏れがあった。
PM、SE

19. 開発はまだまだ続く・・・
単体テスト
(PT)
単体テスト
(PT)
結合テスト
(IT)
運用テスト
(OT)
システムテスト
(ST)

20. 要件定義
仕様設計
開発(PG)
納品
納品！ お疲れ様！
テスト

21. 仕様設計
開発(PG)
納品は運用という長い地獄の入り口になることもある
テスト
納品 拡張・運用

22. 仕様設計
開発(PG)
テスト
納品 拡張・運用
コード整理（リファクタリング）もデグレ怖い・・

23. 仕様設計
開発(PG)
テスト
納品 拡張・運用
納品後には、ドキュメントは信用してはならない

24. 彼の闘いはまだまだつづく・・・
（こういう経験ないですか？)

25. 問題点は何だろ？

26. 問題点

27. 仕様設計 開発(PG) テスト
開発(PG）が終わったあとにテスト工程がある。
開発後の複雑なコードのバグ修正は大変。
複雑に絡みあったコードのあとではバグ修正が多くに
影響を与えることもある。

28. ならば

29. 短期間（コミット時）に何度もテストを行う。
短期間なのでバグが発見しやすい。
バグを潰しながら進めると手戻りが削減できる。
テスト範囲は影響を考えて全体に。
開発・テスト・修正 開発・テスト・修正

30. そんなにテストしたら
テスト時間だけで開発
終わっちゃうよ

31. 開発・テスト・修正 開発・テスト・修正
テストツールを使えばテストケースを作るだけ。
何百というテストケースでもツールに任せれば良い。
テストツール テストツール

32. さらに仕様書がなくても、
テストケースみたら
動作仕様が大体わかるね
他にも、影響テスト（リグレッションテスト）や、
コード整理（リファクタリング）、拡張や仕様変更も
しやすくなる。

33. 問題点

34. 本番に近い環境で動くとは限らない・・・
単体テスト
(PT)
単体テスト
(PT)
システムテスト
(ST)
運用テスト
(OT)
結合テスト
(IT)
自分の環境だと
動いてたよ

35. ならば

36. 開発
修正
本番環境に近いテスト用サーバを準備して
そこでテストしてやればいい
テスト
(本番環境に近い）

37. コミットのたびに
テストサーバにアップ
してテストするの
面倒だよ

38. コミットしたことを監視し、自動でテストできる状態
にしてテストを行い、結果を教えてくれる仕組みを作
ればいいね
コミット
監視
ビルド
テスト
(本番環境に近い）
開発
結果通知
すぐに修正
CIサーバ
バージョン管理

39. コミット
監視
ビルド
テスト
(本番環境に近い）
開発
結果通知
すぐに修正
CIサーバ
テスト工程やコードの区切りなどで好きなときにビル
ド(コンパイル・テストなど)をするのではなく、常に
監視・ビルドし極力エラーのない状態を維持する。

40. テスト工程やコードの区切りなどで好きなときにビル
ド(コンパイル・テストなど)をするのではなく、常に
監視・ビルドし極力エラーのない状態を維持する。
これを行う仕組み

41. テスト工程やコードの区切りなどで好きなときにビル
ド(コンパイル・テストなど)をするのではなく、常に
監視・ビルドし極力エラーのない状態を維持する。
これを行う仕組み
継続的インテグレーション

42. 【実例】
WordPressプラグインをCIでつくる

43. バージョン管理
CIサービス
テストツール
：Git
：Travis CI
：PHPUnit

44. Travis CI
GitHub のリポジトリと連携。
設定（.travis.yml）を追加するだけで CI 環境
を提供。
VM 上でビルドを行う。

45. コミット
監視
ビルド
テスト
開発
結果通知
Travis CI
バージョン管理
メール PHPUnit
バージョン管理
CIサービス
テストツール
：Git
：Travis CI
：PHPUnit
VM

46. 難しそう・・・

47. 意外と簡単！
GitHub プロジェクトとTravis CIを連携
設定（.travis.yml）を作成
PHPUnit用のテストケースを作成
あとは Travis CI サービスにお任せ！

48. デモ

49. 【まとめ】
継続的インテグレーション開発のメリット

50. 開発・テスト・修正 開発・テスト・修正
コミット時にテストが行われるのでバグの早期発見がしや
すい。
コミット時のコードにバグの可能性が高く原因が突き止め
やすい。手戻りが減り、工数削減になる。
(テストツールを使ったテストで影響テストも行う）

51. 開発
修正 テスト
(本番環境に近い）
本番環境に近いテストがしやすい。
テスト専用サーバだとコードチェックツールやセキュリ
ティチェックツール、負荷テストツールなどを使った高ス
ペックな環境が必要なテストがしやすい。
品質があがる

52. コミット
監視
ビルド
テスト
(本番環境に近い）
結果通知
CIサーバ
★自動化
★自動化
★自動化
コミットするだけで、テストサーバに反映、テスト実行さ
らに結果確認までの面倒な作業が全て自動化。工数削減や
他の作業に集中できる。
自動化することで、テストサーバが最新でなかったりテス
トをしなかった！などの手動によるミスが減る。

53. コミット
監視
ビルド
テスト
(本番環境に近い）
結果通知
CIサーバ
★動作保証された
最新状態
開発者以外の人でも最新の状態を確認しやすい。
PM、SEそしてクライアントにも確認してもらいやすいの
で早期の段階で認識のズレが修正しやすい。

54. まとめ
継続的インテグレーションの仕組みを作るのは大変です
がクラウドなど簡単に実現できるものも多くあります。
また、テストの自動化だけする！と一部だけまずはやっ
てみるだけで効果があります。少しづつできることを増
やしていけばいいと思います。
また、JavaScriptやCSSのCIツールもあるようです。自
分の開発に適したCIツールを探してみてはどうでしょ
う。
開発効率を！ 品質向上を！

55. ありがとうございました。