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

#merpay_techtalk Feature branchを使わないFeature開発

#merpay_techtalk Feature branchを使わないFeature開発

6ead85b132078f2f4f91a0caefbfb7c5?s=128

Kentaro "ku" KUMAGAI

March 18, 2021
Tweet

Transcript

  1. 1 Feature branchを使わないFeature開発 merpay Tech Talk 2021/03/18 Kentaro Kumagai @ku

  2. 2 • メルペイの開発手順のご紹介 • コンフリクトで困っていた • ブランチを作るのをやめてみた • 結果 本日の内容

  3. 3 1. Feature frameworkを生成する ./bin/init_framework.sh MerpayFooKit 2. Feature branchを作る git

    checkout -b feature/foo 3. デイリーでmainブランチをマージしつつ開発 4. feature/foo ブランチでメルカリアプリをビルドしてQA メルペイでの新機能開発
  4. 4 Featureってなに? ひとつの機能のこと ひとつのFeature = ひとつのモジュール = ひとつのframework = ひとつのブランチで開発

  5. 5 Featureってなに? ひとつの機能のこと ひとつのFeature = ひとつのモジュール = ひとつのframework = ひとつのブランチで開発

  6. 6 各feature frameworkごとにそのfeatureのみ が動く単体のサンプルアプリFooKitSampleを用 意して開発 • 動作確認に必要最低限の依存framework をリンク • ビルド時間が短いので快適

    FeatureごとのSampleアプリ
  7. 7

  8. 8 • コンフリクト ◦ なぜ起きるのか ▪ 共通のenumやLocalizable.stringsへの追加 ▪ 共通のコンポーネントへの機能追加 ◦

    30分もかからないが毎日起きるとばかにならない (1日の5% * 開発期間) • リリース時のマージ ◦ Featureのリリースが重なるとコンフリクトの解決が大変 (になる可能性) ◦ 本来はすべてのコードがマージされている状態で QAすべき 問題
  9. 9 • 開発中featureのコードもmainのブランチにマージ • リリースビルドにはfeatureのコードを含めない ◦ バイナリサイズ ◦ 機密保持 理想

  10. 10 • コンパイル時のフラグ #if ◦ 各featureの #if がたくさんあるとコードが読めなくなりそう ◦ リリース後に取り除くのもめんどくさい

    • 実行時のフラグ ◦ 上記の問題+ ◦ リリースの何ヶ月も前からバイナリに featureが含まれてしまう ◦ バイナリサイズ ブランチが嫌ならフラグを使えばいいじゃない
  11. 11 GUIのフロントエンドがありプロダクトマネージャー が管理 • Draft作成 → review → 反映 •

    中身はgit
  12. 12 今回試してみた方法 リンクしなければよくないですか by yusuke0518 • Featureのコードもmainにマージしていく • リリースビルドではfeatureのframeworkをリンクしない ◦

    開発はSampleアプリで進められるのでメルカリアプリにリンクしなくて も問題なし
  13. 13 1. Foo frameworkがないのを確認 2. strings Mercari 3. nm Mercari

    バイナリの検証
  14. 14 バイナリ(Mach-O)の文字列定数部分にある文字列を表示 strings

  15. 15 バイナリ(Mach-O)のシンボルテーブルを表示 nm

  16. 16 Activityの定義上enumに新機能のcaseを追加する必要がある enum Activity { enum Foo { case signup

    } case FooActivity } → raw valueがStringでなければ名前自体はバイナリに含まれない merpay固有の事情
  17. 17 共通のコンポーネントへの変更が必要にならない限り問題なし • 既存機能に影響が出ない拡張が大半 ◦ 影響がある変更だけこれまでどおりの branch運用 • 既存機能を意図せず変更しないようにスクリプトでチェック https://github.com/ku/warn-if-outside-of

    運用してみて
  18. 18 ★ 新機能もmainのブランチにマージできてコンフリクトを最小化 ★ リリースビルドにはfeatureのコードは含まれない ◦ バイナリサイズも増えない ◦ 機密も漏れない Frameworkを分離していると可能なのでおすすめです

    まとめ