Q: 如何一天做 15-20 支的 pull request 的 Release
過去我參與的的團隊一夕之間從 3 人膨脹到 20 人團隊。堆積如山的 pull request 成了我們的 devops 最頭大的問題。因為在當時 codebase 沒有測試（ startup 怎可能會有測試）的情況，一天只能 deploy 一支 pull-request，還可能大爆炸。
而這也是在業界最多人常問我的問題：如何設計一個很多人 (a.k.a 10+ 人） 可以瘋狂拉 pull request，卻不會大爆炸的流程？
以下是我的答案
step 1. 切分 deployable 與 development branch
把 branch 切成
- production
master
production 是正式 deploy 的 branch，只有 devops 可以對他進行變更，其他人不得任意進行操作。正式上 production 是去 deploy production branch。
master 是大家開發基準線的 branch，所以大家要開發什麼功能，以這個 branch 去 git checkout
開發完畢之後的 branch 對 master 拉 pull request
pull-request 的原則
- 須以 ticket branch 為名
- 有自動測試，需綠燈。
- 附上手動測試說明，手動測試需要在 15 分鐘內。
- 手動測試部分，junior 須送 senior 做第一次的 code review，senior 可直送 devops
step 2. 只 deploy production branch
devops 收到這些 pull request 後，手動測試後沒問題，merge 到 production branch。
在明日的上班第一個小時 deploy production branch。
如果是 deploy heroku 的操作可以更細膩。
先 deploy 到 staging 的 server，再 promote 到 production branch
step 3. 寫 release log
這樣的開發速度，是沒有辦法對版號做 release note 的。所以之後的 release note 會以 day 為計算。
一開始的 workround 我們是寫 hackpad 紀綠：今天有哪些 pull request 在排隊，哪些 pull request 被 release 了出去。哪些 pull request 在 production 需要額外的操作（例如 data migration)。
然後這份 hackpad 要 cc 給全技術 team，包括技術 team 外的人知道，我們釋出了哪些功能，這樣 customer support 才會知道要憤怒的 customer 衝進來，大概會是為了什麼事。
後來這個手段 loading 實在還是太重了。我們找到 zendesk 開發的 samson，自動化的解決這一切。
samson 是一套網頁介面的部署軟體。samson 可以做什麼呢？
- 對軟體打版號
- 可以一鍵前進 deploy，可以一鍵後退 deploy
- 網頁介面可以顯示這個 deploy 的版號上面，包含了哪些 pull request
然後我們再對 samson 做了一些 hack
- 把 samson 接上了 slack
- 讓 samson 支援 heroku ( 原本只支援 cap deploy )
- 自動寄信給全 team，這次的 deploy release 了哪些 pull request
- 規範了 pull-request 的 description 要怎麼寫
- 寄給全 team 的信裡面就會有功能說明
- devops 知道按下 deploy 鍵後，還要額外手動執行哪些 rake task