Download as PDF, PPTX
![Unit Test ?
テスト書き辛さ問題
ˆ クラスベースなコードの方が少ない
ˆ グローバル関数、グローバル変数が主流
ˆ そもそも <html> の中にビジネスロジックが…
古い PHP に縛られる
ˆ 綺麗に書けなくてイライラ 問題
ˆ trait 使いたいし array(’a’) を [’a’] って書きたい
ˆ バージョンアップに影響をうける
ˆ 本体コード、テストコード両方同時に手を…？](https://image.slidesharecdn.com/peace-of-mind-container-based-ci-150416103726-conversion-gate02/85/Container-based-CI-16-320.jpg)
Uploaded byWataru MIYAGUNI
あなたの安心を高速に守る Container-based CI
Agile Japan 2015 サテライト＜沖縄＞ https://java-kuche.doorkeeper.jp/events/22305 --- 開発を安心して高速に回すための取り組みの一つに 「テストの実行時間を短縮する」 というものがある。 今回はその一例として、Docker のコンテナ技術を用いてテスト並列実行の高速化かつ安定化を目指した記録を紹介する
あなたの安心を高速に守る Container-based CI
- 1. あなたの安心を高速に守る Container-based CI 宮國 渡(@gongoZ) 2015-4-18
- 2. Agenda ˆ 背景 (過去にあった問題解決の話) ˆ新たなる問題 ˆ 振り返らない高速化が生んだ弊害 ˆ 高速と安定の join ˆ まとめ
- 3. 自己紹介 社会人 ˆ 宮國 渡(MIYAGUNI Wataru) ˆ 株式会社ＯＣＣ ˆ PHP な Web アプリケーション開発・運用保守 プライベート ˆ github.com/gongo ˆ Just Do Eat
- 4. 自己紹介 社会人 ˆ 宮國 渡(MIYAGUNI Wataru) ˆ 株式会社ＯＣＣ ˆ PHP な Web アプリケーション開発・運用保守 ˆ ↑ これにまつわる話します プライベート ˆ github.com/gongo ˆ Just Do Eat
- 5.
- 6. Long long ago.. PHP3, 4, 5 の時代を渡り歩いてきた、とある Web アプリ ケーションが居ました ˆ PHP がテンプレートエンジンであった頃 ˆ HTML にビジネスロジックを書き始めた頃 ˆ PHP がアクセス修飾子の無いオブジェクト指向を取り 入れた頃 ˆ 各人から生まれる複数のオレオレフレームワーク
- 7. Long long ago.. PHP3, 4, 5 の時代を渡り歩いてきた、とある Web アプリ ケーションが居ました ˆ PHP がテンプレートエンジンであった頃 ˆ HTML にビジネスロジックを書き始めた頃 ˆ PHP がアクセス修飾子の無いオブジェクト指向を取り 入れた頃 ˆ 各人から生まれる複数のオレオレフレームワーク ˆ 全部混ざってる！
- 8. Long long ago.. PHP3, 4, 5 の時代を渡り歩いてきた、とある Web アプリ ケーションが居ました ˆ PHP がテンプレートエンジンであった頃 ˆ HTML にビジネスロジックを書き始めた頃 ˆ PHP がアクセス修飾子の無いオブジェクト指向を取り 入れた頃 ˆ 各人から生まれる複数のオレオレフレームワーク ˆ 全部混ざってる！ ˆ 何よりテストが無い！
- 9. 現代の PHP (Versions) versioninitial release EOL 5.4 2012/03/01 2015/09/14 5.5 2013/06/20 2016/06/20 5.6 2014/08/28 2017/08/28 (new! →) 7.0 2015/11/xx via PHP: Supported Versions
- 10. 現代の PHP (周辺) ˆPHP-FIG — PHP Framework Interop Group ˆ PSR-FIG なるコミュニティが策定する規約 ˆ PSR-0 —Autoloading Standard ˆ PSR-2 —Coding Style Guide ˆ PSR-3 —Logger Interface など ˆ Composer ˆ パッケージ依存管理ツール (Ruby でいう Bundler) ˆ Packagist ˆ Composer リポジトリ (Ruby でいう RubyGems)
- 11. やりたいことは ˆ 例: PHP5.5 に上げたい ˆ 例: もうメンテされてないライブラリから移行したい ˆ 例: リファクタしたい
- 12.
- 13. 装備 = 自動テスト 「これまで」 ˆテスト仕様書 (Excel) を見ながら手動テスト ˆ 新機能開発であれば手動テストでも良い ˆ 自動テストの主流である回帰テストはあくまで 回帰 ˆ 新規のバグは発見できない。経験と勘が必要 「これから」 ˆ 中身が変わっても外側が変わらないことを保証したい ˆ 古いライブラリからの引越しのたびに全手動テスト？ ˆ PHP バージョンアップのたびに全手動テスト？
- 14.
- 15. 前提条件 Resource ˆ 仕様書はない (ERD含む) ˆ 手動テストで使っていた Excel ならある Policy ˆ 仕様/UI の変更は無い想定とする
- 16. Unit Test ? テスト書き辛さ問題 ˆクラスベースなコードの方が少ない ˆ グローバル関数、グローバル変数が主流 ˆ そもそも <html> の中にビジネスロジックが… 古い PHP に縛られる ˆ 綺麗に書けなくてイライラ 問題 ˆ trait 使いたいし array(’a’) を [’a’] って書きたい ˆ バージョンアップに影響をうける ˆ 本体コード、テストコード両方同時に手を…？
- 17. End-to-End test ? ブラウザ操作してその結果(画面) をチェック系 ˆ Excel から、ある程度機械的にテストケース作成可能 テストコードが サーバーサイドに依存しない ˆ 将来的にも使い続けていける可能性が高い PHP に拘らずに 書ける ˆ バージョンを気にするのは本体のコードだけ ˆ テスト環境は現代のツールを導入できる
- 18.
- 19. Environment of integration testing 簡潔に書けそうなRuby 製を選択 ˆ ブラウザの操作 ˆ Selenium - Web Browser Automation ˆ Selenium Ruby binding ˆ RubyBindings - selenium ˆ Selenium Ruby binding のラッパー ˆ jnicklas/capybara ˆ Ruby テストフレームワーク ˆ RSpec: Behaviour Driven Development for Ruby
- 20.
- 21.
- 22. Next stage aftertest automation テスト実行するのに疲れてしまう (人間だもの)
- 23.
- 24.
- 25.
- 26.
- 27. Continuous Integration 継続したいことは ˆ コードがcommit (push) される度にテスト走るとか ˆ 深夜に、その日 commit されたコードでテストとか ˆ 他にもいろいろ定型的な作業とか via Jenkins CI
- 28.
- 29.
- 30.
- 31.
- 32.
- 33. 構成を組んだあとは 以下のことが実現 ˆ 深夜に 1回、全 Integration test を実行 ˆ 前日に master branch にマージされたコードに対して ˆ 朝、出勤してテストが通ったかどうかチェックできる ˆ テスト失敗した瞬間のスクショをまとめたレポート 隙があまり生じぬ二段構え ˆ 「定時内の開発 and レビュー and テスト」 ˆ 「深夜に全テスト」 コアな部分の修正にも安心感が増した
- 34.
- 35.
- 36.
- 39.
- 40. What happened? テストケースの増大 ˆ テストケースが600 越えてきた ˆ 1 テストケース 10 秒で終わるものもあれば 1 分かかる ものもある ˆ ログインして 3 画面ぐらい遷移してフォーム入力して… テストが遅いこと自体は問題ない
- 41. What happened? テストケースの増大 ˆ テストケースが600 越えてきた ˆ 1 テストケース 10 秒で終わるものもあれば 1 分かかる ものもある ˆ ログインして 3 画面ぐらい遷移してフォーム入力して… テストが遅いこと自体は問題ない テストが実行されていれば
- 42.
- 43. CI に任せてるから 大丈夫だよね？ 深夜に 1回走らせてはいるけど 1 時間半も掛かるテストを定時前に走らせるとか無理
- 44. 僕たちは安心を求めていた ˆ フルテストによってそれを担保していたはずだった ˆ フルテストが億劫になると ˆ最小限のテストだけ走らせるようになる ˆ 見ないふりし始める ( まあ大丈夫だろ 問題) ˆ 深夜のテスト実行まで待てないし手元で動かすのもめ んどくさい。リリースが大事だろ ( 任務遂行絶対 問題) ˆ その結果 ˆ エンバグ、デグレード多発 ˆ その他いろいろな事故リスク増大 「これでは駄目だ」 僕たちは安心を取り戻すために高速化を開始した
- 45.
- 46. 並列実行 (RSpec) 現状 ˆ Testrunner である RSpec を並列実行したい ˆ 参考: The Ruby Toolbox - Distributed Testing 今回は test-queue を採用 ˆ GitHub 本体のテストにも使われているライブラリ ˆ 既存 (RSpec) の環境をほぼそのまま使える ˆ 実行コマンドが rspec-queue に変わるだけ ˆ 暇なプロセスを作らず、テストをいい感じに分配
- 47. 実行例 $ bundle execrspec-queue spec/ ※ 数値はてきとうです
- 48.
- 49. ＼ Selenium Grid／ See: Grid2 SeleniumHQ/selenium Wiki
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64. 回避策思案 -App いっぱい- 「App+ DB」で 1 組のサーバを一杯立てれば？
- 65. 回避策思案 -App いっぱい- なんとなくいけそう ˆtest-queue の各プロセス毎に「この URL にアクセス して」と固定できるので、使えそう ˆ See: 参考ページ サーバ管理めんどくさい ˆ 構築だけでなく起動や終了も ˆ テストデータが更新されたら全サーバに rsync して restore して..
- 66.
- 68.
- 69. Docker Docker（ドッカー）はソフトウェアコンテナ内の アプリケーションのデプロイメントを自動化する オープンソースソフトウェアである。 Linux カーネルにおける LXCと呼ばれる Linux コン テナ技術と Aufs という特殊なファイルシステムを 利用してコンテナ型の仮想化を行う。 ˆ Docker - Wikipedia ˆ What Is Docker? An open platform for distributed apps
- 70. Docker を採用した理由は ただひたすら「手軽」に起動できる ˆ 環境(コンテナ) の起動や停止が速い ˆ 「テストしたい時」「特に必要ない時」でカジュアルに ON/OFF できる (数秒規模) ˆ やろうと思えば複数プロセス動かせる (※) ˆ 僕たちが望んだ「App + DB」の 1 環境ができる ※ 「1 コンテナ 1 プロセス」とよく言われるけど ˆ 起動して数分で消えるテスト環境のために「web」 「app」「db」に分割するのはコストが高すぎる ˆ 手軽な使い捨て環境 だし全部入りコンテナで良い
- 71.
- 72. 構成 -Docker 導入- (Cont’d1st) Dockerfile を作成する # Dockerfile FROM centos:centos6 COPY scripts/* /opt/scripts RUN sh /opt/scripts/install_dependency_libraries.sh && sh /opt/scripts/install_application.sh && sh /opt/scripts/restore_test_data.sh CMD service postgresql start && service httpd start && tail -f /var/log/httpd/access_log EXPOSE 80 $ # Docker コンテナイメージをビルド $ docker build -t app-php55 .
- 73. 構成 -Docker 導入- (Cont’d2nd) Fig (現 Docker Compose) を使う # fig.yml app: image: app-php55 ports: - "80" $ fig scale app=5 # 5 台起動 $ fig scale app=10 # 5 台追加で *計 10 台* 起動 $ fig scale app=3 # 7 台減らして *計 3 台* 起動
- 74. アプリコンテナを Docker で動かしてると ˆ seleniumnode も fig scale でぱぱっと起動したい ˆ この時点では オレオレ.sh で起動してた
- 75. 探してみた Docker Hub ˆ dockerbuild で作成されたイメージが置かれている ˆ Ubuntu 公式 だったり 個人で作ったもの だったり ˆ Dockerfile 公開してないとちょっと心配になる ありました ˆ registry.hub.docker.com/repos/selenium/ ˆ Selenium 開発コミュニティが出しているイメージ ˆ Dockerfile も GitHub に公開 されている
- 77. 最終形態 (準備) # fig.yml app: image:app-php55 ports: - "80" node: image: selenium/node # <= Docker Hub にあるやつ links: - hub hub: image: selenium/hub ports: - "4444:4444"
- 78. 最終形態 (召喚) $ figup -d hub $ fig scale app=15 node=15
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86. エンディング 以下を両立した Container-Based CIの誕生 ˆ テスト 10 分以内に終わる手軽さ ˆ 「なぜか失敗する」という暗黒の排除 僕たちは 安心と速度の両方を手にした
- 87.
- 88. 近況報告 無事 PHP のバージョン上げられました 1PHP 5.X と PHP 5.Y それぞれの Docker コンテナを用 意して検証 2 両方でテストが通るか。通らないなら何が原因か ˆ バージョンの違いによるものか、潜在的なバグか 複数バージョンを高速にチェックできてよかった
- 89. 近況報告 (Cont’d) 開発期間の変化 (高速化する前から取り組んでいましたが) ˆ以前までは 3 ヶ月 - 6 ヶ月などの長期間 ˆ 現在は 2、3 週間スプリントで回している ˆ 開発 (1、2 週間。この間はレビュー & 自動テスト チェックをメインに) ˆ 検証 (4 日間。メインの CHANGE に対する手動テスト) ˆ ふりかえり (1 日。本スプリントでの KPT) テストの高速化、および安定化の維持は良い効果
- 90. 現在の開発フロー 1 手元で開発 2 gitpush 3 GitHub で Pull Request (以下、PR) を作成 4 Jenkins Master が PR(commit) を検知し、そのブランチ を Jenkins Slave に教える 5 Jenkins Slave が教えられたブランチを元に Docker のア プリコンテナを起動 ˆ ついでに Selenium Hub/Node も起動 (停止していれば) 6 Integration test に加えて Unit Test も実行 7 約 10 分ぐらいでフルテスト完了 8 もし fail だったら修正を commit 。以後 4 - 7 を繰り 返す
- 91.
- 92. ずっと目指していた via full testalso want to end within 50ms // Speaker Deck
- 93.
- 94.
- 95.
- 96.