Chapter 15: Managing Continuous Delivery#

本章跳脫純技術層面，從管理與治理的角度探討如何在組織中推動持續交付。內容涵蓋成熟度模型、專案生命週期、風險管理流程、常見交付問題的診斷，以及合規與稽核等議題。

引言：效能與合規的平衡#

持續交付不僅是一套新的交付方法論，更是一種依賴軟體的企業經營全新典範（Paradigm）。

企業治理（Enterprise Governance）的核心存在一個根本張力：

• 業務治理（Business Governance）：關注績效（Performance），希望儘快將有價值的軟體推出以增加營收
• 公司治理（Corporate Governance）：關注合規（Conformance），確保組織理解並管理可能導致損失的風險

作者主張這並非零和博弈——透過部署流水線，可以同時達成效能與合規。流水線讓交付流程透明化，提供稽核紀錄，並可追溯每個環境中的版本到版本控制中的修訂版。

持續交付的實踐——增量交付、建置 / 測試 / 部署自動化——都是為了管理發布新版本軟體的風險。未被頻繁交付的軟體就像倉庫中的庫存：製造成本已付出，卻尚未產生收益。

組態與發布管理的成熟度模型#

作者提出一個五級成熟度模型，涵蓋六大實踐領域，用於評估組織在組態與發布管理方面的成熟程度。

六大實踐領域#

1. 建置管理與持續整合（Build Management & CI）
2. 環境與部署（Environments & Deployment）
3. 發布管理與合規（Release Management & Compliance）
4. 測試（Testing）
5. 資料管理（Data Management）
6. 組態管理（Configuration Management）

五個成熟度等級#

如何使用成熟度模型#

使用此模型的最終目標是組織改善，期望達成：

• 縮短週期時間（Cycle Time），更快交付價值
• 減少缺陷，提高效率並降低支援成本
• 增加可預測性，使規劃更有效
• 維持合規態度，符合監管要求
• 降低成本，透過更好的風險管理

作者建議採用 Deming 循環（PDCA）：

flowchart LR
    P[Plan\n評估成熟度\n找出痛點] --> D[Do\n實施變更\n概念驗證]
    D --> C[Check\n衡量效果]
    C --> A[Act\n回顧改善\n推廣成功做法]
    A --> P

組織變革是困難的。最重要的建議是增量實施變更並持續衡量影響。試圖一步到位從 Level 1 跳到 Level 5 必定失敗。改變大型組織可能需要數年。

專案生命週期（Project Lifecycle）#

每個軟體專案都有類似的生命週期弧線，可分為五個階段：

1. 識別階段（Identification）#

• 中大型組織有治理策略，從戰略目標分解出工作計畫（Programs），再分解為專案（Projects）
• 必須有商業案例（Business Case）——沒有商業案例就無法定義成功的樣貌
• 每個專案需要一位**唯一的業務贊助人（Business Sponsor）**以及一個指導委員會（Steering Committee）
• 其他利害關係人包括：營運、銷售、行銷、支援、開發與測試團隊

2. 啟動階段（Inception）#

在任何生產程式碼撰寫之前的階段，進行需求收集與分析。主要交付物包括：

• 商業案例，含專案估計價值
• 高層級功能與非功能需求清單（容量、可用性、服務持續性、安全性）
• 發布計畫，含工作排程與成本
• 測試策略 與 發布策略
• 架構評估，決定平台與框架
• 風險與問題日誌
• 開發生命週期描述

啟動階段最重要的事情是讓所有利害關係人面對面聚在一起——開發者、客戶、營運人員、管理層。這些人之間的對話所建立的共享理解，才是真正的交付物。

注意事項：此階段的每個決定都基於推測，且必然會改變。過多投入在此階段（對專案了解最少的時候）是一個錯誤。合理的專案最大期限約三到六個月。

3. 起始階段（Initiation）#

啟動之後，建立初始專案基礎設施，通常持續一到兩週：

• 確保團隊有所需的硬體和軟體
• 設定版本控制與基本的 CI 環境
• 約定角色、職責、工作時間與會議時間
• 建立簡單的測試環境與測試資料
• 透過 Spike（拋棄式概念驗證）識別並緩解風險
• 用一個最簡單的真實需求（架構上的 “Hello World”）驅動基礎設施建置

4. 開發與發布（Develop and Release）#

作者推薦迭代與增量流程。迭代開發的基本條件：

• 軟體始終處於可運作狀態（由自動化測試套件驗證）
• 每次迭代都將可運作的軟體部署到類生產環境展示給使用者
• 迭代不超過兩週

迭代開發的好處：

• 優先開發高商業價值功能，軟體可能在專案結束前就開始有用
• 定期獲得客戶回饋，更可能產出真正有用的東西
• 只有客戶簽收才算完成，定期展示是追蹤進度唯一可靠的方式
• 保持軟體始終可運作的紀律，防止冗長的整合階段
• 生產就緒的程式碼是軟體專案中唯一真正有用的進度衡量標準

Scrum 常見失敗原因#

5. 營運階段（Operation）#

• 第一次發布通常不是最後一次
• 在真正敏捷的流程中，營運階段與常規開發階段本質上沒有不同
• 讓這些階段合併是消除風險的最佳方式
• 一旦系統公開發布，變更管理（特別是資料和公開介面）成為重要議題

flowchart LR
    A[識別\nIdentification] --> B[啟動\nInception]
    B --> C[起始\nInitiation]
    C --> D[開發與發布\nDevelop & Release]
    D --> E[營運\nOperation]

風險管理流程（Risk Management Process）#

風險管理確保：

• 主要專案風險已被識別
• 已建立適當的緩解策略
• 風險在專案過程中持續被識別和管理

風險管理 101#

• 用影響（Impact）乘以可能性（Likelihood）計算風險嚴重度（Severity）
• 若緩解策略的成本高於風險嚴重度，可能不值得實施
• 並非所有風險都需要緩解策略——有些事件過於災難性，無法緩解

風險管理時程#

如何進行風險管理練習#

迭代方法的好處在於：如果團隊在每次迭代結束時從類生產環境展示可運作的軟體，團隊速度（Velocity）不會騙人。

分析專案的良好起點問題清單：

• 如何追蹤進度？如何預防 / 發現 / 追蹤缺陷？
• 如何知道一個 Story 已完成？
• 如何管理環境與組態？
• 多常展示可運作的功能？多常進行回顧？
• 如何部署與建置軟體？
• 如何確保發布計畫可行且營運團隊可接受？

常見交付問題：症狀與原因#

1. 不頻繁或有缺陷的部署#

症狀：Bug 關閉時間長、Story 簽收慢、測試者發現開發者早已修復的 Bug、無人信任環境、展示很少發生、團隊速度低於預期

可能原因：部署流程未自動化、硬體不足、硬體與作業系統組態管理不當、部署依賴團隊控制外的系統、了解建置與部署流程的人太少、團隊協作不足、開發者未保持小增量變更的紀律

2. 應用程式品質差#

症狀：回歸 Bug 不斷出現、缺陷數持續增加、客戶抱怨品質差、開發者一聽到新功能就哀嚎、實現新功能的時間越來越長

可能原因：測試者未在開發階段與開發者協作、Story 未經完整自動化測試就標記完成、缺陷被放入 Backlog 而非立即修復、團隊缺乏自動化測試經驗、專案管理未給予時間實施自動化測試

自動化測試過度也是可能的，但最常見的失敗模式是測試太少而非太多。

3. 持續整合流程管理不善#

症狀：開發者不夠頻繁地提交（至少每天一次）、提交階段永久損壞、缺陷數量高、每次發布前有長時間的整合階段

可能原因：自動化測試執行時間太長、提交階段超過十分鐘、自動化測試間歇性失敗（假陽性）、無人有權還原提交、了解 CI 流程的人太少

4. 組態管理不善#

症狀：生產環境出現神秘故障、新部署是緊張可怕的事件、龐大團隊專門負責環境組態、生產部署經常需要回滾或修補

可能原因：UAT 與生產環境不同、變更管理流程不佳或未被執行、營運 / 資料管理 / 交付團隊之間協作不足、對生產環境監控不足、應用程式日誌與儀表板不足

根本原因分析（Root Cause Analysis）#

面對一組症狀時，像小孩一樣反覆問團隊**「為什麼？」**——至少問五次。雖然這聽起來近乎荒謬，但作者認為此方法極其有用且萬無一失。

合規與稽核（Compliance and Auditing）#

許多大型公司必須遵守法規，例如：

• Sarbanes-Oxley（SOX）：美國上市公司
• HIPAA：美國醫療公司
• PCI DSS：處理信用卡資訊的系統

常見合規策略#

• 鎖定誰能存取「特權」環境
• 建立有效的變更管理流程
• 要求管理層核准才能進行部署
• 所有流程從建置到發布都需文件化
• 建立授權屏障，確保建立軟體的人無法將其部署到生產環境
• 每次部署都需被稽核以了解確切變更內容

以自動化取代文件（Automation over Documentation）#

一份聲稱你以某種方式做事的文件，並不能保證你真的那樣做了。文件也容易過時。自動化腳本就是流程的文件——而且是必須能運作的文件。強制使用自動化腳本，既確保它們是最新的，也確保流程完全按照意圖執行。

強制可追溯性（Enforcing Traceability）#

• 只建置二進位檔一次，將相同的二進位檔部署到生產環境。透過雜湊值（MD5 / SHA1）驗證完整性
• 使用全自動化流程記錄誰在何時做了什麼，將二進位檔通過部署、測試與發布流程

打破孤島（Working in Silos）#

大型組織常有獨立的開發、測試、營運、組態管理、資料管理、架構團隊。雖然職責分離有其必要性，但缺乏協作的根源幾乎總是溝通不良。

建議做法：

• 組成發布工作小組（Release Working Group），包含每個孤島的代表，在專案開始時共同制定發布策略
• 發布工作小組在專案期間定期會面，進行回顧並使用 PDCA 循環改善
• 軟體應儘可能頻繁地發布到類生產環境——至少每次迭代一次
• 專案狀態（含儀表板）應對所有參與建置、部署、測試與發布流程的人可見

變更管理（Change Management）#

在受監管環境中，手動測試環境、預備環境和生產環境應始終處於嚴格的存取控制下。研究顯示，做到這一點的組織擁有更低的平均故障間隔時間（MTBF）和平均修復時間（MTTR）。

建議的變更管理流程：

1. 成立變更諮詢委員會（Change Advisory Board, CAB），包含開發、營運、安全、變更管理與業務代表
2. 決定哪些環境受變更管理流程管轄，確保存取控制到位
3. 建立自動化變更請求管理系統，任何人可查看變更請求狀態
4. 任何環境變更都必須透過變更請求
5. 每次變更都需要補救策略（如回退能力）
6. 為變更定義驗收標準，理想情況下建立自動化測試
7. 變更核准後應可一鍵執行

flowchart TD
    A[1. 成立變更顧問委員會 CAB] --> B[2. 定義受管轄環境]
    B --> C[3. 建立自動化\n變更請求系統]
    C --> D[4. 所有變更\n需建立變更請求]
    D --> E[5. 制定補救策略]
    E --> F[6. 定義驗收標準]
    F --> G[7. 核准後\n一鍵自動執行]

部署流水線使得在受監管環境中強制這些策略變得相當容易。為部署流水線加上存取控制是一項簡單的工作，而且你用於測試環境的自動化可以直接重用於受變更管理流程管轄的環境。

CAB 如何決定是否執行變更？這純粹是風險管理：變更的風險是什麼？好處是什麼？如果風險大於好處，就不應該做。

變更核准流程的三項原則：

• 保持指標可見：變更核准時間、等待核准的變更數、被拒絕比例
• 保持驗證指標可見：MTBF、MTTR、變更週期時間
• 定期舉辦回顧會議，邀請各組織單位代表，持續改善

本章總結#

• 成熟度模型用於識別組織交付實踐的有效性並建議改善方向
• 風險管理流程搭配常見反模式清單，幫助儘早發現問題
• 迭代增量交付是有效風險管理的關鍵——沒有迭代增量流程，就無法客觀衡量專案進度
• 部署流水線體現的自動化建置、部署、測試與發布流程，不僅與合規和效能目標相容，更是達成這些目標的最有效方式
• 最終帶來：更快交付有價值的高品質軟體、更高獲利、更低風險——實現良好治理的目標