DevOpsDays Taipei 2023 Trunk Based Development

自從 Git 成為主流版控工具後，開分支與合併分支變成大家日常作業的一部分，但有想過開分支對於整個開發流程，有隱藏的沉默成本嗎？主幹開發推崇不開分支或是分支不要開太久，進而減少沉默成本，以達到更流暢的開發節奏。但這個過程對於團隊運作的影響會是什麼，以及該如何解決，將會在此議程分享給大家。

Transcript

1. 真勇者的版控流程 Miles @DevOpsDays Taipei 2023 2023/9/25 使 用 主幹開發， 大 幅提 高 程式穩定性
2. https://github.com/MilesChou Miles PHP, Docker, DevOps
3. Outline • 認識主幹開發（Trunk-based development）的過程 • 一 分鐘說明主幹開發是什麼？ • 版本控制與分 支 對協作的影響 • 主幹開發所提倡的做法，與實務做法分享 Ref: https://trunkbaseddevelopment.com/
4. 2015 接觸主幹開發 • 2015 年接觸主幹開發，同時也接觸了功能標誌（Feature Flags）、持續整合 （Continuous Integration）、DevOps 等關鍵字 • 實務應 用 功能標誌在重構上
5. 2016 分享功能標誌 然後偷渡主幹開發 Image: https://2016.phpconf.tw/
6. 2017 分享持續交付 然後偷渡主幹開發 Image: https://2017.laravelconf.tw/
7. 2019 分享三場功能標誌 然後偷渡主幹開發
8. 2023 分享 Laravel Pennant 工 作坊 然後偷渡主幹開發 Image: https://martinfowler.com/articles/feature-toggles.html
9. Image: 頭 文 字D 藤原 文 太
10. Source: https://trunkbaseddevelopment.com/ A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.
11. Keyword 分 支 模型 長期分 支 已知技術
12. 不使 用 版控的樣 子 • 多 人 使 用 同 一 台共 用 主機 • 多 人 共享同個資料夾
13. 首 先先…
14. 然後再…
15. 接著就會滿滿的…
16. 想 一 下，這樣做有什麼好處？
17. 另 一 個例 子 ：使 用 版本控制搭配 Git Flow 切換分 支 建立分 支 合併分 支 解衝突
18. 合併與衝突之間的關係
19. Image: https://nvie.com/posts/a-successful-git-branching-model/
20. Image: https://nvie.com/posts/a-successful-git-branching-model/
22. 使 用 分 支 的優點與缺點 • 優點 • 別 人 把東 西 搞壞了，影響不到我 • 缺點 • 別 人 把東 西 搞壞了，可是我不知道
23. https://trunkbaseddevelopment.com/5-min-overview/ Branches create distance between developers and we do not want that — Frank Compagner, Guerrilla Games
24. Image: 頭 文 字D 神之 手 城島 俊也
25. 什麼是主幹開發？
26. 什麼是主幹開發？ • 在兩個極端的例 子 中找到平衡點 沒有版控或分 支 管理 分 支 嚴格控管 主幹開發
27. 面 臨的問題 沒有版控或分 支 管理 分 支 嚴格控管 主幹可能會被破壞 開發者間產 生 距離
28. 團隊現況 • 維護 身 分驗證服務（Identity Provider） • 直接影響 Trunk：主管 + 三位 工 程師的 小 團隊 • 間接影響 Trunk：PM、SRE、DBA… etc.
29. 主幹開發實際的做法 Image: https://trunkbaseddevelopment.com/5-min-overview/
30. 該如何保護主幹？
31. 該如何保護主幹？ • 開分 支 • 自 動化測試（Automated Test） • Code review • 功能標誌（Feature Flags）
32. 應 用 短期分 支 Image: https://trunkbaseddevelopment.com/5-min-overview/
33. Pull Request 與 自 動化測試 Image: https://trunkbaseddevelopment.com/5-min-overview/
34. 自 動化測試 • 必須始終保持是綠燈 • 若遇到錯誤，必須 馬 上修正 Build Build Build Build ✓ ✗ ✓ ✓ FAIL Pass Pass Pass
35. 原 子 提交（Atomic commits） • 增量式變更（Ref: Continuous Delivery） • 不可分割的最 小 提交 • 分割太細，提交之間會互有關聯 • 分割太粗，形成長期分 支 、Code review 變困難
36. 實務的開發流程範例
37. Code Review
38. 實務的 Code Review 範例 • 盡可能達成每個 人 Requester 與 Reviewer 的對象次數是平均的。 • 資深資淺，平等對待 • 大 家都有權 力 影響 code 的結果，責任是 code 壞了 大 家都有機會 面 對
39. 長期分 支 的替代 方 案：功能標誌 Image: https://martinfowler.com/bliki/FeatureFlag.html
40. 實務的功能標誌範例 • 新功能發布使 用 • 0% → 100% • 0% → 20% → 100%
41. 實務的功能標誌範例
42. 發布應 用 程式 Image: https://trunkbaseddevelopment.com/branch-for-release/
43. Hotfix 處理 Image: https://trunkbaseddevelopment.com/branch-for-release/
44. 實務的部署策略範例 待上線環境第1版 待上線環境第2版, 線上環境 測試環境
45. 主幹開發團隊的特 色 • 沒有 Code Freeze • 快速 review • 本機建置應 用 程式 • 本機開發不依賴共 用 服務（與 12 Factor II. Dependencies 相同） • 程式碼擁有權
46. 該如何減少開發者間的距離
47. 該如何減少開發者間的距離 Ans: 持續整合 Image: https://trunkbaseddevelopment.com/context/ 媽，我在這裡！
48. Summary
49. Image: https://trunkbaseddevelopment.com/context/ 媽～我在這裡～ 有誰考慮過我的感受…
50. Code Review 自 動化測試 原 子 提交 功能標誌 持續整合 程式抽象化 持續交付 主幹開發
51. Ref: Kuma Syu 不想 面 對的技術問題，都因為主幹開發 而 不得不解 不得不解最 大 的好處就是迎刃 而 解 ：）
52. Image: 頭 文 字D 神之 手 城島 俊也
53. Q & A