軟件發佈流程圖
軟件發佈流程圖：範圍凍結、自動化測試關卡、預備環境與 UAT、放行與否的審批、部署、回退與緊急修正。
甚麼是軟件發佈流程
軟件發佈流程，就是橫在一個程式碼已可以發佈的建置與一套穩定的生產系統之間的那些關卡。步驟本身大家都熟悉（切一條分支、建置它、測試它、發出去），但把這條流程寫下來的價值恰恰在於關卡：範圍停止變動的那一點，一次失敗的測試套件把工作退回研發、而不是任由它繼續往前的那一點，某位有權限的人說「放行」的那一點，以及一次差劣的發佈被回退、而不是被拿來討論的那一點。每一道關卡都會留下一份紀錄：今次發佈裡有甚麼、測試了甚麼、由誰批准，以及推出之後發生了甚麼。
大部分發佈問題是交接問題，而不是工程問題。分支在還有三個合併在途中的時候就被切了出來，於是無人說得清建置裡到底裝了甚麼。QA 拿一套迴歸測試去跑一個幾個月前已經偏離生產環境的預備環境。放行與否的判斷在一次視像會議上作出，沒有任何書面準則，於是聲音最大的意見勝出。一次發佈在下午較晚的時候發了出去，沒有議定的監察時長，而出問題的第一個訊號是第二天早上的一封客戶電郵。把這條流程畫成泳道之後，每一次交接都變得明確，亦看得出此刻是誰托著今次發佈。
這個範本是一條可用的發佈流程，橫跨五條泳道——開發、QA、發佈經理、營運與產品負責人——鋪排在由範圍凍結到結案的五個階段上。它包含團隊通常不會畫出來的三個迴路：把失敗退回發佈分支的自動化測試關卡；把一次發佈退回返工、而不是放它出門的「不放行」決策；以及那條緊急修正途徑——它令一個發佈之後才發現的缺陷重新進入部署與驗證，而不必有人另外發明一條平行流程。
本流程圖涵蓋的內容
本範本包含
- 頭三條泳道裡的範圍與分支：開發裡程式碼已可以發佈，QA 確認測試範圍與準入準則，然後由發佈經理凍結範圍並建立發佈分支。
- 自動化測試關卡：開發進行建置並執行自動化測試，隨後由 QA 擁有「自動化測試是否通過？」這個決策，它把失敗送往「在發佈分支上修正缺陷」並退回建置，而不是任由它繼續往前。
- 預備環境與 UAT 作為三次各自獨立的交接：營運把建置部署到預備環境，QA 對它執行迴歸測試，產品負責人執行 UAT 並記錄驗收。
- 審批既是一份紀錄、亦是一個決策：發佈經理整合發佈就緒文件，產品負責人批准這個版本發佈到生產環境，而「放行還是不放行？」這個決策要麼把它放出去，要麼把它退回缺陷修正步驟。
- 營運泳道裡的生產環境途徑：在發佈時段內部署，在生產環境執行冒煙測試，然後是「這個版本是否健康？」這個決策——它把一次失敗的發佈導向「回退至上一個版本」並退回缺陷修正。
- 監察與結案：一段訂明的觀察期、把緊急修正迴路經由部署與冒煙測試送回去的「生產環境是否發現缺陷？」決策，以及最後一個發佈版本說明並結案的步驟。
何時使用本範本
- 你們要為一個一直憑習慣和對話紀錄發版的團隊編寫或重寫發佈程序，並且需要在它被寫進流水線之前先有一張大家認可的圖。
- 你們正在為新來的研發、QA 或當值人員做入職，他們需要知道自己擁有哪一道關卡，以及當他們把它攔住時下游會發生甚麼。
- 你們要在下一次發佈把爭論逼出來之前，先訂清楚放行與否的判斷究竟由誰作出、依據甚麼準則。
- 你們要回答一份客戶保安問卷，或者一次關於改動如何被測試、批准和回退的內部審核查詢。
- 你們正在一次差劣的發佈之後檢討流程，希望討論集中在哪一道關卡被略過了，而不是靠記憶重建當時的經過。
運作方式
把泳道改成你們真實的角色
把開發、QA、發佈經理、營運與產品負責人換成你們實際擁有的角色。相當多團隊沒有專職的發佈經理，那就把這條泳道併入技術主管，而不是留下一條空帶。如果你們沒有獨立的營運團隊，就把部署併入開發，並在圖上寫明這一點。
界定範圍凍結到底代表甚麼
把你們的凍結規則寫在建立分支那一步旁邊：分支建立之後還容許甚麼落到這條分支上、由誰批准例外，以及分支怎樣加標籤。記下這條分支由哪個提交建立，因為正是它令建置可以重現，亦令你們可以由差異生成版本說明。
界定每一道測試關卡的「通過」指甚麼
「自動化測試是否通過？」這個決策的好壞，取決於它的定義。訂明哪些測試套件必須為綠、你們可以接受的不穩定率或覆蓋率門檻，以及誰可以推翻一個紅色建置。對預備環境的迴歸測試和 UAT 也做同樣的事，好讓產品負責人知道自己簽的到底是甚麼。
在需要之前就寫好放行與否的準則
把那個籠統的決策換成你們自己的檢查清單：沒有未關閉的嚴重缺陷、回退已經演練、當值安排已經確認、有相依關係的團隊已經知會，以及一個訂明的截止時間。指名誰主持這次判斷、誰可以否決。等到一次發佈已經在門口等著才去議定這些，正是差劣的發佈獲得批准的方式。
訂定回退觸發條件、觀察期與緊急修正途徑
訂明甚麼會令「這個版本是否健康？」給出「失敗」：一個具體的錯誤率、一條延遲門檻或者一次未通過的冒煙測試，而不是一個主觀判斷。訂明觀察期有多長、監察哪些指標。然後議定一次緊急修正需要甚麼審批、誰可以在辦公時間以外批准，以及它如何合併回主幹——因為一個只活在發佈分支上的修正，是下一次迴歸的常見來源。
把它發佈出去，並只保留一個當前版本
把這張圖分享到工作真正發生的地方——發佈檢查清單旁邊，或者運作手冊裡——並取得圖中具名人員的簽署確認。保留此前的各個版本，這樣你們才可以說清程序是在甚麼時候、為甚麼被改動的，並在任何一次出了問題的發佈之後檢討它。
常見問題
軟件發佈流程分為哪些階段？
五個階段可以涵蓋大部分團隊。第一，範圍與分支：議定今次發佈包含甚麼、確認測試準入準則、凍結範圍並建立發佈分支。第二，建置與測試：產出一個候選版本，執行自動化測試套件，並把失敗退回分支而不是任由它繼續往前。第三，預備環境與 UAT：部署到預備環境，執行迴歸測試，並取得產品負責人的 UAT 驗收。第四，審批：整合一份就緒文件，並作出一次明確的放行與否決策。第五，發佈與監察：在議定的時段內部署，執行冒煙測試，按訂明的觀察期盯住它，然後發佈版本說明並結案。
發佈流程和部署流水線有甚麼分別？
部署流水線是自動化：它在被觸發時建置、測試並交付程式碼。發佈流程則是圍繞它的決策——誰議定了範圍、誰確認了這些測試確實有意義、誰批准了發佈到生產環境、發佈出問題時會怎樣，以及團隊甚麼時候可以解除候命。一條成熟的流水線會消除人手步驟，但它不會消除決策。這張圖有意把決策畫成決策，好讓你們看清其中哪些已經由流水線強制執行，哪些仍然要靠有人記得。
放行與否的決策應該由誰作出、依據甚麼？
應該由一位具名的人主持，通常是發佈經理或者生產環境的負責人，而產品負責人的批准應該已經作為輸入記錄在案，而不是在會上再討論一次。依據發佈之前已經寫好的準則來決定：沒有未關閉的嚴重缺陷、迴歸測試與 UAT 已完成、回退已經演練、當值安排已經確認、有相依關係的團隊已經知會。記錄誰有份參與、決定了甚麼，而不只是結果。如果你們要接受 SOC 2 審核，相關準則是 CC8.1，它要求改動經過授權、測試、批准並留下文件；可以證明這一點的正是發佈就緒文件和審批的留痕，而這張圖展示的是它們在哪裡產生。
怎樣在不繞過發佈流程的前提下處理緊急修正？
緊急修正是把流程壓縮，而不是略過它。在這個範本裡，監察期間發現的缺陷會被導向開發泳道中的「建置並測試緊急修正」，隨後在部署處重新進入流程，並經過與一次計劃內發佈完全相同的生產環境冒煙測試和同一個「這個版本是否健康？」檢查。改變的是審批的速度，而不是驗證。有兩條規則可以令它保持誠實：事先議定誰可以在辦公時間以外批准一次緊急修正；並且當日就把這個修正合併回主幹——因為一個只存在於發佈分支上的修正，會在下一次發佈裡以迴歸的形式重新出現。