心得:持續交付 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
) 的差異,其中特別解釋了價值探索環
,也就是經典的8字環
探討兩個層面:
探索環 驗證環
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 是本適合企業高管、經理人、團隊一起閱讀討論,也將是下一個軟體工程的經典高牆。