概要
『【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜』に参加してきたので、簡単にレポートを書く。スライド未公開のものについては、公開されたら更新する。
発表
ペパボを支える大統一CI基盤と人々
- by ペパボ 谷口さん(@ravelll)
- 2015年までは10以上あるチームでそれぞれCIを管理していた
- 知見が独立していて他のチームの助けを得られない、罠を踏む
- 社内統一CI基盤がほしいというissueが立てられ、drone.io環境が社内に構築された
- ペパボではOSS版(0.4)をforkして使っている
- その結果、CI環境のトラブルが減った
- Jenkinsプラグインのバージョンアップで環境を壊すのが流行ってたけど、そういうのがなくなった
- 困ったときに誰にでも質問できる
- そもそも困る機会が少ない
- 課題もある
- drone.ioはジョブ数で判断するけど、実際の使用量で柔軟に判断してほしい
- masterのDocker daemonのメモリ使用量がどんどん増えていく
- 定期的に再起動して対応しているけど、原因調査したい
- Dockerfileのメンテナンスが属人的になる
- ハンズオンとかやるとよさそう
KARTEを支えるCI環境
スライド未公開
- by プレイド 野田さん(@positiveflat)
- 自由でフラットなチームで、スピード感のある開発を目指してる
- git-flowで開発
- pushするとCircleCIからAWS上に環境を構築して各テストを実行
- KARTEを埋め込むユーザーを模倣したサイトでテストを動かす
- CircleCIはインスタンスが非力なのでCircleCI Enterpriseへ移行
- CIの実行時間が長いのが課題、環境構築に時間がかかっている
- Dockerizeして環境構築の時間を削減するのが今後の課題
KARTE開発にマルチブラウザテストを導入・運用した話
スライド未公開
- by プレイド 笹森さん
- 過去のブログ記事
- KARTEはサイトに埋め込んでtracking + delivery（ユーザーによってダイアログとか表示したり）を行うサービス
- イメージ的にはGoogle Analyticsとかに近くて、顧客がサイトにJSを埋め込んでKARTEにデータを送る
- 埋め込まれているサイトの利用者が使用する様々なブラウザで動かないといけない
- IE8のバグやXHTMLの判定などで顧客に迷惑をかけてしまうケースが発生したためマルチブラウザテストをやることに
- BrowserStackを使用
- JSテストとE2Eテストの両方に対応していて、CircleCI連携のドキュメントがある
- テスト実行の録画機能もある
- JSテストはBrowserStack Runnerというnpmパッケージを利用
- KARTEでは接客対象ブラウザと接客対象外ブラウザでテストを分けている
- 接客対象外ブラウザではtracking自体行われないので、JSエラーが発生しないことだけをテスト
- 接客対象ブラウザではエンドユーザーの体験に関わる部分をテスト
- BrowserStack Localを使用してテスト実行環境からBrowserStackにつながるように穴を開ける
- 実行速度が遅いのがハマりどころ、リージョンの問題？
- モバイルはエミュレータの起動で落ちることがあるのでリトライ処理で対応
- 実機テストもあるが、こちらも起動に失敗したり録画機能が使えなかったりするので採用を見送り
- CIのキャンセルによってWebDriverのquitが呼ばれないとBrowserStackにキューが残り続けるので、契約プランによっては注意
- rapid plusプランを利用している(10並列/1並列につき4時間)
- 今後はテストケースの充実、実行時間の短縮とかをやりたい
トークセッション
- ペパボ谷口さんとプレイド笹森さんでトーク
- お互いの発表内容について質問しあったり、会場から質問を募集したり
- 会場でE2Eテストを自動化しているのは1割くらい
グーペのE2Eテスト運用事情
- by ペパボ バーチーさん(@hypermkt)
- グーペに1年半前にジョインしたときはユニットテストもE2Eテストもなかったけど、ビジネスの拡大に伴って自動化することに
- rspec, capybara, phantomjs, poltergeist
- 社内環境デプロイ時にE2Eテストを実行
- デザイナーが検証にも使っている環境
- 全ページが200を返すことを確認するテストと仕様どおりに機能することを確認するテストがある
- Jenkins環境にいろいろ課題があるので、Drone + Dockerの世界へ移行することが課題
並行・並列処理のテストは難しい
- by ペパボ 中野さん(@nakano_akihito]
- PHPでsnidelというマルチプロセス処理を手軽にできるライブラリを作っている
- 並行・並列処理のテストはタイミング問題が発生する
- Humble ObjectパターンとSizedQueueによるメッセージングで解決
所感
CIとE2Eテストの自動テストについて、ペパボさんとプレイドさんの2社の事例を聞けたのはとてもおもしろかった。特にマルチブラウザテストは、WebDriverがブラウザによって機能が異なる部分があるので難しいと感じていたけど、複雑な操作を行わなければ十分運用できるということが具体例としてわかった。
驚いたのは、会場でE2Eテストを自動化している人がほとんどいなかったこと。CIや自動テストに興味がある層が集まったはずの勉強会でこれだと、世の中的にはまだまだ当たり前になっていない分野なのだと感じた。懇親会で聞いた感じでは、やりたいけども組織的な問題で取り組めないという話が多かった。CIや自動テストは、技術的な問題よりも組織的な問題の方が解決が難しそう。
あと、E2Eテストの自動化は覚悟が必要という話でも盛り上がった。やはり、本体のサービスと同じレベルでコードをメンテナンスしていかないといけないし、テストコードが落ちたときのフローなど組織的な問題にも向き合わないといけないので、なかなか手軽には始めづらい。
今回のように実際の現場での知見が共有される機会が増えると嬉しいので、そういう場を増やしていきたい。
