[2023/10/06 - Four Keysで改善する開発生産性] フロントエンド開発における、 デプロイ頻度を上げるための テスト設計と仕組みづくりのヒント / Tips for designing and structuring tests to increase deployment frequency in front-end development

2023/10/06にオンラインでタイミーさんと共同開催させてもらった「Four Keysで改善する開発生産性〜データ・モバイル・フロントエンド〜」での資料です。

https://uzabase-tech.connpass.com/event/294494/

===

セクション②
フロントエンド開発における、デプロイ頻度を上げるためのテスト設計と仕組みづくりのヒント

https://www.youtube.com/live/mrfTRtL8gOI?feature=shared&t=1856

Transcript

1. フロントエンド開発における、 デプロイ頻度を上げるための テスト設計と仕組みづくりのヒント 2023.10.06@Four Keysで改善する開発生産性〜データ・モバイル・フロントエンド〜 NewsPicks Web Engineer / イイダユカコ
2. 1 自己紹介 フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 2013 年 4 月より 株式会社 CyberaAgent にサーバーサイドエンジニアとして入社。 2015 年 12 月より 社内異動をきっかけにフロントエンドエンジニアとして従事。 2019 年 9 月より 株式会社ユーザベースにエンジニアとして入社。 フロントエンド領域の開発をメインに、design system の推進、 Observability（o11y）& Accessibility（a11y）の布教活動などを行う。 現在は Web プロダクトのメインメンテナーを担当する Web Experience Unit のリーダーを担当しています。 Unit では、Web プロダクトにおける Re-architecture & Design renewal project 推進中 💪 イイダ ユカコ NewsPicks Web エンジニア @becyn on
3. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 1 フロントエンド開発における、 デプロイ頻度を上げるための テスト設計と仕組みづくりのヒント
4. 2 NewsPicks の開発現場の紹介 フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） NewsPicks Product Division（全16Unit、約100名の組織） 内 12 Unit が開発を担当する Unit WX Unit は現在 FE2名、BE2名の Unit WX Unit dev dev dev dev dev dev dev dev dev dev dev dev
5. 2 その中で Web Experience Unit（以下, WXUnit）とは フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 2023年10月も、WX Unit ＋ 3 Unit が Web プロダクトを並列で開発中 WX Unit Division の半数が触る可能性のある Web プロダクトのメインメンテナー dev dev dev dev dev dev dev dev dev dev dev dev
6. 2 WX Unit の責務 フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） Web プロダクトの基盤を 誰でも不安なく爆速で開発可能にし、 より早くユーザーに価値を届ける ＝ Web プロダクトに関するデプロイ頻度を division 単位で上げていきたい！ ユーザにとっても、 開発者にとっても、 Experience ++ してくぞ！ もちろん自分たちでも開発しつつ、
7. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 3 Q. デプロイ頻度を 上げるにはどうする🤔？
8. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 3 A. ブレーキ要因を全部潰す💪
9. 3 デプロイ頻度のブレーキ要因とは フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） • main で build/lint/test が通らない • テストが通ったり通らなかったりする • 既存 component にどういったものがあるのかわからない • component の style 更新が原因でいつの間にか他ページで style 崩れが発生する • 既存機能の「正解」がわからず、担当者に聞く • ログ実装が複雑で実装に時間がかかる • どこにどういったテストを書けばいいのかわからない • そもそもリリースしていいのかわからない • リリース後に別ページで不具合が発覚 etc …
10. 03 デプロイ頻度のブレーキ要因とは フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） • main で build/lint/test が通らない • テストが通ったり通らなかったりする • 既存 component にどういったものがあるのかわからない • component の style 更新が原因でいつの間にか他ページで style 崩れが発生する • 既存機能の「正解」がわからず、担当者に聞く • ログ実装が複雑で実装に時間がかかる • どこにどういったテストを書けばいいのかわからない • そもそもリリースしていいのかわからない • リリース後に別ページで不具合が発覚 etc … これらを全部 テストと仕組み で
11. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 3 そもそも「テスト」とは、 • 「これができれば大丈夫」の定義を形にしたもの • 関わる人の目線を合わせるもの と考えているので、決して無理マッチョなことを言ってないと思ってる
12. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 4 具体の話
13. 4 WX Unit が関係するプロダクトのアーキテクチャ(略図) フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） DB App Server Java/Kotlin project GraphQL Next.js project API & Web 用 rendering を担う、Spring base で作られた project。 re-architecture 未対応ページについては NP Server にリクエストする。 最終的に API に特化した project になることを目指す（Web を切り離す） 初回来訪時 Next.js project 内の ページ遷移時に発生する API Request 対応状況により path ごとに振り分け （Path-based routing） Web Client TypeScript project Web server ELB
14. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 4.a なにが担保されていると 安心できるか？
15. 1. ELB を用いた path-based routing が意図通りに機能している 2. 受け取った API のデータを BFF を介して Web で表示ができている 3. Web からの Request を BFF を介して API に送り、 200 OK が返ってくる 4. BFF から Web に返すデータの型が match している 5. component が意図するデータの型で情報を受け取り、表示できている 6. component の props に対して表示に影響するデータを全て網羅できている 7. component のリファクタリングをした際、変更 diff が意図したものになっている a. 意図した影響があるか、もしくは、影響が出ていないかを確認できる 8. 各所 utils において、その method が持つ責務が明確で、また保証されている 4.a 8つの「これができているから大丈夫」を証明したいもの NewsPicks Web プロダクトの場合 フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks）
16. 4.a フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 2行で表すと、 • それぞれの接続部分で互いに認識差異がなく、 疎通や安全性を担保できること • それぞれの責務が全うされていることを担保でき ていること これらをテストで満たすことで、「大丈夫だ」と表現、立証できている状態にする
17. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 04.b どう証明するか
18. 4.b どういったテスト/仕組みで網羅しているか • Observability tools（NewRelic） 1. ELB を用いた path-based routing が意図通りに機能している • e2e test（MagicPod） 1. 受け取った API のデータを BFF を介して Web で表示ができている 2. Web からの Request を BFF を介して API に送り、 200 OK が返ってくる • 型定義で担保 1. BFF から Web に返すデータの型が match している 2. component が意図するデータの型で情報を受け取り、表示できている • Visual Regression Testing 1. component の props に対して表示に影響するデータを全て網羅できている 2. component のリファクタリングをした際、変更 diff が意図したものになっている • Unit Test 1. 各所 utils において、その method が持つ責務が明確で、また保証されている
19. 4.b テスト/仕組みを運用していく上での工夫ポイント • Observability tools（NewRelic） ◦ 開発中から本番まで、どの環境でも確認環境を構築 ◦ 意図せぬページ遷移発生時にエラー通知 • e2e test（MagicPod） ◦ Re-architecture したページリリースのタイミングで全てのページに対して追加管理を徹底 • 型定義で担保 ◦ BFF で schema 定義が更新されたタイミングで web リポジトリに型定義ファイル更新 PR を自動生成 ◦ Fragment Colocation を採用し、component と型定義を密な状態にして型と文脈を管理＆認識齟齬防止 • Visual Regression Testing ◦ PageComponent も含めた全ての component、全ての表示パターンに対する Story をもとにテストを実施 ◦ VRT 時の ViewPort を Mobile サイズ、Desktop サイズの2サイズで実施しレスポンシブのチェック • Unit Test ◦ 正常パターン、異常パターンどちらもを実施するよう徹底
20. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 4.c どう継続/習慣化させるか
21. • Web プロダクトを普段触ってないメンバーでもミスなくメンテできる習慣をつくる ◦ component を実装する際、hygen を使って実装ファイルとテストファイルを同時に自動生成 ◦ 現在、自動生成されるテストファイル例 ▪ component の Storybook ファイル ▪ Storybook を用いた a11y-jest のテストファイル ▪ testing-library の rendering チェックテストファイル • 開発してたら自動でテストが回るようにする ◦ GitHub Actions で build / lint / a11y Violation check / VisualRegressionTesting が走るよう設定 ◦ 「正直 XX に対してどう気をつければいいかわからん」という状況でも開発フローの中で課題を認識可能 • 各テストの責務を定義し管理する ◦ メンテナンスが高コストにならないよう、責務を超えるテストを排除 ▪ 結果、必要最低限で、かつ “Flaky Test” が発生しない環境づくりに繋がった 🎉 4.c テスト/仕組みを設計する上で気をつけていること フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks）
22. 4.c WX Unit が関係するプロダクトのアーキテクチャ(略図) フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） DB App Server Java/Kotlin project GraphQL Next.js project API & Web 用 rendering を担う、Spring base で作られた project。 re-architecture 未対応ページについては NP Server にリクエストする。 最終的に API に特化した project になることを目指す（Web を切り離す） 初回来訪時 Next.js project 内の ページ遷移時に発生する API Request 対応状況により path ごとに振り分け （Path-based routing） Web Client TypeScript project Web server ELB ✔ ✔ ✔ ✔ ✔ ✔ ✔
23. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 5 なぜ大事にしているの？ 正直そこまでしなくてもプロダクトは動くし、デプロイはできるくね…🤔？
24. • テストや仕組みは「基盤としての ”大丈夫” の価値観や認識のすり合わせの場」 普段触らない基盤でも安心してデプロイしてほしい（背中を押す存在でありたい） • これら基盤は、メンバーの「日頃の開発環境」 ＝ 日常のルーティン ＝ いつもの習慣 ＝ 組織の文化 （になると願っている） • Web プロダクトの基盤で開発することで、 関わる開発者全員がデプロイ頻度を始めとする four keys に向き合える状態にした い 5 なぜテストや仕組みを大事にしているのか？ フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks）
25. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） Unit で一番大事にしてること
26. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 定期的継続的に Unit 全員で振り返ること
27. • 頻度 ◦ 週に1度のレトロスペクティブ • 確認ポイント ◦ web, bff repository における生産性チェック ◦ 対象者：division の開発者全員 ◦ 使っているツール：Findy Team + ◦ 確認ポイント ▪ オープンからマージまでの平均時間 … 目標: 48h以内 ▪ PR のオープンからレビューの時間 … 目標: 24h以内 ▪ レビューからマージまでの平均時間 … 目標: 24h以内 ▪ 上記の移動平均推移（直近1週間＆直近3ヶ月） ▪ 遅くなる原因となった PR や事象などを全員で確認する 実は現在スコアが下がってしまっているフェーズで打開策をみんなで出し合っているところ😇 改善がんばるぞ💪😭 5 Unit メンバー全員で、Unit だけでなく、Division 単位で振り返 る フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks）
28. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） 6 まとめ
29. 「Web プロダクトに関するデプロイ頻度を division 単位で上げていきたい！」 という思いをもとに、テストや周辺の仕組みを設計し、全ての環境に適用した • テストに対する考え ◦ 「これができれば大丈夫」の定義を形にしたもの ◦ 関わる人の目線を合わせるもの • テストや仕組みに求めること ◦ それぞれの接続部分の認識誤差がなく、疎通や安全性を担保できること ◦ それぞれの責務が全うされていることを担保できること • 工夫ポイント ◦ Web プロダクトを普段触ってないメンバーでもミスなくメンテできる習慣をつくる ◦ 開発してたら自動でテストが回るようにする ◦ 各テストの責務を定義し管理する ◦ 上記の取り組みに対して振り返る習慣を Unit 内で定着させる 6 まとめ
30. フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ（@becyn, NewsPicks） フロントエンド開発における、 デプロイ頻度を上げるための テスト設計と仕組みづくりのヒント ユーザにとっても、 開発者にとっても、 Experience ++ してくぞ！ @becyn on ご清聴、ありがとうございました！