---
title: "#22.0 TBD 讀網站會 - Introduction (Part 1)"
tags: Meetups
date: 2022-05-26
---

Ref: https://trunkbaseddevelopment.com/

## One line summary

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ [1], 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.

一個版控的分支模型，單一分支進行協作，稱之為「樹幹」

創建生命週期比較長的分支。我們透過以下技巧降低壓力

這讓我們避免合併痛苦。

[1] *main or master*, in Git nomenclature

## Shared branches off mainline/master/trunk are bad at any release cadence:

從 release 上面進行開發的情境


## Trunk-Based Development For Smaller Teams:

小規模團隊(1-2人)基於TBD開發的情境


## Scaled Trunk-Based Development:


大規模團隊(>2人)基於TBD開發的情境

## Elaboration, Claims and Caveats
闡述, 聲明 注意事項

Trunk-Based Development is a key enabler of [Continuous Integration](https://trunkbaseddevelopment.com/continuous-integration/) and by extension [Continuous Delivery](https://trunkbaseddevelopment.com/continuous-delivery/). When individuals on a team are committing their changes to the trunk multiple times a day it becomes easy to satisfy the core requirement of Continuous Integration that all team members commit to trunk at least once every 24 hours. This ensures the codebase is always releasable on demand and helps to make Continuous Delivery a reality.

TBD的開發方式是CI/CD的關鍵要素.
當團隊內的每個人每天能對trunk持續提交變更, 能變得很容易去滿足CI的核心需求.
這樣子做的好處確保了codebase總是能按需求發布, 並且有助於實現持續交付.

The dividing line between small team Trunk-Based Development and scaled Trunk-Based Development is a subject to team size and commit rate consideration. The precise moment a dev team is no longer “small” and has transitioned to “scaled” is subject to practitioner debate. Regardless, teams perform a full “pre integrate” build (compile, unit tests, integration tests) on their dev workstations before committing/pushing for others (or bots) to see.

小團隊TBD與大規模的TBD的分界線的維度是團隊人數與提交頻率來做考量.
具體來說, 何時該從小規模的TBD變成大規模的TBD是值得爭論的.
無論如何, 團隊成員要提交/推送到Git給別人/Bot看到下來之前, 要在開發環境上, 執行完整的"預先整合"建置(編譯, 單元測試, 整合測試...)

> 參考 CI 的開發人員的七項實踐

### Claims

- You should do Trunk-Based Development instead of GitFlow and other branching models that feature multiple long-running branches
- You can either do a direct to trunk commit/push (v small teams) or a Pull-Request workflow as long as those feature branches are short-lived and the product of a single person.

1. 應該進行TBD的開發流程來取代GitFlow或其它的有多個長生命分支的策略模型
2. 可以直接對Trunk做提交/推送(小規模團隊) 或者用PR工作流程, 只要這些功能分支是短生命的且你屬於一人產品團隊.

> TBD 與 GitHub Flow 比較接近，GitLab Flow 比較像變形

### Caveats

- Depending on the team size, and the rate of commits, [short-lived feature branches](https://trunkbaseddevelopment.com/short-lived-feature-branches/) are used for code-review and build checking (CI), but not artifact creation or publication, to happen before commits land in the trunk for other developers to depend on. Such branches allow developers to engage in [eager and continuous code review](https://trunkbaseddevelopment.com/continuous-review/) of contributions before their code is integrated into the trunk. Very small teams may [commit direct to the trunk](https://trunkbaseddevelopment.com/committing-straight-to-the-trunk/).

根據團隊人數規模與提交頻率, 短生命週期的功能分支被用來code-review和編譯檢查(CI), 而不是用來做artifact的生成與發布, 在提交限於主幹被其他開發人員拿來用甚至看到之前. 這些分支讓開發者們熱衷於review.
非常小的團隊可能直接提到到trunk.

- Depending on the intended release cadence, there may be [release branches](https://trunkbaseddevelopment.com/branch-for-release/) that are cut from the trunk on a just-in-time basis, are ‘hardened’ before a release (without that being a team activity), and those branches are deleted some time after release. Alternatively, there may also be no release branches if the team is [releasing from Trunk](https://trunkbaseddevelopment.com/release-from-trunk/), and choosing a “fix forward” strategy for bug fixes. Releasing from trunk is also for high-throughput teams, too.

根據想要的發布節奏, 有些發布分支可能會從trunk被切出去, 且不會在被合併回來了, 且這些被切出去的分支通常不久後就會在發布後被刪除. 或者, 團隊也可能從trunk直接發布, 並且選擇"fix forward"的策略來修復bug.
從主幹直接發布適合用於高產能團隊.
[參考上圖](#Trunk-Based-Development-For-Smaller-Teams)

- Teams should become adept with the related [branch by abstraction](https://trunkbaseddevelopment.com/branch-by-abstraction/) technique for longer to achieve changes, and use feature flags in day to day development to allow for hedging on the order of releases (and other good things - see [concurrent development of consecutive releases](https://trunkbaseddevelopment.com/concurrent-development-of-consecutive-releases/))

團隊們應該花點時間來適應branch by abstraction.
也能使用feature flags讓每天持續的開發人員的產出也能對做發布, 但又能避險, 讓還沒要公開或有風險的功能做公開.