Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
#merpay_techtalk Feature branchを使わないFeature開発
Search
Kentaro "ku" KUMAGAI
March 18, 2021
Technology
3
550
#merpay_techtalk Feature branchを使わないFeature開発
Kentaro "ku" KUMAGAI
March 18, 2021
Tweet
Share
Other Decks in Technology
See All in Technology
LLMアプリケーションの評価の実践と課題 ~PharmaXにおける今後の展望~
pharma_x_tech
2
170
エンジニアの生存戦略 〜クラウド潮流の経験から紐解く技術トレンドのメカニズムと乗りこなし方〜
shimy
9
1.9k
目標設定は好きですか? アジャイルとともに目標と向き合い続ける方法 / Do you like target Management?
kakehashi
10
3k
クラウド利用者の「責任」をどう果たす?AWSセキュリティ対策のススメ #AWSSummit
hiashisan
0
280
地理情報とAPIのトレンド
nagix
0
160
年間一億円削減した時系列データベースのアーキテクチャ改善~不確実性の高いプロジェクトへの挑戦~
lycorptech_jp
PRO
3
2.9k
dxd2024-生成AIに振り回された3か月間の成功と失敗/dxd2024-link-and-motivation
lmi
2
260
20240725 LLMによるDXのビジョンと、今何からやるべきか @Azure OpenAI Service Dev Day
nrryuya
3
1.2k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
0
190
What if...? 처음부터 다시 LLM 어플리케이션을 개발한다면
huffon
0
1k
Azure AI ことはじめ
tsubakimoto_s
0
130
開発生産性をむしろ向上させる セキュリティパートナーの作り方 / Dev Productivity Con 2024
flatt_security
0
390
Featured
See All Featured
Pencils Down: Stop Designing & Start Developing
hursman
118
11k
Faster Mobile Websites
deanohume
303
30k
Teambox: Starting and Learning
jrom
130
8.6k
The Language of Interfaces
destraynor
151
23k
Building Adaptive Systems
keathley
34
2k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
13
430
Raft: Consensus for Rubyists
vanstee
134
6.5k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
36
9.1k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
26
1.6k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
26
2.1k
Ruby is Unlike a Banana
tanoku
96
10k
Designing with Data
zakiwarfel
96
5k
Transcript
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を分離していると可能なのでおすすめです
まとめ