持續交付2.0

業務引領的 DevOps 精要

前言

自「軟體工程」一詞誕生以降，「質量」與「效率」就是開發的目標。
我們從過往的瀑布式開發、 V-Model、Scrum 到現在的 DevOps，甚至到後來《持續交付》，這些目的都是要發布軟體服務產生商業價值。
因而作者撰寫了這本《持續交付2.0》，目的是要說在 VUCA 的環境下，比過往的持續交付精神更加地強調「業務精神」！到底在說什麼呢？

以「業務引領」的持續交付架構

本書除了討論交付軟體技術面的課題，更強調了以業務驅動交付價值的概念

- 良好的企業文化

• 作者在書中提到四個步驟「定義想要做的事情」、「定義期望做事的方法」、「提供相應的培訓」、「做必須的事情強化那些行為」，是為了呼應持續交付 2.0 的內容。
• 組織文化一直都是影響商業變革過程，這本書認為企業要做到「失敗是安全的」、「相互信任」以及「持續改善」，才能開始談整個。

- 持續交付 2.0

• 雖然作者在書中的最前面兩個章節重新定義 DevOps 環，他認為環要有兩個圈，分別是探索環跟快速驗證環。
• 前者是專注在探索 Why，為什麼我要做這件事情，背後的意義與價值分別是什麼，透過「提問」、「錨定」、「共創」、「精煉」四步驟來驗證業務問題，找出最大的風險點，進而用最小的成本驗證概念並找出解決方案(或是決策)。
• 接著就使用快速驗證環將前面環所產出的決策進行「建構」「運行」「監測」「決策」，驗證前面精煉過後的解決方案作驗證，如此得到的結果就可再度放進探索環中，如此循環不息，逐步完善。

- 軟體架構

• 商業需求產生開發策略，開發策略因而產生對應的架構
• 「架構」與「需求」如何滿足以持續交付為主的進行方式？書中提到的將系統改為 SOA 架構，並且拆分成小的，書中提了 5 個面向設計(Design for X)，4個拆分原則，3 架構，3模式供讀者參考。
• 有需求才有生產，在第六章提到如何管理需求、以及技術債，書中將達到完成產品版本週期的迭代，分為準備期與交付期該完成什麼重點事項，以及介紹現行的許多需求分析以及管理方法讓大家可以達到持續交付。

讀了這本書之後，我認為書的順序改成先了解組織文化，再來談環的運行會比較好。

持續交付的流水線

提到持續交付，就一定免不了下面幾項：

1. 設計部署流水線
2. 如何做版控
3. 自動化測試
4. 持續整合
5. 持續部署
6. 配置管理
7. 監視系統運作是否正常

書中中段的一大部分都在描述這類內容，我將其拆為三類做分享： CI、CD、Provisioning

為了達成持續交付的流水線，書中的觀點是：盡可能達成流程的自動化、提交能自動觸發部署流水線，有遇到問題要停止並當下解決問題。

- 環境配置

• 好的配置管理是交付流水線的基石，因為在一切自動化的基礎下，要如何確保我的產出物有沒有相依到對的套件或 package？這章正是探討怎麼實踐良好的配置管理。

- 持續整合

• 分支策略：在開發軟體的過程中，一定會與他人協作程式碼開發，就會遇到整合的問題，書中介紹了幾個策略讓讀者可以根據自己的專案做量身打造。
• 持續整合：確保每個人提交都是有價值、能運作的程式碼，如果有提交問題要修正；書中也提到一些技巧如「六步提交法」幫助團隊建立起持續整合的團隊精神，搭配前面的分支策略讓專案開發更佳順暢
• 自動化測試：沒有測試，便不能驗證做出來的東西是否有幫助，如果我們每次的提交都能被驗證，那非常好，但是人工的話很沒效率，因此將重複的測試自動化，或是為舊有的系統加入測試碼，是這個章節在討論的。

- 持續部署

• 低風險發布：發布一個軟體令人興奮，但是過往的發布常常失敗，造成加班。現在都追求快速部署來爭取市場，那要如何降低發布風險？書中介紹了幾個部署方式，像是「藍綠部署」、「金絲雀部署」等方法來降低發布風險！

- 生產環境的監視

• 收集數據是這個章節的一大重點，透過收集不同的數據整理成不同的資訊幫助我們決斷要做哪件事情，書中分為三大類：基礎監視、應用監視、業務監視
• 上面所提的監視都是為了做不同的處理而分層次的，同時，收集到的資料將會決定往新的開發或是精煉現有的軟體前進。

團隊組建

有了商業想法以及流程後，謀事在人，因此書中最後講述了團隊的組建。

- 大型團隊

• 大團隊最辛苦的地方在於因為第一印象被認為人多，所以就事情特別多，且又留下不少過往的遺留系統，難以整合，因此書中介紹了將其組成多的 Feature Team，並且每個團隊都實踐《持續交付2.0》所指導的內容，因此將軟體架構、組織成功解耦，成為一個成功的流程再造、變革管理的經典案例之一。

- 小型團隊

• 並非只有大團隊才能實踐《持續交付2.0》，書中也介紹了小團隊如何從工作地獄中成功轉型為「零缺陷交付」的持續改善歷程。背景案例很有趣的是該團隊一開始便實施 Scrum 方法進行開發，所以書中強調此團隊透過優化部分流程，導入看板法等，成功的提高了產能與軟體交付的質量。

- 推動 DevOps

• 最後的團隊案例是介紹擁有 PMO 管理結構的公司，如何從 Scrum101(Water-Scrum-Fall) 轉型到 DevOps 的過程，一樣透過實踐《持續交付2.0》的精神，搭配流程再造，最終打造出良好的 DevOps 文化。

總結

如果你是正在思考團隊變革，或是希望能夠在團隊實施持續交付，但是卻苦於不知道如何開始，或者是不知道使用哪種方法，務必拿這本書翻一翻，因為真的很多可以馬上拿來實踐在自己團隊上，再根據自己的團隊所處的企業環境以及組織政策做調適，變成你們團隊自己的《持續交付2.0》。
最後送給大家一句書中所寫的心法：「別提敏捷，只解決問題！」