名刺アプリ 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
- ビルド結果をデプロイくらい
- ローカル
- キャッシュ
- 監視
- Datadog使ってる
- Real User Monitoring
- 関係ないエラーをフィルタしたり
- RUMでCWVを計測
- Datadog使ってる
- アップデート
- 週次Renovate
- 重大なもの以外は3ヶ月に1回くらい
心がけ
- シンプルに保つ
- メンテ大変にならないように
- マイナスをゼロにする開発に力を入れる
- アプリコードに手を入れないように
DangerJSを導入してPRレビューを効率化しよう
- mayuko nittaさん
Danger JS
- https://danger.systems/js/
- CIプロセスでコードレビューしてくれる
- PR作成をフックにコードをチェックしてコメント投稿までできる
- 投稿はmdで書ける
- 行数チェック
- 文字列チェック
- console.log残ってないかとか
導入時
- プッシュしてPR作らないと設定のチェックができず面倒
- dangerのテストを書くと事前にチェックできる
導入して
スタートアップのフロントエンド事情
- 蝦名 潤さん
スタートアップでの開発
- 1人でMVPを素早く作る必要があった
- BEはrailsでFEはReact
- モノリスなSPAにした
- erbの中でReactを読み込むところがエントリーポイント
- そこから先はReactの世界
- ルーティングがないってこと？
- erbの中でReactを読み込むところがエントリーポイント
- デプロイがシンプルでCI/CDが楽
- エントリーポイント以外は疎結合
- Rails環境に依存してしまったのが懸念
- Nodeのバージョンあがるのが遅い？
- 今後インフラを分離
- ビルドしたものをCDNにデプロイ
いつか来たる大改修のために備えておくべきn個のこと
- 西浦太基さん
大改修の事例
泥臭かったこと
- 仕様がドキュメントにのこってない
- ソースをみて調査するしかない
- ユニットテストはあったがE2Eはなかった
- 手動でテストした
- レビュー体制が整ってなかった
備えておくべきこと
- 機能の仕様は背景込みで残す
- エッジケースなど残してるといい
- テスト自動化の仕組みを導入
- UTとVRTがあってもE2Eは大事
- レビューの観点を明文化しておく
- 同期的なやりとりが増えてしまわないように
コミュニケーションでフロントエンドの「広さ」に立ち向かう
- 山下翔太郎さん
FEの知識の広さ
- FEの知識が広く
- タイミーFEエンジニア
- featureチームに数人FEエンジニアが入る感じ
- 横断組織ののchapterもあるがメインはfeature
- 課題
- スコープが広く横断課題が積み重なる
- 属人化しやすい
- 広さに立ち向かう体制が整っていない
- 改善の取り組み
- 積まれた横断課題を整理し理想や方針の認識を合わせる
- 課題起票だけで終わらないように改善デーを作ってで対応
- メンバー間の思考や課題感の違いを理解するコミュニケーションが大事
- それをきっかけに改善を進めていく
- 今後
- いろいろやってるから線でなく点になってることが多い
- 旗を立て直す
