心得：持續交付 2.0

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

在讀書會開始不久，有次跟朋友聊到持續部署想法，當時我提到因為時空背景的關係，這幾年各種新的概念與技術快速發展，特別是微服務與分散式架構的實踐概念快速發展之下，不斷的提醒大家，持續部署應該有不同的想法與實踐。同時 DevOps 與敏捷開發 (Agile Development) 概念鋪天蓋地的出現，大家意識到霧卡世界（VUCA) 正在驅動整個軟體產業，除了持續部署，持續交付商業價值將面對更大的挑戰！

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

– 美國名將麥克阿瑟

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

心得與摘要

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

持續交付 2.0

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

探索環
驗證環

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

/**
 * 配置管理、持續整合、測試策略、部署流水線
 * 部署與釋出、基礎設施與環境、依賴管理、版本控管
 */
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 除了交付軟體技術面的課題，更強調了交付價值的概念，用我個人在教吉他時，經常遇到的問題做小結：

學樂器有兩個層次：ofollow,noindex">怎麼彈、彈什麼？ 。怎麼彈 是演奏技術問題，包含演奏技巧、和絃、音階、節奏等基本功，是理性思維；彈什麼 是情感表達問題，如何表達出音樂性，包含音樂層次、敘事張力、文化風格、抽象概念等，屬於感性呈現。持續部署是怎麼交付 ，屬於工程問題、怎麼做，持續交付則是交付什麼 ，屬於文化、價值觀。

軟體系統架構

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

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

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

我在 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 … 詳細參見：Stages in Software Testing
• 持續整合 (CI)：產出物管理 (Artifact Managemenet)、程式品質碼驗證、單元測試 (Unit Test) …
• 持續部署 (CD)：依據使用者角色（Tester or SRE) 的需求，選擇待部署的版本、配置、環境，執行部署

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

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

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

持續交付的團隊

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

int x = a + b;

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

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

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

• 產品、開發、測試三個單位的交付：產品開發團隊 (不含維運)
• 開發、測試、維運的持續交付：開發團隊的 Dev and Ops

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

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

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

• 產品開發團隊團（Dev): 產品＋開發＋測試
• 企業營運團隊 (Ops)：行銷、業務、營管、維運、IT、HR、財務

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

Ops 回饋到 Dev，透過加速的回饋，產生倍數的價值。

結論

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

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

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

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