ペンディングプロジェクトでの学び / What I learned from the Pending Project

社内で発表した資料から一部Confidentialな情報を削除したものです。

Transcript

1. ペンディングプロジェクトPh1での学び Nov 26th, 2020 Nishioka Kotaro CXI team Rakuten, Inc.
2. 2 ⽬次 - 概要 - 設計 - 開発 - テスト - QA - 監査 - リリース・監視 - Feature Toggleの使い⽅ - 今後の展望
3. 3 概要 Confidential
4. 4 設計 仕様調査 商品が表⽰される箇所全てを洗い出す必要がある。 RubyMineのパス内検索を活⽤。(grepとかでも良いと思う) Itemモデルのそれっぽいメソッドが呼ばれている箇所をかたっぱしから洗い出す。 さらにそのそれっぽいメソッドの中で呼ばれてるそれっぽいメソッドを洗い出す…という具合に抜け漏れない ように調べ上げる。 タイムライン 特定商品を除外するという既存の実装を参考に実装。 →問題発⽣…特定商品でタイムラインが埋め尽くされる場合商品が⼀切返らなくなる問題が起きる。 既存の実装に倣うのが必ずしも正解ではない。 むしろ古いコードは現状動いていたとしても何かしら問題を抱えてると疑ってかかるくらいの⽅が良さそう。
5. 5 開発 ブランチ Good • 変更量が膨⼤になることが予想されたため、レビューのことを考え、リリースブランチを作り、そこに対し て機能ごとにPRを作成した。 Bad • ⼀通り開発が終わった後にFTを⼊れることになったため、既に各機能がマージされたリリースブランチから ブランチを切ってまとめてFTを導⼊しPRを作成。FTの導⼊のみなのでレビューも⼤変ではないだろうと思 いきや、レビュワーとしては機能全体を把握する必要が出てくるのでレビューコストがヤバいことになる。 →結局チーム内レビューで対応。FTを導⼊するだけでもブランチは機能ごとに分けた⽅が良い。できればFT を導⼊するかどうかは⾒積もりの段階で話し合っておく⽅がベター。(スケジュール的にも) • リリースブランチに対して直接コミットしない。→どのコミットがapproveされてるのか分からなくなり、 リリース前⽇に⼿作業でコミットを集計し直す⽻⽬に…。 パフォーマンス N+1問題を防ぐ→Bulletを活⽤しよう。(開発機)
6. 6 テスト 複数のFTのkey(購⼊者側と出品者側)の組み合わせによってテストケースが複雑化。 Mindmapを使って抜け漏れないようテストケースを網羅して実施。 →しかし後のQAで指摘が…境界値に着⽬したテストをすべき • 最⼤ケース • コーナーケース
7. 7 QA 機能追加・修正の影響範囲が多岐にわたっているため、既存の問題・仕様で多数のチケットが切られる。 • Confidential • STGのGSPはかなり遅延する。下⼿すると30分くらい。 切り分けをどうするか。 • コードを読む。→仕様理解。 • ログを読む。→キャッシュ絡みで挙動が変わる • 別環境と⽐較して差分があるか(STGとQA01)
8. 8 監査 エンドポイントの⼀覧とパラメータを提出する必要がある。 Githubのpostmanリポジトリにまとまっている。
9. 9 リリース・監視 FT⼊れていても100%安全ではない。 FTを上げるときよりもむしろリリース直後に注意すべき。 →FTを上げるときの変化に注⽬していてリリース前との変化を注視してなかった New RelicやDatadogを使ってレスポンスタイムとエラー数をチェック。 →レスポンスが遅すぎる場合Webサーバーでエラーになってレスポンスタイムに影響が⾒られないので、 Datadogでエラー数を監視することが⼤事。
10. 10 Feature Toggleの使い⽅ Feature Toggleに渡す値としてuserのインスタンスが必要。 →安易にUser.findするとパフォーマンスに影響が出る。 呼び出し回数が多そうな箇所(bulk~みたいなバッチは危ない)はOpenStructを使うことでDBへの負荷を減らせ る。(Email指定できなくなるので注意。) FTのかかる範囲を最⼩限にする。 if FeatureToggle hoge && fuga && piyo end ではなく hoge && fuga && piyo def piyo if FeatureToggle … end end
11. 11 今後の展望 リリースサイクルを短くしたい QA中に別プロジェクトの変更で、とあるモデルが削除され、そのモデルのメソッドを使っていたためエラーが 発⽣することがあった。 開発が⻑期化すると他プロジェクトの影響を受ける可能性が⾼くなる。 競合をなくすためには、新規テーブル・モデルの作成など既存の機能から切り離されている部分や、FTを⼊れ るなどして本番で動かない状態のコードはこまめにリリースすると良さそう。 理想はGoogleなどでやられているトランクベース開発︖(各⾃が変更を毎⽇masterブランチに反映させる)