almost 8 years ago

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

系列文章

← 工程團隊如何做專案與程式碼管理 (二) 工程團隊如何做專案與程式碼管理 (總結) →
 
comments powered by Disqus