30万行を超えるCMSのNuxt3移行戦略【Yappli Tech Conference 2023】

Transcript

1. 30万 行 を超えるCMSの Nuxt 3 移 行 戦略
2. 01 02 03 04 Yappliのフロントエンドについて🛁 アップデート計画🤔 アップデート前準備💪 得られた学び📚
3. 01 Yappliの フロントエンドについて🛁
4. 0 1 Yappliのフロントエンドについて Yappliのフロントエンド業務 Yappliの主なフロントエンド領域はアプリを作る管理画 面 です。 例えば… • 既存機能の運 用 や保守 • 新機能の提案や開発 • Storybookを 用 いたデザインシステムの構築 • etc.
5. 0 1 Yappliのフロントエンドについて Yappliのフロントエンド業務 Yappliの主なフロントエンド領域はアプリを作る管理画 面 です。 例えば… • 既存機能の運 用 や保守 • 新機能の提案や開発 • Storybookを 用 いたデザインシステムの構築 • etc.
6. プロダクトの規模 • コード 行 数：約 33 万 行 • コンポーネント数：約 1,400 コンポーネント • ページ数：約 100 ページ フロントエンド5 人 と 一 部のバックエンド数 人 で 支 えている 0 1 Yappliのフロントエンドについて
7. 使ってる技術 • Nuxt 2 . 1 5 . 8 • Vue 2 . 6 . 1 4 • @nuxtjs/composition-api 0 . 3 2 . 0 • TypeScript 4 . 2 . 4 ※2023-09-15時点 0 1 Yappliのフロントエンドについて
8. 02 アップデート計画 採 用 しているNuxt 2 について 2023年末でサポートが終了😭 年内にNuxt 3 にアップデートする必要がある。
9. 02 アップデート計画🤔
10. 02 アップデート計画 取り組むこと 1 . アップデート前の準備 2 . Nuxt 2 . 1 7 へのアップデート 3 . Nuxt Bridgeの導 入 4 . Bridgeの段階導 入 5 . Nuxt 3 へのアップデート
11. アップデート前の準備 Nuxt, Vue 共に破壊的変更が結構ある。 プロダクト規模も前述の通りのため、 入 念に事前調査しながら、 アップデート前に対応できる変更や依存関係の整理から取り組 む。 02 アップデート計画
12. Nuxt 2 . 1 7 へのアップデート 2023年頭にNuxt 2 . 1 6 がリリースされ、続いて2.17もリリースされ た。後続のNuxt Bridgeに向けアップデートが必要。他にも • Vue 2 . 7 （script setup, Composition API） • Node.js 2 0 +をサポート など、年内をNuxt 2 で戦うための重要なアップデート。 02 アップデート計画
13. Nuxt Bridgeの利 用 プロダクト規模もそれなりのため、アップデート作業には 工 数が かかる上に相応のビジネスリスクも伴うため、切り戻しやすいよ うに段階的に進めたい。 Bridgeがあれば、途中で3直 行 もできるため選択肢が多くなる🥰 02 アップデート計画
14. Nuxt Bridgeの利 用 Bridgeのリリース当初は不安定で、ドキュメントや事例など情報 不 足 だったが、メンテナの 方 々の尽 力 でかなり安定してきた。 近々、RC版も出る🎉 02 アップデート計画
15. Nuxt 3 へのアップデート ビッグバンリリースを避けるために段階的にリリースしたいが、 2→3はどうしても 大 きなリリースになるのは不可避… ➡カナリアリリースなどの公開範囲を絞るリリースを検討。 02 アップデート計画
16. 02 アップデート計画 取り組むこと 1 . アップデート前の準備 2 . Nuxt 2 . 1 7 へのアップデート 3 . Nuxt Bridgeの導 入 （👈イマココ） 4 . Bridgeの段階導 入 5 . Nuxt 3 へのアップデート
17. 03 アップデート前準備💪
18. アップデートの前に… • 計画時点で対応事項が 100 個ぐらいあった。 • これらを 長 期的に安全にアップデートをしていく必要がある。 • リソース都合で 一 時的に1 人 でやらないといけない😇 03 アップデート前準備
19. アップデートの前に… • 計画時点で対応事項が 100 個ぐらいあった。 • これらを 長 期的に安全にアップデートをしていく必要がある。 • リソース都合で 一 時的に1 人 でやらないといけない😇 ➡ 大 量の対応を少ないリソースで品質を担保しながら進める必要 がある🤔 03 アップデート前準備
20. 自 動化だ！🦾🤖🦾 03 アップデート前準備
21. 自 動化 1 . ESLint のカスタムルールを使う 2 . VRT (Visual Regression Testing) をする 03 アップデート前準備
22. 自 動化 1 . ESLint のカスタムルールを使う 2 . VRT (Visual Regression Testing) をする 03 アップデート前準備
23. ESLint のカスタムルールを使う💪 Vue 公式の eslint-plugin-vue で破壊的変 更の多くを対応できる。 …が、プロダクトには放置された 非 推奨 コードが多く、pluginだけでカバーできな い形式のものが結構あった（数百件🫠 03 アップデート前準備 - 自 動化
24. Vue の SFC の書き換え (SFC→AST→SFC) は vue-eslint-parser とESLintのカスタムルールでできるので 自 作する✍ ESLint のカスタムルールを使う💪 ➡ ➡ ➡ ✨ ✨ 03 アップデート前準備 - 自 動化
25. 🎉
26. Linterで防げれば 非 推奨コードも 早期& 自 動で排除できる👍 03 アップデート前準備 - 自 動化
27. 自 動化 1 . ESLint のカスタムルールを使う 2 . VRT (Visual Regression Testing) をする 03 アップデート前準備
28. なんで VRT？🤔 1 . Yappliの開発フローとの相性 2 . テストのためのコスト 3 . バージョンアップとの相性 03 アップデート前準備 - 自 動化
29. 1 . Yappliの開発フローとの相性 03 アップデート前準備 - なんでVRT？🤔 実装 コード レビュー 個別QA 週次QA リリース 週次QAとリリースは週に1回
30. 実装 コード レビュー 個別QA 週次QA リリース バージョンアップでは影響範囲が広いので通常の個別QAは困難😿 03 アップデート前準備 - なんでVRT？🤔 1 . Yappliの開発フローとの相性
31. 実装 コード レビュー 個別QA 週次QA リリース かといって週次QAを待つと 手 戻りが多くなる可能性🙀 03 アップデート前準備 - なんでVRT？🤔 1 . Yappliの開発フローとの相性
32. 実装 コード レビュー 個別QA 週次QA リリース 実装段階で早めに広範囲の動作確認を低コストに実施したい → 自 動テストが有効そう✅ 03 アップデート前準備 - なんでVRT？🤔 1 . Yappliの開発フローとの相性
33. 2. テストのためのコスト 元々コンポーネントのテストが不 十 分（StoreとUtilしかない）か つコンポーネントはStoreにめちゃくちゃ依存している🙀 単体 ・ 結合レベルのテストをするには、まずコンポーネント 自 体 のテスタビリティを向上する必要がありそう… 03 アップデート前準備 - なんでVRT？🤔
34. https://autify.com/ja/blog/refactoring-or-testing-ja 2. テストのためのコスト 03 アップデート前準備 - なんでVRT？🤔
35. https://autify.com/ja/blog/refactoring-or-testing-ja 2. テストのためのコスト 03 アップデート前準備 - なんでVRT？🤔
36. https://autify.com/ja/blog/refactoring-or-testing-ja 2. テストのためのコスト 03 アップデート前準備 - なんでVRT？🤔 E 2 Eが合いそう✅
37. 3. バージョンアップとの相性 バージョンアップで確認したいことは、バージョンアップ後の 環境と本番環境が同じ動作であること。 🤝 本番 検証 03 アップデート前準備 - なんでVRT？🤔
38. E 2 Eの中でもVRTが良さそう💡 03 アップデート前準備 - なんでVRT？🤔
39. VRTするぞ！ 03 アップデート前準備 - なんでVRT？🤔
40. https://playwright.dev/
41. なんでPlaywright？ • VRTも普通のE 2 Eもどちらもできる • 並列実 行 が最 高 • Auto-waitのおかげで、多少の不安定さを 吸収してくれる • 使うのが初めてでも、直感的に書ける！ 03 アップデート前準備 - なんでVRT？🤔
42. 🎉
48. 僅かな差分も検知できる✅ 03 アップデート前準備
49. これで万全のバージョンアップ体制ができた🥳 03 アップデート前準備
50. 04 得られた学び📚
51. 1 2 ”仕組み”でプロダクトを維持すること 自 動化の偉 大 さ • 非 推奨なコードや依存関係は意識しないと放置されがち。 • 日 頃から妥協せず、早めに摘む。（「後で直す」は 大 体直さない🫠） • 維持する仕組みを作ろう！（静的解析、CI、啓蒙活動など） • 定期的に 見 直す 文 化を作ることでも、チームにも維持する意識が芽 生 える。 • プロダクトが 大 きくなるほど、 人力 だけで対処できなくなる。 • 自 動化のメリットはプロダクトが 大 きくなるほど、時間が経つほどに増 大 する。 04 得られた学び📚
52. VERSION UP VOYAGEは まだ始まったばかり…👨🚀