Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Talk about CI and testing of the STORES
Search
hogelog
November 08, 2023
Programming
2
390
Talk about CI and testing of the STORES
STORES Tech Talk - STORESのRailsを語る会の登壇「STORES ネットショップのCIとかテストについて話します」資料です。
hogelog
November 08, 2023
Tweet
Share
More Decks by hogelog
See All by hogelog
小3の子がいるエンジニアの昔と今。
hogelog
0
1.1k
Kaigi_on_Rails_2022_Talk-hogelog.pdf
hogelog
3
1k
クックパッドインターンシップ 2018 API 編(前半)/ Cookpad internship 2018 Day 3: API
hogelog
0
9.4k
クックパッドの巨大 Rails アプリケーションの改善
hogelog
11
10k
自分相手にアプリケーションをつくり得られるもの
hogelog
0
900
Other Decks in Programming
See All in Programming
Fast JSX: Don't clone props object #28768
yossydev
1
130
Git Lint
bkuhlmann
4
750
大規模UIKitベースアプリへのTCAの段階的導入/gradual-adoption-of-tca-in-a-large-scale-uikit-based-app
takehilo
1
180
冗長なエラーログを削減し、スタックトレースを手に入れる / Reducing Verbose Error Logs and Obtaining Stack Traces
upamune
0
840
『Railsオワコン』と言われる時代に、なぜブルーモ証券はRailsを選ぶのか
free_world21
0
270
単体テストを書かない技術 #phpcon_odawara
o0h
PRO
27
8.3k
二郎系ラーメンのコールで学ぶ AST 解析
memory1994
PRO
7
1.7k
Let's learn code review
riofujimon
2
520
コーンフレークから始める モデリング会話入門
ogurotakayuki
0
380
PHPの次期バージョンはこの時期どうなっているのか - Internalsの開発体制について - PHPカンファレンス小田原
youkidearitai
PRO
1
190
Goのmultiple errorsについて (2024年4月版)
syumai
4
990
MicrosoftのPlatform Engineeringガイドを読んで実際になにかやってみた
ymd65536
1
420
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
60
14k
Why Our Code Smells
bkeepers
PRO
331
56k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
121
39k
Code Reviewing Like a Champion
maltzj
514
39k
Building Your Own Lightsaber
phodgson
99
5.7k
Building Adaptive Systems
keathley
31
1.9k
Optimising Largest Contentful Paint
csswizardry
8
2.4k
What the flash - Photography Introduction
edds
64
11k
From Idea to $5000 a Month in 5 Months
shpigford
377
45k
Visualization
eitanlees
136
14k
Imperfection Machines: The Place of Print at Facebook
scottboms
260
12k
Transcript
STORES 株式会社 STORES ネットショップのCIとかテストに ついて話します 2023-11-08 @hogelog CTO室技術基盤グループマネージャ 小室 直
2023年11月
自己紹介 技術基盤グループ マネージャ @hogelog ウェブ企業でサービス開発エンジニア、基盤領域エンジニアやマ ネージャーを経由して、現在はまたエンジニアマネージャに。 サーバサイドとインフラの間や組織と組織の間に落ちているボー ルを拾うのが割と好きです。
CIとは 3 - CI = Continuous Integration(継続的インテグレーション) - CIでは色々なものを動かします -
テスト - Lint - ……
STORES ネットショップのテスト 4 - STORES ネットショップのRailsアプリケーションのテストに関し てあれこれ雑多に紹介します
STORES ネットショップのテスト行数推移 5 - 2023年11月現在: 22万6185行 - `find spec -type
file -name '*.rb' | xargs wc -l`
CI実行環境と実行時間 6 - CI実行環境: CircleCI - 10m+ もしばしば☔
ある程度以上規模のRailsアプリケーションテストの問題 7 - 問題 - 結果が不安定 - 時間がかかる - お金がかかる
- なんとかする - 不安定なテストの改善 - テストの高速化 ( )≒ 時間がかかる
不安定なテストの安定化
テスト安定化: タイミング問題で落ちるテストの修正 9 - 複数データが同一秒に作成されると落ちるテスト - 複数データが同一秒に作成されないと落ちるテスト - 他
テスト安定化: 不安定なテストの改善(レスポンスのブラウザキャッシュ) 10 - feature specでブラウザがレスポンスをキャッシュしてしまい実 行順によっては失敗する場合があった - 現在はテスト実行時は `expires_in`
を無効化している - 後日ブログで再現コードや他の解決方法について解説します module DisableBrowserCacheDuringTest def expires_in(seconds, options = {}) if seconds == 0 super end end end ActionController::ConditionalGet.prepend(DisableBrowserCacheDuringTest)
テスト安定化: 不安定なテストの改善(遅い回線のエミュレート) 11 - CIでネットワークが詰まった時に不安定になるテストを見つけるた めの遅い回線のエミュレート if ENV["CAPYBARA_EMULATE_SLOW_NETWORK"] emulate_network_config =
{ latency: 100, # 100ms download_throughput: 64 * 1024 / 8, # 64Kbps upload_throughput: 64 * 1024 / 8, # 64Kbps } elsif ENV["CAPYBARA_EMULATE_NETWORK_CONFIG"] emulate_network_config = JSON.parse(ENV["CAPYBARA_EMULATE_NETWORK_CONFIG"], symbolize_names: true) end if emulate_network_config Capybara.current_session.driver.browser.devtools.network.emulate_network_conditions(offline: false, **emulate_network_config) end
テスト安定化: 不安定なテストの改善(集計と継続的取り組み) 12 - 不安定なテストをスプレッドシートに集計、可視化し改善に日々取 り組み
テスト安定化: rspec --only-failures 13 - 実行に失敗したテストのみ再実行するフラグ - 不安定なテスト失敗時、テストを全て実行しなおす時間をスキップ できる
テスト安定化: rspec-retry 14 - 実行に失敗したテストのみ再実行するgem - 同一rspec実行プロセスの中で再実行されるので--only-failuresよ りも速いことが期待できる
テスト再実行系ソリューションの注意点 15 - 不安定なテストが気づかぬうちに増えていく - 不安定なテストが増えると実行時間も伸びる - 継続的な改善活動に取り組んでいない場合、必ず不安定なテストは 増えていきます -
CircleCIならばCircleCI Insightsなどを見るのもオススメ - そもそも再実行系ソリューションは可能な限り導入を避けたい
テストの高速化
テスト高速化: Capybara.default_max_wait_time の調整 17 - feature specの失敗時、Capybara.default_max_wait_time時間 待つ場合があるので、長すぎない程度の適切な時間を設定 - 現在の設定:
`default_max_wait_time = 10`
テスト高速化: 大量に作られるテストデータの削減 18 - 検証したい条件に関連しない無駄なテストデータ作成を削減 - かなり地道 - 101.times {
|i| Fabricate.create(...) } + Fabricate.create(...)
テスト高速化: テスト分割と並列実行(CircleCI) 19 - 現在の設定: `parallelism: 16` - 💰
テスト高速化: テスト分割と並列実行(parallel_rspec) 20 - CircleCIのparallelismはマシンリソースを使いきれないので parallel_rspecで並列度を更に向上📈 - 複雑度も向上📈、悩ましい
テスト高速化: テスト分割と並列実行(parallel_rspec不安定テストの再実行) 21 - rspec-retry + 失敗したspecの再実行 - rspec-retryでは救いきれないパターンを再実行でカバー -
parallel_rspec x rspec --only-failures がうまく動かないので自 前スクリプトで before_result = File.read("tmp/test_results/failing_specs.log") failed_output = (before_result =~ /Failed examples:[\r\n]+(.+)/m && $1) failing_examples = failed_output.lines.map do |line| $1 if line =~ %r[rspec ('.+'|./spec/.+:\d+)] end.compact puts "Rerun #{failing_examples.size} examples" command = "bundle exec rspec --no-fail-fast -- #{failing_examples.join(" ")}" puts command exec command
テスト(CI)高速化: CircleCI workspaceの省サイズ化 22 - ジョブ間のデータ共有に用いるworkspaceの省サイズ化`rm -rf .git/ ...`
テスト(CI)高速化: 細かい改善 23 - テスト失敗あるときのみ `rspec --only-failures` 実行 - 無駄なapt-get
installの削減 - 他
テスト(CI)高速化: 遅いテストを観測し改善する継続的な取り組み 24 - 基本は rspec --profile - 集計しavg, p95など可視化すると効果的
- CircleCI Insightsなども有用
テスト安定化・高速化 25 - しばらくテスト安定化・高速化の取り組みがない、アクティブに開 発されているRailsアプリケーションは必ずテストが不安定になり 遅くなっています - CIの結果や設定ファイルをじっと見ると改善できる場所が必ず浮か んでくる -
できるまでやればできる
今後のテストについて 26 - CircleCI -> GitHub Actions, CodeBuild, Jenkins, …?
- 不安定なテスト、遅いテストがまた蓄積しつつある - To be continued...