「GENBA #2 〜Front-End Opsの現場〜」に参加してきました

• 2024/2/21
• https://timeedev.connpass.com/event/308783/

名刺アプリ Eight における Frontend Ops

• 鳥山 らいかさん

Frontend Ops

• https://www.smashingmagazine.com/2013/06/front-end-ops/
  • 2013年の記事
• フロントエンドでDevOps関連のタスクが増えた
  • ビルド,CI/CD,エラー監視,perf監視,依存アップデート
• ツールチェインで自動化高速化

EightでのFrontend Ops

• ビルド
  • Viteに寄せてる
  • Chunk分割
  • CSS Modules(ゼロランタイムがいい)
  • BabelからSWCへ
  • 設定のカスタマイズはあまりしない
    • ツールの移行とかで面倒にならないように
• CI/CD
  • ローカル
    • Lint/format
  • CI
    • テストビルド型チェック
      • 差分に関係ないjobは実行しないで時間やコスト削減
  • CD
    • ビルド結果をデプロイくらい
• キャッシュ
  • CDN
    • CloudFront
  • ブラウザ
    • 静的アセットにハッシュ付けて管理
    • ReduxやApolloでキャッシュも
  • CI/CD
    • npmpackageキャッシュしたり
• 監視
  • Datadog使ってる
    • Real User Monitoring
  • 関係ないエラーをフィルタしたり
  • RUMでCWVを計測
• アップデート
  • 週次Renovate
  • 重大なもの以外は3ヶ月に1回くらい

心がけ

• シンプルに保つ
  • メンテ大変にならないように
• マイナスをゼロにする開発に力を入れる
• アプリコードに手を入れないように

DangerJSを導入してPRレビューを効率化しよう

• mayuko nittaさん

Danger JS

• https://danger.systems/js/
• CIプロセスでコードレビューしてくれる
• PR作成をフックにコードをチェックしてコメント投稿までできる
  • 投稿はmdで書ける
  • 行数チェック
  • 文字列チェック
    • console.log残ってないかとか

導入時

• プッシュしてPR作らないと設定のチェックができず面倒
  • dangerのテストを書くと事前にチェックできる

導入して

• 機械的なチェックでレビューにかける工数が減った
• いろいろチェックしたいことが出てきた
  • commitした画像容量チェック
  • typoチェック
  • PRのsuggestの活用も

スタートアップのフロントエンド事情

• 蝦名 潤さん

スタートアップでの開発

• 1人でMVPを素早く作る必要があった
  • BEはrailsでFEはReact
• モノリスなSPAにした
  • erbの中でReactを読み込むところがエントリーポイント
    • そこから先はReactの世界
  • ルーティングがないってこと？
• デプロイがシンプルでCI/CDが楽
  • エントリーポイント以外は疎結合
• Rails環境に依存してしまったのが懸念
  • Nodeのバージョンあがるのが遅い？
• 今後インフラを分離
  • ビルドしたものをCDNにデプロイ

いつか来たる大改修のために備えておくべきn個のこと

• 西浦太基さん

大改修の事例

• Rails+jQueryをReact+Nextにした
• 段階的にリプレース
• その時の知見

泥臭かったこと

• 仕様がドキュメントにのこってない
  • ソースをみて調査するしかない
• ユニットテストはあったがE2Eはなかった
  • 手動でテストした
• レビュー体制が整ってなかった

備えておくべきこと

• 機能の仕様は背景込みで残す
  • エッジケースなど残してるといい
• テスト自動化の仕組みを導入
  • UTとVRTがあってもE2Eは大事
• レビューの観点を明文化しておく
  • 同期的なやりとりが増えてしまわないように

コミュニケーションでフロントエンドの「広さ」に立ち向かう

• 山下翔太郎さん

FEの知識の広さ

• FEの知識が広く
• タイミーFEエンジニア
  • featureチームに数人FEエンジニアが入る感じ
  • 横断組織ののchapterもあるがメインはfeature
• 課題
  • スコープが広く横断課題が積み重なる
  • 属人化しやすい
• 広さに立ち向かう体制が整っていない
• 改善の取り組み
  • 積まれた横断課題を整理し理想や方針の認識を合わせる
  • 課題起票だけで終わらないように改善デーを作ってで対応
• メンバー間の思考や課題感の違いを理解するコミュニケーションが大事
  • それをきっかけに改善を進めていく
• 今後
  • いろいろやってるから線でなく点になってることが多い
  • 旗を立て直す