今年 (2018) 三月，我在公司內完成長達半年的 SRE (Site Reliability Engieering) 讀書會，快結束時就在盤算下一本候選書，希望激盪團隊更多想法。那時候首選就是當代軟體工程的經典之作：持續交付 (Continuous Delivery)。

在讀書會開始不久，有次跟朋友聊到持續部署想法，當時我提到因為時空背景的關係，這幾年各種新的概念與技術快速發展，特別是雲端架構應用、微服務與分散式架構的實踐概念，彷彿不斷的在提醒大家，持續部署 應該有不同的想法與實踐。當時的筆記如下圖：

同時 DevOps 與敏捷開發 (Agile Development) 概念鋪天蓋地的出現，大家意識到 霧卡世界（VUCA) 正在驅動整個軟體產業，除了持續部署，持續交付商業價值將面對更大的挑戰！VUCA 是 Volatility（易變性）、Uncertainty（不確定性）、Complexity（複雜性）、Ambiguity（模糊性）的縮寫。

戰爭之前，不管做了多少參謀作業，戰爭第一聲槍響的時候，所有計畫都會隨之改變。

– 美國名將 麥克阿瑟

雖然世界變化之快，常常讓人迷失，但變化越快，越要靜下心思考。正當我在思考，是否將這些資訊做通盤整理，彙整成更有意義的文字時，十一月七日早上，是立冬之日，Ruddy 老師在我桌上放了一本書，作者是人稱喬幫主的喬梁老師大作，書名：持續交付 2.0。當時的我心裡想：『嗯，我想要的，應該都在這裡面了。』

2019/04/27 於新竹敏捷社群 Meetup 的分享：導讀持續交付 2.0 - 談當代軟體交付之虛實融合

心得與摘要

喬老師的這本大作看起來不厚，但是內容非常扎實。我只摘錄幾個有共鳴的章節，做心得與摘要。

持續交付 2.0

這本書集合了現代軟體開發方法與協作管理之大成，書本一開始整理了軟體工程發展的模式，從瀑布開發、敏捷開發、DevOps 運動，然後整理 Jez Humble、Devid Farley 的經典之作 持續交付 1.0 (底下簡稱 CDv1.0) 與 持續交付 2.0 (底下簡稱 CDv2.0) 的差異，其中特別解釋了 價值探索環，也就是經典的 ８字環 探討兩個層面：

• 探索環：八字環左邊的圈，包含了 提問、錨定、共創、精練
• 驗證環：八字環右邊的圈，包含了 建構、運行、監測、決策

CDv2.0 延續了 CDv1.0 概念，同時也加入了很多面對 VUCA 的思維，我簡單用程式碼來表示如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

/**
 * 配置管理、持續整合、測試策略、部署流水線
 * 部署與發佈、基礎設施與環境、依賴管理、版本控管
 */
class CDv10 {
    // 可持續地、快速發布軟體服務
    boolean rapidDeploy = true;
    // 最小化可行產品
    boolean enableMVP = true;
}

class CDv20 extends CDv10 {
    // 四個核心原則
    boolean 減持少做 = true;
    boolean 持續分解問題 = true;
    boolean 快速反饋 = true;
    boolean 持續改進並衡量 = true;

    var teams = { "業務", "產品", "開發", "測試", "維運" };

    constructor(bizGoal) {
        eventLoop(bizGoal)
    }

    // 基礎設施
    void infra() {}
    // 軟體架構
    void architecture(default=microservices) {}
    // 組織機制
    void organize() {}

}

CDv2.0 除了交付軟體技術面的課題，更強調了交付價值的概念，用我個人在教吉他時，經常遇到的問題做小結：

學樂器有兩個層次：怎麼彈、彈什麼？。怎麼彈 是演奏技術問題，包含演奏技巧、和弦、音階、節奏等基本功，是理性思維；彈什麼 是情感表達問題，如何表達出音樂性，包含音樂層次、敘事張力、文化風格、抽象概念等，屬於感性呈現。

持續部署是 怎麼交付，屬於工程問題、執行面問題；持續交付則是 交付什麼，屬於商業價值、企業文化層次。

軟體系統架構

第五章的標題：持續交付的軟件系統架構，這標題正好是我在公司內部推廣的概念：看見系統架構的全貌，包含開發，測試、正式環境的架構與考量。

專案之初，首重看見全貌；持續交付首要看見架構全貌。

軟體服務經常因為隨著時間的前進，系統架構會做改變與調整，漸漸的，很少人能夠清楚地掌握全貌。這間接造成後續維運的風險增加、成本不可控、測試階段可測性大減，同時無法全面掌控架構，也讓持續部署寸步難行，最終導致的就是無法快速的持續交付，不管是交付到新的測試環境、還是新的業務需求，影響的將是整個企業的發展與生存機會。

我在 DevOpsDays Taipei 2018 分享了 緊急事件處理的探討，其中也提及如何溝通系統架構的方法，如何定義架構與團隊之間的關係。另一篇文章：導入 CI/CD 的第一步，也特別強調架構的重要性。過往帶領測試團隊時，持續部署到測試環境是每天必做的，能做的不只是功能環境的驗證，也包含非功能的驗證。強調持續部署與交付到測試環境的重要性，能夠快速部署，代表著部署流水線有著順暢的定義，系統架構有清楚的關係定義。所以在持續部署階段，掌握系統架構更是基本功。

基本功不代表簡單、容易，實際上代表的是重要，要越早做越好的。不管是微服務架構、微核架構還是單體架構，實際上都跟 物件導向 與 設計模式 有著巧合的關聯性。我在探討架構規範時，就針對 服務定義、服務依賴、角色可視性、基礎架構 做了清楚的定義，最後架構都會跟組織有著直接關係，也就是 康威定律 (Conway's Law) ：描述了組織溝通的方式與對象。

如何調整架構，讓持續部署與交付能夠更快，更清楚，這也是現代團隊都要面對的問題，因為他間接會影響整個組織溝通的效率與成本。特別是現代架構走向 分散式系統 已經是一種必然的趨勢。

交付流水線

流水線 (Pipeline) 承接軟體開發過程中每次的交棒，其中包含了整個開發團隊從功能開發、產品功能測試 (Product Functional Test)、維運功能測試 (Ops Functional Test)、使用者接受測試 (UAT)，整串的流程中，技術面包含很多面向，像是：

• 環境建置 (Provisioning)
  • 基礎建置：Infra as Code
  • 開發環境：開發人員本地端的環境，現代通常是以容器 (Container) 加上容器編排器 (Container Orchestration)
  • 功能驗證環境：資源最小化、功能完整性最高、成本最低。麻雀雖小五臟俱全，容器也是首選技術。
  • 維運功能驗證環境：一般稱非功能性環境，以前我稱為 SVT、RT、PT … 詳細參見：淺談軟體測試的階段與策略
• 持續整合 (CI)：
  • 單元測試 (Unit Test)
  • 產出物管理 (Artifact Managemenet)：Build, Packing, Dockerfile, Version Control… 等.
  • 程式品質碼驗證
• 持續部署 (CD)：依據使用者角色（Tester or SRE) 的需求，選擇待部署的版本、配置、環境，執行部署

簡單羅列一些概念，這些在喬老師的 CDv2.0 也都有類似的整理與想法。

除了 CI/CD 相關的關鍵技術，團隊協作的紀律與共識也是重要的。其中特別是環境與配置管理部分，這關係到整個團隊協作的流暢度與溝通品質。所以整個持續交付的流水線至關重要。

部署流水線掌握了軟體開發團隊的節奏，就像音樂一樣，音符在穩定的節拍與律動上，詮釋著樂章上每個精彩的音符與呼吸。

如果說整個開發團隊本身也是一種維運 (Ops)，那麼部署流水線就是軟體開發團隊的維運！他的節奏順暢與否，關係著交付價值的速度與品質。

持續交付的團隊

在計算機程式語言裡，底下這段程式碼：

1

int x = a + b;

加號 (+) 稱為運算子 (Operator)，意思是把 a, b 這兩個符號的內容，用加法做運算。而等號 (=) 則是指定 (assigement) 運算，將 a + b 的結果指定給 x.

軟體開發過程，加號與等號類似於內部的 Operating，也就是維運，這個讓團隊之間協作的維運方法，可以稱為持續交付。

通常講 開發團隊 可能的組成有：產品 (PM)、開發 (Dev)、測試 (Test)、維運 (Ops)。依照這樣單位的組成，交付的形式有底下幾種：

• 產品、開發、測試三個單位的交付：產品開發團隊 (不含維運)
• 開發、測試、維運的持續交付：開發團隊的 Dev, QA, and Ops，也就是 Wikipedia 說明的交集。

同樣用程式碼來呈現上述的 價值：

1
2

int value1 = 產品() + 開發() + 測試();
int value2 = 開發() + 測試() + 維運();

但這兩個 values 真的有價值？我覺得這是狹義的開發團隊，把鏡頭稍微 Zoom Out 一點點，看到整個企業，重新定義 產品開發團隊：

• 產品開發團隊 (Dev)：產品 ＋ 開發 ＋ 測試
• 企業營運團隊 (Ops)：行銷 ＋ 業務 ＋ 維運 ＋ IT ＋ 人資 ＋ 財務 ＋ 法務 ….

整個企業團隊的持續交付 = 產品開發團隊（Dev) + 企業營運團隊 (Ops)

Ops 回饋到 Dev，然後 Ops 會變成開發，Dev 會變成營運，透過回饋機制，由品質建立數量，由數量產生速度，產生倍數的價值。

結論

從上一個世紀阿波羅登陸月球計畫開始之後，MIT 教授 Margaret Hamilton 開始推廣 軟體工程 一詞開始，『交付』在軟體開發團隊裡不是什麼新觀念，到了廿一世紀的今天，隨著行動應用、物聯網的發展，到大數據與機器學習，原本大週期性的交付、不穩定且斷斷續續的交付，因為敏捷開發與 DevOps 的登入，人們才認知到軟體服務因該是有節奏的交付。持續交付 1.0 告訴大家工程方法，影響了廿一世紀的軟體工程；持續交付 2.0 繼承了上一個版本，不只談工程，也談文化，更是眾家之大成。

持續面對改變 是敏捷開發的基本精神與原則，交付價值 則是面對霧卡世界必須思考的。隨著時間的右移，技術不斷推成出新，能夠生存的企業唯一不變的法則是：

用 持續 且穩定的技術與團隊 (節奏)，交付 有商業價值的軟體與服務 (音符)。

天下武功、唯快不破，但是唯有嚴謹的系統架構，有紀律與規矩，才能面對外在瞬息萬變的世界。持續交付 2.0 是本適合企業高管、經理人、團隊一起閱讀討論，也將是下一個軟體工程的經典高牆。

… 2018/11/11, 寫於雙十一 台北 松山

Updated: 2019/04/27
於新竹敏捷社群 Meetup 的分享：導讀持續交付 2.0 - 談當代軟體交付之虛實融合

相關書籍

• Continuous Delivery - Jez Humble, David Farley
• Building Microservices - Sam Newman
• Site Reliability Engineering
• Effective DevOps - Jennifer Davis, Ryn Daniels
• 第五項修練：學習型組織的藝術與實務 - 彼得·聖吉（Peter M. Senge)
• Google軟體測試之道：進行 Google 級的軟體測試
• Design Patterns - GoF
• Designing Distributed Systems - Burns, Brendan

延伸閱讀

• Software Development Lifecycle
• 導入 CI/CD 的第一步
• 怎樣的 CI/CD 才夠 Quality?
• Artifacts Management
• Resource Provisioning and DevOps
• 淺談軟體測試的階段與策略
• 演講：從緊急事件 談 SRE 應變能力的培養
• 演講：Ops as Code using Serverless
• 推薦：Site Reliability Engineering
• DevOps 8 字環的誤區：左環問題
• 導讀持續交付 2.0 - 談當代軟體交付之虛實融合