#22.1 TBD 讀網站會 - Introduction (Part 2)

--- title: "#22.1 TBD 讀網站會 - Introduction (Part 2)" tags: Meetups date: 2022-06-02 --- Ref: https://trunkbaseddevelopment.com/ ### Caveats - If you have more than a couple of developers on the project, you are going to need to hook up a build server to verify that their commits have not broken the build after they land in the trunk, and also when they are ready to be merged back into the trunk from a short-lived feature branch. 團隊有多名開發人員在同一個repository上進行開發的話, 就會需要先建置好一個build serer來進行CI驗證. 用來驗證大家的提交在進入trunk分支時, 不會有不正常的代碼或不完整的業務功能, 以及當準備要進行merge時會從一個短生命週期的功能分支來合併到trunk分支. - Development teams can casually flex up or down in size (in the trunk) without affecting throughput or quality. Proof? Google does Trunk-Based Development and have 35000 developers and QA automators in that single monorepo trunk, that in their case can expand or contract to suit the developer in question. 開發團隊的規模可以任意地擴編或縮邊在trunk分支開發的人數規模, 而不會去影響到吞吐量跟品質證明??? Google執行TBD時, 在單一個monorepo trunk中有35000名左右的開發者與QA自動化人員, 在它們的情況下, 可以任意地收縮規模來配置開發人員 - People who practice the GitHub-flow branching model will feel that this is quite similar, but there is one small difference around where to release from. 用Github-flow分支策略來進行開發的人們會覺得TBD跟它很相似, 但有一點點小不同在從哪裡去做發佈. - People who practice the Gitflow branching model will find this very different, as will many developers used to the popular ClearCase, Subversion, Perforce, StarTeam, VCS branching models of the past. 之前習慣Gitflow分支策略的人, 會覺得TBD很不一樣. 大部分的開發者都習慣用集中式板控的分支策略模型了. - Many publications promote Trunk-Based Development as we describe it here. Those include the best-selling ‘Continuous Delivery’ and ‘DevOps Handbook’. This should not even be controversial anymore! 就像我們這裡所描述的, 大部分的書刊讀物, 大部分都在提倡TBD. 最著明的讀物就是"Continuous Delivery"和"DevOps Handbook". 所以TBD的優勢就沒什麼好爭議的了! ## History Trunk-Based Development is not a new branching model. The word ‘trunk’ is referent to the concept of a growing tree, where the fattest and longest span is the trunk, not the branches that radiate from it and are of more limited length. TBD不是一個全新的分支模型概念, Trunk這詞指的是一棵成長中的樹的概念, 最粗最長的跨度就是Trunk, 而不是其它從trunk生長到旁邊的小分支. It has been a lesser known branching model of choice since the mid-nineties and considered tactically since the eighties. The largest of development organizations, like Google (as mentioned) and Facebook practice it at scale. 從九十年代中期開始, TBD一直是一種顯為人知被選擇的分支模型. 從八零年代以來一直會在策略上被考慮進去. 最大的開發組織, 像是Google或Facebook都在大規模地實踐它. Over 30 years different [advances to source-control technologies and related tools/techniques](https://trunkbaseddevelopment.com/game-changers/) have made Trunk-Based Development more (and occasionally less) prevalent, but it has been a branching model that many have stuck with through the years. 經過30年來, 不同的source-control技術與相關的工具愈來愈進步了, 使得基於TBD的開發更加普遍了, 但還是有許多人一直以來堅持採取的分支模型策略. ## This site This site attempts to collect all the related facts, rationale and techniques for Trunk-Based Development together in one place, complete with twenty-five diagrams to help explain things. All without using TBD as an acronym even once twice.