用證據做發布決定

精確說明決定

綠色管線代表一組檢查提供的證據，並非發布決定的完整說明。負責人需要知道將改變什麼、在哪裡改變，以及還有哪些後果。

以虛構客戶資料匯出為例，指出已接受的 commit 及其產生的建置產物，並寫出目標環境。連結相關測試、審查和已核准例外。納入伴隨應用程式發布的資料或基礎架構變更。

NIST 的 SSDF 提供安全開發實務，SLSA 來源證明則協助描述建置產物如何產生。兩者都無法省略這個決策：此次發布是否適合這項服務。NIST SSDF、SLSA 來源證明。

區分三件事

合併將原始碼變更放入分支。部署將建置產物放入環境。功能開放則讓使用者能使用該行為。這三件事可能同時發生，但不一定是同一件事。

服務可以先部署尚未啟用的功能，之後再開放。資料庫移轉，也可能在可見功能出現前就影響正式環境。定義實際順序，不要假設 PR 合併就能說明所有後果。

對匯出功能而言，功能旗標可能限制初期開放範圍，但不會自動保護新端點，也不會撤回資料結構描述移轉。在後果真正發生的位置驗證控制措施。

審查精簡的證據紀錄

使用另一位負責人能檢查的紀錄：

• 目的與受影響使用者。
• Commit 與建置產物身分。
• 相關行為、安全與相容性檢查。
• 目標環境與執行身分。
• 剩餘例外、負責人與到期條件。
• 監控、復原方法與應變負責人。

陳述要具體。「測試通過」不如連結到發布 commit 的結果，並清楚說明涵蓋範圍。「可以回復版本」不如附上經過測試且限制明確的程序。

決定如何停止

執行前定義發布條件。對虛構匯出功能而言，跨組織存取成功、產物與已接受摘要值不同，或無法復原時，都應停止。這些只是示範條件，不是通用檢查表。

部署後，檢查對使用者重要的訊號。將錯誤行為與回應時間，和服務已接受的目標比較。程序健康，不代表使用者工作流程正常。

條件不符合時，使用約定的應變方式，例如關閉功能、回復相容程式碼，或復原資料。選擇能處理故障、又不會造成更大問題的操作。

發布後保留決定

記錄實際部署產物與結果。執行若與計畫不同，清楚顯示差異。將事件與非預期工作納入下次發布設計。

自動化交付系統應讓紀錄更容易檢查，不應要求審查者從零散對話、記錄檔和截圖重建發布過程。清楚證據讓團隊可以自動執行例行工作，同時保留有明確責任歸屬的決定。