心得:持續交付 2.0


今年 (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) 的差異,其中特別解釋了 價值探索環,也就是經典的 8字環 探討兩個層面:

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

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):
  • 持續部署 (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

延伸閱讀



Comments

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲