Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[2023/10/06 - Four Keysで改善する開発生産性] フロントエンド開発におけ...

Yukako IIDA
October 06, 2023

[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

Yukako IIDA

October 06, 2023
Tweet

More Decks by Yukako IIDA

Other Decks in Technology

Transcript

  1. 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
  2. 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
  3. 2 WX Unit の責務 フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ(@becyn, NewsPicks) Web プロダクトの基盤を 誰でも不安なく爆速で開発可能にし、

    より早くユーザーに価値を届ける = Web プロダクトに関するデプロイ頻度を division 単位で上げていきたい! ユーザにとっても、 開発者にとっても、 Experience ++ してくぞ! もちろん自分たちでも開発しつつ、
  4. 3 デプロイ頻度のブレーキ要因とは フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ(@becyn, NewsPicks) • main で build/lint/test が通らない

    • テストが通ったり通らなかったりする • 既存 component にどういったものがあるのかわからない • component の style 更新が原因でいつの間にか他ページで style 崩れが発生する • 既存機能の「正解」がわからず、担当者に聞く • ログ実装が複雑で実装に時間がかかる • どこにどういったテストを書けばいいのかわからない • そもそもリリースしていいのかわからない • リリース後に別ページで不具合が発覚 etc …
  5. 03 デプロイ頻度のブレーキ要因とは フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ(@becyn, NewsPicks) • main で build/lint/test が通らない

    • テストが通ったり通らなかったりする • 既存 component にどういったものがあるのかわからない • component の style 更新が原因でいつの間にか他ページで style 崩れが発生する • 既存機能の「正解」がわからず、担当者に聞く • ログ実装が複雑で実装に時間がかかる • どこにどういったテストを書けばいいのかわからない • そもそもリリースしていいのかわからない • リリース後に別ページで不具合が発覚 etc … これらを全部 テストと仕組み で
  6. 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
  7. 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)
  8. 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 が持つ責務が明確で、また保証されている
  9. 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 ◦ 正常パターン、異常パターンどちらもを実施するよう徹底
  10. • 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)
  11. 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 ✔ ✔ ✔ ✔ ✔ ✔ ✔
  12. • テストや仕組みは「基盤としての ”大丈夫” の価値観や認識のすり合わせの場」 普段触らない基盤でも安心してデプロイしてほしい(背中を押す存在でありたい) • これら基盤は、メンバーの「日頃の開発環境」 = 日常のルーティン =

    いつもの習慣 = 組織の文化 (になると願っている) • Web プロダクトの基盤で開発することで、 関わる開発者全員がデプロイ頻度を始めとする four keys に向き合える状態にした い 5 なぜテストや仕組みを大事にしているのか? フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ(@becyn, NewsPicks)
  13. • 頻度 ◦ 週に1度のレトロスペクティブ • 確認ポイント ◦ web, bff repository

    における生産性チェック ◦ 対象者:division の開発者全員 ◦ 使っているツール:Findy Team + ◦ 確認ポイント ▪ オープンからマージまでの平均時間 … 目標: 48h以内 ▪ PR のオープンからレビューの時間 … 目標: 24h以内 ▪ レビューからマージまでの平均時間 … 目標: 24h以内 ▪ 上記の移動平均推移(直近1週間&直近3ヶ月) ▪ 遅くなる原因となった PR や事象などを全員で確認する 実は現在スコアが下がってしまっているフェーズで打開策をみんなで出し合っているところ😇 改善がんばるぞ💪😭 5 Unit メンバー全員で、Unit だけでなく、Division 単位で振り返 る フロントエンド開発における、デプロイ頻度を上げるためのテスト設計のヒント イイダユカコ(@becyn, NewsPicks)
  14. 「Web プロダクトに関するデプロイ頻度を division 単位で上げていきたい!」 という思いをもとに、テストや周辺の仕組みを設計し、全ての環境に適用した • テストに対する考え ◦ 「これができれば大丈夫」の定義を形にしたもの ◦

    関わる人の目線を合わせるもの • テストや仕組みに求めること ◦ それぞれの接続部分の認識誤差がなく、疎通や安全性を担保できること ◦ それぞれの責務が全うされていることを担保できること • 工夫ポイント ◦ Web プロダクトを普段触ってないメンバーでもミスなくメンテできる習慣をつくる ◦ 開発してたら自動でテストが回るようにする ◦ 各テストの責務を定義し管理する ◦ 上記の取り組みに対して振り返る習慣を Unit 内で定着させる 6 まとめ