[好書推薦] Continuous Delivery

(本文授權 DevOpsDays Taipei 2018 及天瓏網路書店全文轉載)
在你的公司裡,僅涉及一行程式碼的變更需要用多久時間才能部署上線?你的處理方式是否可重複且可靠呢?

這個問題來自《Implementing Lean Software Development》這本書,大家也可以捫心自問,目前團隊將開發完成的軟體部署到生產環境的過程是否仍是

  • 純手工工人智慧?
  • 常常犯錯?
  • 每次總是花很長的時間?
  • 軟體部署其實是其他部門的工作,與我無關?

根據敏捷宣言的第一條原則:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

來解析一下關鍵字,Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

  • 盡早發生
  • 持續交付有價值的產品
  • 讓客戶滿意

試想各位團隊的軟體開發有遵照這一條原則嗎?


我的 DevOps 之路的第一本書

當初我踏入 #DevOps 的第一本書,就是從閱讀了這一本 DevOps 的經典好書開始。本書獲得了《Dr. Dobb’s Journal》肯定,榮獲第21屆Jolt獎(素有IT書籍奧斯卡金像獎之稱),面對軟體部署的複雜度,以廣度來說,作者討論了從交付前應注意的事項到交付中及到交付後會遭遇到的種種問題。以深度來說,作者很有結構地討論了 Why — Who — How:

WHY

問題發生的原因;為何要採用這種實踐

WHO

身為 IT 主管、專案經理、開發人員、測試人員、維運人員在什麼環境、什麼情況下應該要做些什麼?

HOW

面對交付各個環節所面臨的各種問題,團隊所需採取的原則與實踐概念。

而本書比較可惜但又有點還好的一點是缺乏 What 層面的實踐手法,不過本書的重點在於持續交付話題的廣度,且光只是描述 Why — Who — How 層面的原則與觀念也占了 488 頁的厚度,若把更細節的 What 討論進來,只會讓讀者更難讀完這本經典好書。所幸書中都會附上關於更細節實踐的線上連結與參考書目,讓有興趣想了解細節的讀者有地方參考。

另一方面,這本書的安排也很符合敏捷的精神,每一個章節都是一個相對獨立的章節(相當於能獨立產生價值的 MVP),儘管你分開閱讀也都能了解該章節的主題。

而我,覺得幸運的地方就是這是我踏入 DevOps 的第一本書,而我也的確現學現賣地把一些實踐實驗在當時的團隊上,到現在我也很感謝從這本書學到的正確觀念,讓我的敏捷路上更加穩健。


本書的架構

本書其實分成三大部分,而我把每個大主題與章節的想像成主題(Epic)與章節(User Story)的關係,每一個 Epic 與 Story 都能夠獨立閱讀且對你的導入是能夠產生價值的。

  • Epic 1 基礎概念(Foundations)
  • Epic 2 部署流水線(The Deployment Pipeline)
  • Epic 3 交付系統生態(The Delivery Ecosystem)

Epic 1 基礎概念(Foundations)

對持續交付還沒有概念的朋友,建議一定要先閱讀這個主題,你將會慢慢理解持續交付背後的原則。
  • Story 1 軟體交付的問題
  • Story 2 設置管理
  • Story 3 持續整合
  • Story 4 測試策略的實作

Epic 2 部署流水線(The Deployment Pipeline)

有了觀念之後,想必你開始躍躍欲試,這個主題的實踐手法與各階段的實踐絕對可以滿足你踏入持續交付的核心。第10章的部署策略非常實戰,強烈推薦各位閱讀。
  • Story 5 部署流水線解析
  • Story 6 建置與部署的腳本化
  • Story 7 提交階段
  • Story 8 自動化驗收測試
  • Story 9 非功能性需求的測試
  • Story 10 應用程式的部署與發佈

Epic 3 交付系統生態(The Delivery Ecosystem)

待確實地建立了部署流水線之後,接下來就要思考為了支援部署流水線,我們需要採取的實踐與技術,第12章的資料管理非常實際地討論資料庫的問題,強烈推薦各位閱讀。
  • Story 11 基礎設施和環境管理
  • Story 12 資料管理
  • Story 13 元件與相依性管理
  • Story 14 版本控制進階
  • Story 15 持續交付管理

關於持續交付,絕對要看的一本經典書籍

導入任何一項工具或實踐之前,我們最好搞清楚為何而戰,而本書的第一章就是血淋淋地指出一些常見的發佈反模式,不管是總是手動部署軟體到開發完成後才部署到類生產環境到手動設置生產環境。每一項都是讓我們離客戶越來越遠的大忌。我們總想著要趕快上線開始創造價值,但是卻敗在交付這最後一哩路,各位甘心嗎?

以終為始,身為軟體人,我重新呼應一下文章一開始所提到的敏捷宣言第一條原則

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

為了要實踐這一條原則,我們該怎麼做呢?我很喜歡作者所提的目標:

找到一種可以用高效率、快速且可靠的方式,用來交付高品質且有價值軟體的方法

為了達到這個目標,我們需要一步一步地把手弄髒,實際地建造出這樣持續交付的文化,產生價值。


反思

其實從第一章的反模式就發現了我們團隊甚至是我們部門還是踩到了一些地雷(儘管我們有所謂的 SRE Team、DevOps Engineer 以及還不錯的 CICD 流程),直到第十五章看見交付的成熟度模型:

Source : https://github.com/garystafford/cd-maturity-model/wiki/Continuous-Delivery-Maturity-Model---Gap-Analysis-Visualization-Tool

老實說我們團隊目前大概只到 Level 0 吧,前陣子也才發生在生產環境上直接改 code 以及直接更改環境設定等事件,總是為了一些緊急情況做了這些處置(不得不妥協),這真的是一條漫漫長路阿,我也會跟各位讀者一樣,一起努力,讓自動化與頻繁發佈變成一種習慣與文化。

共勉之,大家一起加油!

#一起變強