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

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

3 1. Feature frameworkを生成する ./bin/init_framework.sh MerpayFooKit 2. Feature branchを作る git checkout -b feature/foo 3. デイリーでmainブランチをマージしつつ開発 4. feature/foo ブランチでメルカリアプリをビルドしてQA メルペイでの新機能開発

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

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

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

7

8 ● コンフリクト ○ なぜ起きるのか ■ 共通のenumやLocalizable.stringsへの追加 ■ 共通のコンポーネントへの機能追加 ○ 30分もかからないが毎日起きるとばかにならない (1日の5% * 開発期間) ● リリース時のマージ ○ Featureのリリースが重なるとコンフリクトの解決が大変 (になる可能性) ○ 本来はすべてのコードがマージされている状態で QAすべき 問題

9 ● 開発中featureのコードもmainのブランチにマージ ● リリースビルドにはfeatureのコードを含めない ○ バイナリサイズ ○ 機密保持 理想

10 ● コンパイル時のフラグ #if ○ 各featureの #if がたくさんあるとコードが読めなくなりそう ○ リリース後に取り除くのもめんどくさい ● 実行時のフラグ ○ 上記の問題+ ○ リリースの何ヶ月も前からバイナリに featureが含まれてしまう ○ バイナリサイズ ブランチが嫌ならフラグを使えばいいじゃない

11 GUIのフロントエンドがありプロダクトマネージャー が管理 ● Draft作成 → review → 反映 ● 中身はgit

12 今回試してみた方法 リンクしなければよくないですか by yusuke0518 ● Featureのコードもmainにマージしていく ● リリースビルドではfeatureのframeworkをリンクしない ○ 開発はSampleアプリで進められるのでメルカリアプリにリンクしなくて も問題なし

13 1. Foo frameworkがないのを確認 2. strings Mercari 3. nm Mercari バイナリの検証

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

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

16 Activityの定義上enumに新機能のcaseを追加する必要がある enum Activity { enum Foo { case signup } case FooActivity } → raw valueがStringでなければ名前自体はバイナリに含まれない merpay固有の事情

17 共通のコンポーネントへの変更が必要にならない限り問題なし ● 既存機能に影響が出ない拡張が大半 ○ 影響がある変更だけこれまでどおりの branch運用 ● 既存機能を意図せず変更しないようにスクリプトでチェック https://github.com/ku/warn-if-outside-of 運用してみて

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