PRマージのあらゆるブロッキングを回避する技術 / trunk-based development tips

https://gotanda-rb.connpass.com/event/315058/
2024/04/024「gotanda.rb #57」の資料です。

本発表では、トランクベース開発における基本的な考え方とプラクティスを紹介しました。

Transcript

1. © 2024 Wantedly, Inc. PR マージのあらゆる ブロッキングを回避する技術 Gotanda.rb #58 Apr 24 2024 - Sora Ichigo
2. © 2024 Wantedly, Inc. ⾃⼰紹介 名前 市古 空 (Sora Ichigo) 所属 • ウォンテッドリー株式会社 • バックエンドエンジニア • DevOps 推進チームリード SNS • X: @igsr5_
3. © 2024 Wantedly, Inc. 今回のテーマ トランクベース開発 ⼩さなパッチを頻繁にデプロイしていく DevOps ケイパビリティの⼀つ https://dora.dev/devops-capabilities/technical/trunk-based-development/
4. © 2024 Wantedly, Inc. トランクベース開発 構成要素 「作業の分割」 x 「迅速なデプロイ」
5. © 2024 Wantedly, Inc. 構成要素 「作業の分割」 x 「迅速なデプロイ」 今回のメインテーマ こちらが今回のメインテーマ
6. © 2024 Wantedly, Inc. ⽬次 1. トランクベース開発の全体像 2. PR マージを阻害する外部要因 3. ウォンテッドリー事例 (Ruby で実践してみる)
7. © 2024 Wantedly, Inc. 1. トランクベース開発の全体像
8. © 2024 Wantedly, Inc. 導⼊ ⼀般論として、プロダクト開発を⾼速かつ安全に進めるためには 変更をなるべく “⼩さな単位で頻繁に本番に出していくこと”が⼤事
9. © 2024 Wantedly, Inc. よく⽐較される 2 つの開発スタイル (A) リリースブランチを切って変更を集約する (B) リリースブランチを切らずに常に全ての変更を本番に出す トランクベース開発は (B) を指す
10. © 2024 Wantedly, Inc. (A) リリースブランチを切って変更を集約する https://dora.dev/devops-capabilities/technical/trunk-based-development/
11. © 2024 Wantedly, Inc. (B) リリースブランチを切らずに常に全ての変更を本番に出す https://dora.dev/devops-capabilities/technical/trunk-based-development/
12. © 2024 Wantedly, Inc. トランクベース開発 (B) の利点 • 変更1回あたりの認知負荷の低減 • テスト容易性の向上 • 本番環境から得られるフィードバックの最⼤化 • 変更1回あたりのインシデントリスクの低減 • 頻繁なコンフリクトの予防
13. © 2024 Wantedly, Inc. トランクベース開発 (B) の利点 これらは開発プロセスのなかで継続的に価値を発揮し、 機能開発のスピードや安定性に⼤きく影響する
14. © 2024 Wantedly, Inc. 2. PR マージを阻害する外部要因
15. © 2024 Wantedly, Inc. 問題 実装やコードレビューは完了しているのに ”外部要因によって PR マージがブロックされる” ケースがある
16. © 2024 Wantedly, Inc. 具体例 • QA テスト、デザイナーや PdM による最終確認など • まだユーザーには⾒せたくないケース • 関連サービスの実装が追いついていないケース • ... 受け⼊れ条件を満たしている か確認したい！ 受け⼊れテストが終わるまで PRマージは待とう
17. © 2024 Wantedly, Inc. 最も素朴なアプローチ “外部要因が取り除かれるまで PR を寝かしておく” が最も素朴なアプ ローチ。 ⼀⽅でこれはトランクベース開発の恩恵を諦めることを意味する。
18. © 2024 Wantedly, Inc. トランクベース開発と外部要因の解決をなんとか両⽴できないか？ 実は、これらの外部要因によるブロックは⼯夫次第で回避可能
19. © 2024 Wantedly, Inc. 基本となる考え⽅ マージできない外部要因は “何かしらの条件分岐“ を実装することで⼤抵 回避できる • 環境変数による分岐 • Feature Flag による分岐 • 認証ユーザーによる分岐 • Basic Auth による分岐 • ...
20. © 2024 Wantedly, Inc. 適⽤例 • 「この変更はまだ PdM チェックが終わっていないから、、、」 ◦ → 本番環境のみ旧実装を出せばマージ可能 • 「この変更は関連マイクロサービスの実装を待たないと、、」 ◦ → Feature Flag で新実装を隠蔽すればマージ可能 次ページから詳しく解説します
21. © 2024 Wantedly, Inc. 3. ウォンテッドリー事例 Ruby で実践してみる
22. © 2024 Wantedly, Inc. 実際にあったシナリオ • PdM チェックが終わっていないのでマージできない • 開発途中の変更をユーザーに⾒せたくないのでマージできない • 新規サイト⽴ち上げでリリース当⽇まで本番環境が作れない
23. © 2024 Wantedly, Inc. QA テストが終わっていないのでマージできない エンジニア PdM コードレビューまで完了！ 受け⼊れ条件を満たしている か確認したい！
24. © 2024 Wantedly, Inc. アンチパターン󰢃 エンジニア PdM コードレビューまで完了！ 受け⼊れ条件を満たしている か確認したい！ 受け⼊れテストが終わるまで PR マージは待とう
25. © 2024 Wantedly, Inc. 何が問題か PR ⽣存期間が⻑くなることによる⽣産性低下 • いつまでも未マージの PR がチームの認知負荷を増加させる • 特定ブランチをデプロイしないと QA テストが⾏えない • ⾒つかった問題の修正が同じ PR に積まれて⾒通しが悪くなる • 最新 master をいちいち取り込む⼿間がかかる
26. © 2024 Wantedly, Inc. どうするか. 案 󰢏 エンジニア PdM コードレビューまで完了！ 受け⼊れ条件を満たしている か確認したい！ Feature Flag で変更を 切り替え可能にして PR マージしよう
27. © 2024 Wantedly, Inc. ウォンテッドリーと Feature Flag こんなコードを書くと 内製 Chrome Extension から 戻り値を override 可能になる リリース‧デプロイ戦略を⽀える技術 | Wantedly Engineering Handbook
28. © 2024 Wantedly, Inc. ウォンテッドリーと Feature Flag Feature Flag が true の時のみ 新実装を出すようにすれば 安全に PR マージできる Chrome Extension は⾮エンジニアでも触れるので QA テストも簡単
29. © 2024 Wantedly, Inc. リッチな Feature Flag がない場合でも params や環境変数、認証ユーザー情報などで代替可能
30. © 2024 Wantedly, Inc. 最後に
31. © 2024 Wantedly, Inc. まとめ トランクベース開発 ⼀般論として、プロダクト開発を⾼速かつ安全に進めるためには 変更をなるべく “⼩さな単位で頻繁に本番に出していくこと” が⼤事 Feature Flag マージできない外部要因は “何かしらの条件分岐“ を実装することで⼤抵 回避できる
32. © 2024 Wantedly, Inc. もっと知りたい • DORA | DevOps Capabilities: Trunk-based Development • リリース‧デプロイ戦略 | Wantedly Engineering Handbook • リリース‧デプロイ戦略を⽀える技術 | Wantedly Engineering Handbook