Re: [討論] 大家公司產品的Release週期都多長阿

※ 引述《hiefal (Bushiroad原廠打手)》之銘言：
: 各位晚上好
: 我剛進入後端開發一陣子 經驗還不多
: 最近拿到了一份offer 目前各方面條件感覺起來都不錯
: 面試官給人的感覺以及技術都很好
: 但是似乎步調有點快 主管看起來也比較疲憊(可能是因為要on call)
: 其中對方有提到產品的Release週期為一個月一次
: 想請問各位這樣的Release速度是不是太快了?
: 會不會容易因為時程關係
: 反而不利於技術成長呢?
: 大家公司的release週期大概都是多長呢

先快速回答這題的答案，
我待過的不同團隊有兩週上線一次、每天上版的，
也有一天上很多次（每個人都可以 deploy）的團隊。

原文下面的推文也滿多人提到跟工作方法或產品型態有關，
我寫了一篇文章來分享自己過去在團隊做 Release Management 的經驗，
以及剛踏入 PM 工作初期時總是搞不清楚的技術名詞解釋，
這部分如果解釋有誤還請大家多多回饋。

Medium 好讀版：http://a0.pise.pw/RUWUK

文章內容包含：
- 為什麼不同產品團隊 Release 的頻率會有這麼大的差異？
- 產品上線流程相關的名詞解釋
- 實務工作流程、每天上版之我痛苦的一天

▍為什麼 Release 頻率會有這麼大的差異？
一、產品類型與服務對象不同：自有產品 vs 接案團隊
自有產品的團隊對於多久上一個新版本、每個版本要涵蓋多少改動的決策可以較為彈性。

接案團隊則取決於客戶的喜好、習慣與信任度，尤其若是新產品、新網站上線，客戶通常會要求功能與頁面都非常完整才會一次上線，上線前也會有客戶驗收、測試與來回修改的時間，所花的時間就很容易比前者陸續優化現有產品的狀況還要多非常多。

二、工作方法與目標不同：敏捷式開發 vs 瀑布式開發
在敏捷式開發（Agile）方法中，核心價值是快速的開發、測試、上線，透過小而快速的迭代來從市場與使用者身上學習，新的需求可能會在每次新版本釋出後因為收到的回饋而被修正，貼近市場與使用者來持續優化產品。

在這種情況下搭配自動化的 CI/CD 增加釋出新版本的頻率是必要的，舉例來說 Scrum 方法論常見的跑法是每兩週一個 Sprint，因此上線頻率可能就是每兩週一次。

在瀑布式開發（Waterfall）方法中，開發上有明確的順序，如釐清需求、產品設計、開發、測試、上線，追求的是在開發的流程中每個階段都要做好十足的準備，完成後才能進入下個階段，也因此整個過程會花費較多的時間，適用於一些定義很明確的狀況，例如串接第三方服務、接客戶的案子、極端情境（edge cases）很多且需完整測試才能產生信任感的狀況等等。這種情況下，一季、一年才上線一次也有可能。

▍產品上線流程相關的名詞解釋
產品、功能、改動最終的目標都是上線，亦即呈現在使用者面前、讓使用者使用。這邊可以分為兩個部分，第一部分是程式碼的改動被部署到正式環境（這篇文章主要分享的部分） ；第二部分則是這個改動被推到使用者面前的階段，而這階段又分為推到部分使用者面前做測試或實驗，以及最終開放給所有的使用者的狀態。

不論是跟台灣團隊還是海外團隊工作，我們在提到這些名詞時幾乎都是用英文稱呼，也因此講話總是中英夾雜，文章中我會嘗試用中文來表達！

Deployment（部署、上版）
本身的意思是將程式碼放到特定環境中，常見的環境包含開發環境（dev）、測試環境（test）、正式環境（production），有些團隊中會在上線正式環境前有個模擬環境（staging, stg）來做整合測試或 E2E 測試。

在日常生活中當我們提到「今天有 deployment 嗎？」可能就是只有沒有新的改動要上線到正式環境當中，所以有時候 deploy 跟 release 這兩個詞會被混在一起使用。

Release（釋出、上線）
這個詞很容易讓人誤會，因為有時候我們將改動部署到正式環境中時，改動馬上就可以被終端使用者看見並使用；但有時候我們會先只釋出給一部分使用者、特定市場、做 A/B Testing，如果成果是好的才會是好的才會釋出給所有使用者。

從工程師的角度來看，可能每一次的正式環境部署都可以算是 release，但從產品團隊、行銷團隊、使用者的角度來看又會不同。

如果由我自己來定義的話，我認為這個新版本、新功能要有來自正式環境的流量與真實使用者使用時才算是 release，若只是給內部團隊在正式環境測試，那也不能算釋出。在這個定義下，rollout 也可以代表相同的意思。

Phased Rollout、Staged Rollout（階段性釋出）
承上，從部署完到完全上線中間有時候會有一個階段性釋出的過程，短則一週、長則幾個月都是有可能的，這部分通常是由產品經理負責的。

這個階段會做的事情就是內部測試、外部測試、蒐集回饋，如果有 bug、從使用者身上得到心回饋，也可能會在將產品改動或功能做得更完整後再釋出給更多人。有些團隊也會明定 Alpha Test、Beta Test、Release Candidate（RC）等不同階段。

Full Rollout、Rollout to All（完整上線、釋出給所有人）
經歷過上面釋出給一部分使用者測試、在特定市場試水溫、用實驗來觀察數據變化後，若反應都很正向，就可以正式上線給所有人使用了。

當然也有可能在前面幾個階段發現新的改動並不值得上線，而直接取消上線、或是大改方向的狀況。

Product Launch（產品發布、上市）
這個步驟則是在功能或產品釋出給所有人後，選擇對外公開公告新功能或新產品的階段，通常由產品團隊、行銷團隊（B2C）或客服與業務團隊（B2B）負責，小則從在網站上推播、或寄信發公告給使用者，大至發新聞稿給媒體、舉辦大型記者會。

▍相關技術名詞概述
以下再補充一些技術相關的一些名詞解釋，我剛開始 PM 工作時跟工程師講話簡直就是一頭霧水！我畢竟不是工程師，就不深入說明每個名詞的細節，單純分享團隊討論時常出現的名詞，有興趣的讀者可以自己再去深入研究這些主題。

Delivery（交付）
CI/CD 中，前者是持續整合（Continuous Integration），後者是有人說是持續交付（Continuous Delivery）、也有人說是持續部署（Continuous Deployment），這部分讓我有點困惑，有時也會混著用。

其中一種說法是，交付代表程式碼隨時準備好能夠被部署到正式環境中，因此是部署前的步驟；也有人說交付的程式碼是小包小包的，而部署的程式碼是一整個大版本；而若由我自己來說明差異的話，我認為部署（deploy）作為動詞時，對象是環境；而交付（deliver）作為動詞時，對象是使用者。

在某些公司會有 Delivery Manager 這個職位，通常由工程師背景、技術背景的主管擔任。

Master & Branch（主線 & 分支）
產品上線會有持續有很多不同的版本，可以使用 Git 這個分散式的版本控制系統來做專案的版本管理。可以想像同時有很多個不同的工程師在為同一個產品開發新功能，使用者現在在正式環境看到的都是統一版本，然而每個工程師在自己的本地端會因為開發新功能而加了新的程式碼，所以每個版本都不同，這時候版本控制系統就非常重要。

Master Branch 是最主要的主線，其他分支如 Dev Branch、Feature Branch、Release Branch、Hotfix Branch 等等，新的功能通常會開新的分支來開發，開發完成後會再合併（merge）回主線。

其他常見名詞解釋
- Push：將本地端的檔案、程式碼上傳（推）到遠端。
- Pull：把遠端的程式碼下載（拉）下來，類似於複製最新的版本到本地端，並將遠端分支合併到本地分支，這樣開發時才會是基於最新的版本。
- PR（Pull Request）：要求第三方、遠端、其他分支拉自己的版本過去，類似於合併到其他人的版本上。
- Merge：把新的程式碼合回去主線。
- Dependency：相依性，某段程式碼跟其他程式碼有關聯，merge 的先後順序可能會有差異。
- Conflicts：不同的版本之間在 merge 的過程中可能會有衝突，例如兩個工程師雖然在開發不同的功能，但可能背後一些交錯的邏輯是有相關的，這時候就要來解 conflicts。
- Rebase：同上，當有新的版本部署到正式環境，跟每個工程師在本地端開發的版本可能已經有不同，因此要整理本地端的版本，避免還在舊的版本上開發。

Build（建置、版本）
原則上就是即將部署的版本，會是一堆任務、功能、改動、Pull Request 的集合。團隊會基於這個版本在模擬環境（staging env, pre-production env）做上線前的最終測試。如果在測試中發現問題，就會 merge bugfix to the build 然後重新測試，確保上線的版本是經過檢驗的。

Version（版本、版號）
每個 Build 都會有一個獨特的版號，有些團隊會以「日期」來命名，但另一個常見的形式是如 1.23.0 的三組數字，意思分別為 major.minor.patch（主版號.次版號.修訂號），數字會隨著新版本遞增。第一個數字是大版本更新時、第二個是功能更新或新功能上線時、第三個是小型變動時，當前一個數字進位時，後面低階層的數字會歸零。

這種語意化版本的版號其實是有官方定義的：https://semver.org/
不過我會說每個團隊都有自己習慣的定義方式，只要團隊內部有共識、好管理就行了！

我的習慣是預設一般情況下只改變 minor 的數字（上面案例變為 1.24.0），patch 是留給 hotfix 使用（變為 1.23.1），major 則是底層架構大更新、整個介面大改版時才會更新（變為 2.0.0）使用機會較低。

Rollback（回滾、回復上一動）
當部署到環境中發生問題時，可以 rollback 回到該環境的上一個狀態中。通常是部署到正式環境後發生問題，短時間內找不到問題而無法用 hotfix 解決，因此決定將正式環境回復到還沒部署新程式碼的狀態。這種情況當然是愈少愈好。

Hotfix（現在一定要上線的緊急修正）
當正式環境發生了緊急且嚴重的問題，無法等到下一次版本上線，必須立刻修好的時候，我們就會馬上上一個 hotfix。

它不是功能、也不是預料之中要上線的東西，且會立刻打斷原先排程的工作，再怎麼會拖，通常當天下班前一定要處理完，否則就會變成你今晚的惡夢。

▍產品上線實務流程
當團隊還小、產品影響力不大時，每個工程師可能都有權限自己部署新版本到正式環境，這時只要工程師彼此能夠溝通好就沒問題了。Slack 也有一些插件讓工程師可以很快速的部署，同時讓其他在同個 channel 的團隊成員得到更新。

隨著產品團隊長大，同時在動工的部分很多，上線這件事情變得愈來愈複雜，因此會需要有專門的人來負責，有些團隊中會有專職的 Release Manager、Delivery Manager 來管理，有些團隊則是由 Project Manager、Product Manager 一條龍來負責前期規劃、開發到最後上線，另外一些團隊則是將最後一哩路統一交給 QA Manager 來負責。

我有幸（還是不幸？）曾經擔任過團隊中統整產品部署與上線流程的負責人，在此稍微分享一下這個職位的工作內容。

我們的團隊當時幾乎是每天上新版（daily deployment），狀況好時順著流程走就沒問題，但出現問題時只能全心全意處理上版的問題（first priority!）幾乎從早到晚都在忙這件事，根本不可能專心做產品工作。

每天上新版的流程
10:00 — 開始部署新版本至正式環境
確認前一天的 build 是否測試完成且沒問題，若沒問題則通知負責部署的工程師上新版本到正式環境。

同時在公司群組發送 Release Notes 讓大家知道這個新版本的改動。

11:00 — 部署完成、正式環境檢查
正常情況下已經部署完成，PM 與 QA 團隊會在正式環境確認上線的內容沒問題。

如果有問題的話，端看問題的嚴重程度，決定是否需要上 hotfix，還是需要整包 rollback，同時確認當天這個版本是否還能重新測試完上線、是否會影響到後面的時程，重大問題還要寫日誌紀錄跟檢討。

若問題沒有非常嚴重，可以將它視為一般的 fix 並放到下一個版本上線修正。

12:00 — 為下一個 build 做準備
整理下一個 build 要包含的內容、判斷準備上線的內容的優先級、跟 PM 團隊確認隔天要上的功能與改動。

同時檢查這些任務之間有沒有 dependency、以及會不會有太多重大的改動在同一個 build 中，或是過於重大的改動需要提前通知前他部門。

其實這些通常不會當天才確認，但要請工程師 merge 之前還是要做好檢查。

若沒問題就通知負責部署的工程師開始建置下一個 build 的測試環境。

14:00 — 開始測試下一個 build
當工程師已經將下個版本一整包的內容放到測試環境後，QA、PM 就可以開始測試與檢查，包含自動化測試與手動測試。

自動化測試的主要測試項目為目前線上已有的基本功能與模組，避免新的版本影響到原有功能，而新功能的自動化測項則是會邊開發邊加進去，逐漸提高代碼覆蓋率（code coverage）。

手動測試時會檢查要新上線的功能、改動的前端狀況，包然使用情境、使用流程、UIUX 的呈現狀況。

18:00 — 下班前隨時確認測試狀況、為隔天的部署做準備
確認測結果，理想狀況是當天當測試完畢，隔天早上一上班就可以讓新版本上線，也因此在前一天下班前要將 Release Notes 都寫好，並事先預告團隊。

不理想的狀況是測試測出問題，就要在這個 build 中 merge 新的 fix 進去、嚴重點可能直接 revert 某一段程式碼（也就是某個功能或改動不會在這一包一起上線），然後重新部署到測試環境後重新測試，因此如果確定隔天沒辦法上新版本，一樣要預告團隊成員。

不只是 Release Manager 更是 Issue Manager
這個工作難的地方在於當新版本正式部署到正式環境時，可能會出現問題，每次的問題可能又不同，這時候快速應對跟危機處理非常重要。我們也因此訂定了一些基本規定讓未知風險的危機處理可以更有效率。

1. 規定上版時間：週五不上新版，因為若週末出問題沒人能處理；下午四點以後不上新版，因為太接近下班時間。

2. 討論好 hotfix 的定義：如果每個小問題都要上 hotfix 那我們整天光處理這件事就好了，因此事先定義好多嚴重的事情才達到我們必須上 hotfix 的緊急情況很重要。

3. 將工作流程文件化：其他部門（甚至不熟悉這套流程的 PM）可能會認為上線新版本、上線一個 hotfix 是一件非常快速又簡單的事情，但是根本不是啊啊啊！因此要盡量將工作流程文件化，方便跟其他團隊分享流程、也方便內部團隊的教育訓練。

總之在這個位置上，我追求的就是上線上的快、改動頻率高（新功能多）、downtime 時間少，而且每天上線的內容的優先級是合理的，總歸一句就是「低風險的快速迭代」。如果你的團隊也決定要走每天上線新版本這條路，要有每天都像在打仗的心理準備！

▍結語
以上分享我不專業不全職的工作方法，這方面中文的分享似乎不多（或是我下錯關鍵字…）下面分享一篇也是中英夾雜的文章，以及 David Ko 的這篇《從 Scrum 到 Kanban 的過程》也有提到這個角色。

歡迎專職的 Release Manager 來分享全職做這份工作時完整的規劃與做事方法！我真心敬佩

兼職 Release Manager 時的工作吃力不討好，我們整個產品團隊當時有好幾個產品經理、scrum team、feature team，大家都希望自己的東西趕快上線，畢竟東西沒上線就跟不存在一樣、一點影響力都沒有！

然而我對優先級的想法與其他 PM 的想法有時不同（我也很想先上我自己負責的產品啊啊啊啊但又一直提醒自己不能球員兼裁判），協調什麼先上、什麼後上真的是一門大學問，而為了趕每天的時程難免忙中有錯，真的是溝通技能和抗壓性要點高一點才能安穩妥當地做好這份工作。

不過我在做這份工作時也更完整的理解了整個產品從腦中構思到實際上線的過程，以及整條道路上會遇到的阻礙，更重要的是，如何從產品規劃與開發的時候就事先辨認與降低這些風險。

以上拋磚引玉，希望大家也可以多多分享自己團隊 Release 的流程和管理方法！

--

產品三眼怪實驗室 \(ＯＯＯ)/
https://medium.com/3pm-lab

--