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