Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

7

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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