軟件部署流程圖：由建置到生產環境
軟件部署流程圖：建置並為製品編上版本、品質關卡、提升至製品庫、預備環境檢查、金絲雀推出與自動回退。
甚麼是軟件部署流程圖：由建置到生產環境流程
軟件部署流程是把一個建置製品送到運行中的基礎設施上的具體機制。它由一次合併開始，止於某個版本完成推出，或者回退至上一個版本。這令它有意比發佈管理更窄：發佈管理決定哪些內容屬於今次發佈、範圍何時凍結，以及機構是否已經準備好交付。發佈管理回答的是要不要發、發甚麼；部署回答的是怎樣發。如果你們需要的那張圖裡有範圍凍結、UAT 驗收和一次放行與否的會議，那你們要的是發佈流程。如果裡面有製品版本、製品庫、流量切換和回退觸發條件，那就來對地方了。它亦不是 IT 變更管理：改動時段以及開啟它的那道審批，在這裡只是兩個步驟，而不是主題——因為這張圖假定審批途徑已經存在，它要展示的是部署在哪裡等待它。
大部分部署事故都可以追溯到少數幾條沒有畫出來的假設。製品在每個環境各自重新建置，於是通過了測試的東西，和最終進入生產環境的東西並不完全是同一個。預備環境幾個月前已經偏離了生產環境的設定，因此一次全綠的冒煙測試所能證明的，比人們以為的要少。推出沒有訂明步長和觀察時間，於是全部流量一次過切過去，而出問題的第一個訊號是支援工單排起了隊。還有，回退觸發條件是一個盯著儀表板的人，而不是流水線自己就能判斷的門檻——這就把一次快速而沉悶的回退，變成一場討論。把這條流程畫成泳道之後，哪些步驟你們已經自動化、哪些仍然要靠有人記得，就一目了然。
這個範本是一條可用的部署流程，橫跨五條泳道——開發人員、CI/CD 流水線、QA、發佈負責人與營運——鋪排在由建置到生產環境推出的五個階段上。它畫出了通常不會被記錄下來的三個迴路：把失敗的建置退回給開發人員、而不是任由它繼續往前走的品質關卡；在有人去預約改動時段之前做同一件事的預備環境檢查；以及把已超出門檻的推出送回同一個缺陷修正步驟的自動回退。它亦把部署策略畫成一個決策、而不是一條預設假設，於是藍綠部署和金絲雀發佈作為兩條具名途徑出現在圖上，並在共同的流量切換與健康檢查途徑上重新匯合。
本流程圖涵蓋的內容
本範本包含
- 頭兩條泳道裡的建置與版本：開發人員把改動合併到 main 分支，隨後 CI/CD 流水線只建置一次製品，並把它標上所來自的提交，因此此後每一個環境部署的都是同一個製品。
- 品質關卡：流水線執行自動化測試與掃描，隨後由 QA 擁有「是否通過品質關卡？」這個決策，它把失敗導向「修正缺陷並重新建置」，而不是任由它繼續往前。
- 把提升與預備環境畫成兩個各自獨立的步驟：製品被提升至製品庫，由流水線部署到預備環境，再由 QA 用冒煙測試與整合測試檢查，然後才是「預備環境是否健康？」這個決策——它失敗的那條分支同樣退回缺陷修正。
- 帶有真實否定結果的審批：發佈負責人申請生產環境改動時段，由營運作出「部署是否獲批？」的判斷，而不批准會令今次嘗試終止於「部署押後至下一個時段」，而不是靜靜地繼續往下走。
- 被畫成決策的部署策略：「藍綠部署還是金絲雀發佈？」分成部署到待命環境或部署到金絲雀執行個體，兩條分支都在「配合健康檢查切換流量」處重新匯合。
- 營運泳道裡的回退與收尾：「是否超出錯誤預算？」這個決策把失敗的推出送往「回退至上一個版本」並回到缺陷修正，而健康的推出則完成推出、持續監察，並結束部署紀錄。
何時使用本範本
- 你們要為一個部署步驟只存在於一份流水線設定檔和少數幾個人腦裡的團隊，記錄一次建置究竟是怎樣進入生產環境的。
- 你們要在真的需要它之前就把回退觸發條件議定下來，令這個判斷是一條量化門檻，而不是在最壞的時刻頂著壓力作出的估算。
- 你們要為研發、QA 與當值人員做入職，他們需要知道自己擁有哪一道關卡，以及當他們把這道關卡關住時下游會發生甚麼。
- 你們要逐個服務決定採用藍綠部署還是金絲雀發佈，並把這個選擇記錄在執行部署的人看得見的地方。
- 你們要回答核數師或客戶關於一次改動是如何被測試、授權和撤回的問題，作為你們變更管理程序的補充。
運作方式
把泳道改成你們真實的角色
把開發人員、CI/CD 流水線、QA、發佈負責人與營運換成你們實際擁有的角色。很多團隊沒有發佈負責人，那就把這條泳道併入生產環境的負責人，而不是留下一條空帶。即使 CI/CD 流水線是自動化的，也要把它保留為獨立的一條泳道——這張圖的意義正是展示哪些步驟由機器執行、哪些仍然由人執行。
寫清楚製品是甚麼、放在哪裡
寫下製品類型（容器映像檔、軟件套件、打包產物）、版本編號方案、版本是如何由提交推導出來的、由哪個製品庫保存，以及保留多久。然後寫下整張圖其餘部分所倚賴的那條規則：只建置一次並提升同一個製品，絕不在每個環境各自重新建置。如果你們的流水線目前會重新建置，就把這一點標在圖上，因為它切斷了已測試內容與已交付內容之間的關聯。
界定每一道關卡究竟檢查甚麼
「是否通過品質關卡？」的有用程度，取決於它的定義。訂明哪些測試套件必須為綠、你們可以接受的不穩定率與覆蓋率容忍度、哪些保安與相依項掃描會阻斷建置，以及誰可以推翻一個紅色結果。對預備環境的冒煙測試與整合測試也做同樣的事，並列出預備環境與生產環境之間已知的差異（資料量、第三方沙盒、縮減規模的基礎設施），令所有人都知道一次通過的預備環境執行可以證明甚麼、又不可以證明甚麼。
訂定改動時段，以及由誰開啟它
記錄部署可以在甚麼時候執行、由誰批准，以及一次沒有獲批的部署會怎樣。訂明這一類部署是在一份長期有效的變更模式下預先授權的，還是每次都需要一次個別審批，並指名那位可以在正常工作時間以外批准部署的人。如果被押後的部署只是等待下一個時段，就訂明製品在必須重新建置和重新測試之前還可以有效多久。
逐個服務選一種策略，並寫下推出步驟
為每個服務選擇藍綠部署或金絲雀發佈，並把這個選擇放到圖上。然後寫下它的機制：流量的遞增幅度、每一步之間觀察多久、每一步會執行哪些健康檢查，以及金絲雀執行個體是拿來跟甚麼作對照的。資料庫改動要另行處理，因為一次結構描述遷移往往正是回退不只是把開關撥回去的原因；把擴展式遷移與收縮式遷移同程式碼部署分開，可以令舊版本保持可運行。
令回退觸發條件可以量度，然後把圖發佈出去
把「有人會發現」換成流水線自己就能判斷的訊號：在訂明的觀察時段內、對照服務水平目標量得的錯誤率或回應時間，並配上一個已經議定的動作。演練一次回退，好讓你們知道它需要多長時間。然後把圖和運作手冊放在一起分享，取得圖中具名人員的簽署確認，只保留一個當前版本，並在任何一次出了問題的部署之後檢討它。
常見問題
部署流程和發佈流程有甚麼分別？
發佈流程決定交付甚麼、以及是否應該交付：哪些改動在範圍之內、範圍何時凍結、由誰簽署 UAT 驗收，以及放行與否的判斷是不是「放行」。部署流程則是它底下的機制：只建置一次製品、為它編上版本、提升它、在預備環境驗證它、把它送到生產環境的基礎設施上，並在它表現異常時回退。兩者不是一一對應的。一次發佈可以包含多次部署，而大量部署根本不掛在任何一次發佈之下——例如程式碼在功能開關後面推出、遲些才被開啟。這個範本講的是機制；如果你們需要的是範圍凍結、UAT 驗收和放行與否的關卡，請改用軟件發佈流程範本。
軟件部署流程分為哪些階段？
五個階段可以涵蓋大部分團隊。建置與版本：合併改動，由乾淨的簽出開始只建置一次製品，並把它標上所屬的提交。測試與品質關卡：執行自動化測試與掃描，把失敗退回給開發人員，而不是任由它繼續往前。預備環境：把製品提升至製品庫，部署到預備環境，並對它執行冒煙測試與整合測試。審批與時段：申請生產環境改動時段並令部署獲批，或者把它押後至下一個時段。生產環境推出：以藍綠部署或金絲雀發佈的方式部署，配合健康檢查分步切換流量，一旦超出錯誤預算就自動回退，否則就完成推出、持續監察，並結束部署紀錄。
我們應該用藍綠部署還是金絲雀發佈？
藍綠部署運行兩套生產環境並在它們之間切換流量，因此上一個版本會保持熱備，切換回去幾乎是即時的。代價是部署期間大約需要雙倍容量，而且所有用戶都在切換的那一刻一起被切過去，於是一個只在真實流量下才會現形的問題，會一次過擊中所有人。金絲雀發佈先把一小部分真實流量送到新版本，可以暴露合成測試捉不到的問題，但它需要流量調度和可以按版本切分的量度指標，耗時更長，而且它是明知故犯地讓一部分用戶去接觸一個你們還未有把握的版本。兩者都解決不了資料庫改動：它們都假定上一個版本仍然可以在當前的結構描述上運行，因此遷移通常會被拆成擴展與收縮兩步，分別部署。
部署應該在甚麼時候自動回退？
當一個流水線自己就能判斷的訊號越過了議定的門檻時——而不是當有人去解讀一塊儀表板的時候。在實際操作上，這意味著在訂明的觀察時段內、對照服務水平目標量得的錯誤率、回應時間或某項具名的業務交易，一旦錯誤預算的消耗比議定的上限更差，就自動暫停或撤回今次推出。有兩件事令它真的管用。第一，演練回退，好讓你們知道它確實可行、以及需要多長時間。第二，把不可逆的步驟——主要是結構描述遷移和單向的資料改動——同程式碼部署分開，令部署保持可撤回，否則自動化會去嘗試一次資料根本承載不了的回退。
如果我們一日部署好幾次，審批應該放在哪裡？
逐次審批每一個部署無法規模化，而一條人們無法遵守的流程會被繞過去。通常的答案是為途徑授權、而不是為單次執行授權：把這一類部署界定為預先批准的標準變更，由流水線的關卡、測試和自動回退充當控制措施，把個別審批留給落在這個模式以外的改動——例如結構描述遷移，或任何涉及受限環境的操作。這張圖裡的「部署是否獲批？」決策正正坐在這個位置上，那條押後分支亦因此才被畫出來。SOC 2（準則 CC8.1）和 ISO/IEC 27001 的變更管理控制措施這類框架，要求生產環境的改動經過授權、測試並留下文件；它們並不要求每一次部署都有人簽字。一張圖本身不構成證據，但它所產生的部署紀錄、測試結果和審批，正是評估人員要求查看的東西。