# Trunk-Based Development makes DevOps easy. - Paul Hammant
{%hackmd @DevOpsDay/B1cnefOI0 %}

#### 》[議程介紹](https://devopsdays.tw/2024/speaker-page/1488)
#### 》[收看即時AI翻譯字幕｜Watch AI-translated subtitles](https://attend.wordly.ai/join/HRTH-6395)
#### 》[填寫議程滿意度問卷｜回饋建言給辛苦的講者](https://forms.gle/csxMnaFxB8L67zWGA)

> 共筆從這開始

###### tags: `DevOpsDays Taipei 2024`

# Source control with DevOps is important to me

## CI and Trunk-Based Development

a branching model for source control

## 4種公司規模
發佈頻率 100, 10, 1, 1/10 days 佈署一次
緊急修復 2.5, 0.5, <0.1, no 次
CI 本身談論的目標是, 每個開發人員每天將工作重新納入source version control.
Release 的頻率愈高，因為 hotfix 的需求愈低，unplanned 的程度反而愈低.

理想狀況是, 持續性計畫性地發布以及 0 個計畫之外的發布.

Release **頻率愈低，抓馬愈多，加班愈多**，愈多制度上的不公平（修錯誤要加班，獎金發給加班的人）

Release 的頻率相當於練習的頻率，「專家會練到不犯錯」，頻繁 release 等於增加練習的頻率
如果公司每天能發布 10 個版本時, 會發現公司的時間其實已經消除了所有可能發生的錯誤.

## Bad Branching models(對應到前面四分的 Slow Enterprise)
紅線表示 build 不起作用, 可能無法編譯, 或者單元測試無法運行.
Slow Enterprise ： (紅線)Not deployable 數量約等於 deployable

- 死線到了才 merge
- merge 很痛苦，unmerge 很難

[](https://paulhammant.com/blog/branch_by_abstraction.html)
> 簡報圖片的來源

## Traditional Trunk-Based Dev (對應到前面四分的 Better Enterprise)

圖中的藍色區域是每個開發人員在工作的地方, 距離主幹分之的距離應該只有一天的時間間隔.
發布分支(灰色部分)在接近發布時間時, 不該允許開發人員在該分之上工作, 只有發布工程師和 SRE 可以在該分之上工作.
Trunk，所有開發者共享的 branch

[](https://tw.trunkbaseddevelopment.com/)
> 簡報圖片的來源（中文版）

## Better TBD (1/1 Transitional)
基於主幹開發需要我們在source control 中實踐良好的feature toggle 機制
## Google-class TBD
沒有分支，只有標籤。

- [Branch by Abstraction](https://paulhammant.com/blog/branch_by_abstraction.html)

（一天發布十次）


## Case Study - Big FX Bank
這樣的分支模型, 很可能導致有些人在 release 的最後幾天內長時間的工作.
需要做的是將這混亂的建置系統轉移至都是綠線的統一建置系統, 所以需要引入`單元測試`以及`測試自動化`.
`抽象分支`的目的是, 使得發布意圖早於發布的工作完成之前.

## More differentiators: Pre-prod 環境（QA, UAT 等）
這裡以 QA 的角度, 並運用四種顏色, 討論與表達更多差異化因素.

Slow：因為QA環境都是手動建立，沒有留下任何文件，容易失去/無法重建QA環境

Better : 複製相同環境需要一天

Transitional : 通過 IaC 工具將基礎設施環境也加入source control中, 能快速建立 QA 環境並獨立執行測試
將建立 QA 環境的方法、測試都包含到主幹中，建立不同的 QA 環境變成可以計算的成本（只需要額外取得算力）。

Fast ： All in trunk, 隨時產生QA env

## More differentiators: Release binaries
Slow: zip, 包啥誰也不知道
Better: pkg
Transitional: pkg for roll-back
Fast: Just fix forward.

## More differentiators: databases

Slow: 資料庫的發布計畫交由 dba 執行, 但這並不會在開發團隊的掌控之中.
Better: 會同時定義出兩個版本間的migration script 以及rollback script
Transitional:
Fast: 會一直forward fix , 不考慮rollback

## Google's TBD monorepo
monorepo 促進團隊, 無論使用什麼技術, 都在同一個source control repo中, 只是被劃分至不同的目錄之中.這使得所有團隊能同步更新對應的依賴.

改一個模組，所有用到模組的都會 release。

Google monorepo 是指 Google 使用的單一、龐大的程式碼儲存庫，其中包含了幾乎所有 Google 產品和服務的原始碼。這個儲存庫被稱為 Piper，它是一個集中式的版本控制系統，讓 Google 的工程師們可以更輕鬆地協作、共享程式碼，並維護程式碼的一致性。 by Gimini

### One CD: Continuous Delivery
> is to be or not to be.要麻生存, 要馬毀滅
> from Shakespare

CI 事實上只是把每個commit 或 pr, 推入 QA/UAT 環境中, 並不會直接投入正式環境中
CD(持續交付) 指在沒人覺得不妥的情況下, 將程式的變更投入 QA/UAT 環境中.

### The other CD: Continuous Deployment

沒有發布指令、pull requests 直接投入production env

### Non Continuous Delivery

### CD 和 NCD

# Grading companies / clients

## At the get-to-konw-you stage
通過以下的問題循序漸進地了解, 客戶的公司正處於什麼階段.
問客戶的問題：

- 同一個應用程式／服務，一年有多少計畫中和計劃外的發布？
- 從這個問題可以把客戶分進前面的四類，大概就知道後面的情況
- 要能區分 planned release 或單純只是 bugfix
- 製作一個 QA（或 UAT）環境要多久？
- 製作第二個要多久？
- 服務和資料庫不能跟第一個環境共用
- 防火牆要分開
- 可以清楚知道所需預算
- 製作第三個 QA 環境要多久？

https://phdo.paulhammant.com/Trunk-Correlated-Practices-Chart

https://phdo.paulhammant.com/BofA-Platform-Case-Study

# Q&A

Q:
A: 這比較是個社交技巧的問題。當然需要支持的架構。要搜集意見、找到對的人挺 TBD、讓團隊能表達安心的轉移時程、好好計畫。在舊作法和新作法之間找到一個折衷。

----

## 共筆聊天室：
[TW TBD](https://tw.trunkbaseddevelopment.com/)

HIHI
HI
Hi
Hi~~
morning
zzz
testingggggg
Hi
簽到～
Forward Fixing：前進就可以得到兩樣東西！
不懂就問：為何要製作多個QA環境？
1. 測試不同feature?
1. 不同程度的整合測試？
翻譯是不是用不了@@

---