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