#22.3 TBD 讀網站會 - Deciding factors

--- title: "#22.3 TBD 讀網站會 - Deciding factors" tags: Meetups date: 2022-06-16 --- https://trunkbaseddevelopment.com/deciding-factors/ ## Release cadence 發佈節奏 There are many factors that put pressure on the team to lengthen the interval between releases. Here are some. 下述有些因素會因為延長發布而帶給團隊壓力 ### Iteration length 迭代週期長度 Different Agile teams focus on different iteration lengths. Some teams work at three-week iterations, some two, and some one. Some teams do not have an iteration at all - particularly teams doing Continuous Delivery. 不同的團隊都走敏捷式開發週期, 有的是3週迭代, 有的是2週, 有的更短, 有的根本沒在固定迭代. 就持續地有在交付. If you are on a four week, or more iteration length, and each of those four weeks varies with proximity to the release and cannot change that you may be in a bind. You may be able to follow the tenets of Trunk-Based Development, benefit from a Continuous Integration daemon (as all branching models can), but you are not going to be able to get all the way to Continuous Delivery (or Continuous Deployment). 但如果你的團隊迭代週期超過4週的話, 這段時間內的每一周都可能隨著發佈時限的逼近而產生變化, 就很可能會無法改變以迎合變化. 你可以遵循TBD開發原則, 透過CI自動化流程, 持續地獲得受益. 但你無法實現持續交付(或持續佈署), 就因為迭代週期超過4周, 無法快點取得市場或客戶回饋, 做即時調整. ### Waterfall 瀑布式開發 This one is easy. If you are doing waterfall, you are not close at all to the “do not break the build” mantra required to do Trunk-Based Development. Consider a short-iteration Agile methodology like Extreme Programming. 如果團隊走瀑布式方法, 沒辦法實踐TBD原則裡的"別搞壞Build". (為啥? 因為太久沒做合併可能會造成多個開發功能也許無法保證能與之前發的主幹合併,或是合併後能夠 build success) 但能考慮短迭代週期的敏捷方法論, 像是"Extreme Programming" ### Story size Trunk-Based Development needs you to have small stories/tasks. Optimal is you starting work on a change, should only be a matter of hours before completing and pushing it forward for code review. Longer than a couple of days, and there is going to be pressure to group a bunch of developers on a non-trunk branch and merge back later. Or worse, have developers make branches/forks from your in-progress branch. Or worse still, take intermediate merges from your branch, despite your change being incomplete.. TBD需要你有給出小故事/任務. 最好的是當你開始著手寫扣時, 只需要幾個小時就能完成的長度, 並且有Code Review和Push. 只要完成時長超過幾天的長度, 就會產生壓力在一群正在non-trunk分支上的開發者, 要把code給從trunk分支merge回自己的non-trunk時. 更糟糕的是, 讓開發者從你正在進行的分支上進行fork/創建分支, 儘管你的功能還不完整, 也還是要從你的分支進行merge. Generally speaking, the whole development team should do whatever it can to break stories/tasks into smaller stories/tasks. In Agile, there is an INVEST mnemonic that aids in the splitting up of stories. 一般來說, 開發團隊應該盡其所能地把故事/任務拆解的更小. 在Agile中, 有一個[INVEST符號](https://en.wikipedia.org/wiki/INVEST_%28mnemonic%29)能幫助拆分story. ### Build times 專案構建時間 Keeping build times short is important in that it directly drives the number of commits a developer can do in a day. If the build time is a couple of minutes, developers are likely to keep a high pace. If the build time is 30 minutes or worse, developers change pace to match only a couple of commits a day and drop their throughput. 保持Build的時間夠短很重要, 因為這直接決定了開發人員一天能完成的commit數量. 如果Build時間只有幾分鐘, 那開發人員就能保持著高速. 如果是30分鐘或更糟, 開發人員會改變步調來適應, 導致每天只commit幾個就降低了它們的吞吐量. ## VCS Technology Choice Your VCS/source-control technology choice should facilitate update/pull/sync from the team’s trunk many times a day. The elapsed time for the update/pull/sync should be less than three seconds for the situation where you already had latest of everything. It should be no more than fifteen seconds the case of the shared trunk being ahead of you. 你的版控服務器選擇要有助於團隊每天能多次從團隊的trunk上執行update/pull/sync. 團隊成員從server上執行update/pull/sync的時間應該要少於3秒. Older versions of ClearCase and PVCS Dimensions would be 30 minutes for the former and 45 minutes for the latter. Double that if two team-mates were simultaneously trying to do the update/pull/sync operation. In that configuration, it was completely impossible for teams to practice Trunk-Based Development. ### Binaries in the Repo? Depending on how many and how often they update, some SCM/VCS/source-control technologies are better than others. Perforce can handle terabytes of binaries and textual source. Subversion aims to. Git can only do large binaries if configured in [Git-LFS](https://git-lfs.github.com/) mode ### Repo size? It is suggested that Git and Mercurial really should not have a history (ignoring Git-LFS) that exceeds 1GB. There are field reports of clones being many times bigger than that and still working, but the development team suggests 1GB as the top limit. In order to use Git and push through that ceiling yearly, you might be in a situation where you have to keep archiving a repository, and starting a new one with no history to have more head room. Archiving might look like renaming the repository in GitHub, and turning it read-only so that all the history, issues, and code review comments are intact. Simpler clone-rationalization strategies might include recommending a “–shallow-since” date on cloning, or leveraging more recent partial clone capabilities to clone the full repo commit history without getting historical blobs until they are needed. ### Peak commit frequency In “pure” Git, if a colleague beat you to a commit/push on a branch (their code-review and automated CI passed) when you thought you were going to push, Git will inform you that you have to pull first. You pull, and you resolve your merge clashes (hopefully none), and then push again. On highly-active repos, you might struggle to find a window open long enough to push in this way without encountering the same problem. This is known as the “race to push”. 在“純”Git 中，如果同事在您認為要推送時擊敗您提交/推送分支（他們的代碼審查和自動化 CI 通過），Git 會通知您必須先拉取。你拉，你解決你的合併衝突（希望沒有），然後再推。在高度活躍的存儲庫中，您可能很難找到一個打開足夠長的窗口來以這種方式推送而不會遇到同樣的問題。這被稱為“競相推動”。 Fork-based “pull requests” and similar branch-based “merge requests” in hosted git services solve this to a degree, with robots keeping pull-request branches abreast of *origin:master* automatically as long as no conflicts arise. 託管 git 服務中基於分叉的“拉取請求”和類似的基於分支的“合併請求”在一定程度上解決了這個問題，只要沒有發生衝突，機器人就會自動將拉取請求分支與 *origin:master* 保持同步。 Even with Pull Requests, however, very high commit frequencies to the shared repo means contention and an artificial serialization. Microsoft acknowledged this as one of the motivations to their Git Virtual File System (GitVFS GVFS VFS for Git). > Git has critical serialization points that will cause a queue to back up badly > Brian Harry Refer to Brian’s “More on GVFS” blog entry We’re sure that within a few years, Git will be able to handle huge scale too. Whether with the Microsoft technologies, or something else. 我們確信在幾年內，Git 也將能夠處理巨大的規模。無論是使用 Microsoft 技術還是其他技術。 ## Conway’s Law The organization creates applications and services that reflect the organization’s own structure. If your organization feels like this, and a Monorepo does not feel right, then MicroServices could be the direction for you. 組織創建反映組織自身結構的應用程序和服務。如果您的組織有這種感覺，並且 Monorepo 感覺不對，那麼微服務可能是您的方向。 ## Database migrations In order to manage database schemas in a Trunk-Based Development way you will need to find a way to handle table-shape changes under source control, and even manage existing data where new/changed columns have happened. Pramod Sadlage and Scott Amber’s book “Refactoring Databases: Evolutionary Database Design" goes into that much more, as does the Continuous Delivery book. 為了以基於主幹的開發方式管理數據庫模式，您需要找到一種方法來處理源代碼控制下的表格形狀更改，甚至管理髮生新/更改列的現有數據。 Pramod Sadlage 和 Scott Amber 的《重構數據庫：進化數據庫設計》一書深入探討了這一點，《持續交付》一書也是如此。 ## Shared code Trunk-Based Development teams typically have common code ownership rules around contributions to different parts of the source tree. If they do not have a fully egalitarian system, they have objective rules for contributions to the tree. Rules that focus on standards and come with a promise of a prioritized and fair code review. Trunk-Based Development teams might have fine-grained write permissions for directories within the trunk, but never have any impediment to reading files in the trunk - everyone can see everything. 基於主幹的開發團隊通常圍繞對源代碼樹不同部分的貢獻有共同的代碼所有權規則。如果他們沒有完全平等的制度，他們就有對樹的貢獻的客觀規則。專注於標準並承諾優先和公平的代碼審查的規則。基於主幹的開發團隊可能對主幹中的目錄具有細粒度的寫入權限，但在讀取主幹中的文件時從來沒有任何障礙——每個人都可以看到一切。