持續交付：價值主張

軟件工程快速地從敏捷開發到持續集成、再到持續交付的發展，如何才能跟上互聯網大規模協做的軟件進程？持續交付不是作不作的問題，而是不得不作、如何去作、如何作好的問題。

 

英文連接：Continuous Delivery: The Value Proposition

　　過去十年中，一個劃時代的改變就是：基於Web的業務模式對傳統企業業務模式的衝擊。亞馬遜就是歷史最長，也最明顯的例子之一，而愈來愈多的公司（從航空到金融服務）開始依賴軟件打造其競爭優點了。

　　依靠軟件來運行的業務有兩個關鍵組件：一是你想如何改變世界的願景，二是儘早收集用戶的反饋。精益創業運動特別強調反饋的重要性，這不只僅體如今創業公司。像亞馬遜、NetFlix、和臉譜這樣的公司也持續不斷地對其網站進行小步改進，從而增長收入，並改善網站用戶的體驗。

　　什麼是持續交付？

　　想在用戶與項目團隊（包括客戶或者Product Owner）之間創建緊密的反饋環，依賴於你是否有這樣的能力，即：經過持續交付新的軟件版本，驗證新的想法和軟件的改動，並能衡量這些改動對收入的影響。

　　對於不少須要幾個月時間才能發佈新版本的公司來講，在一天以內發佈數次彷佛是天方夜譚。然而，遵循《持續交付》一書中的原則與實踐，一些原來一 年才能發佈幾回新版本的公司，也已經能在一個月內發佈數次，或者更頻繁了。這是一種巨大的競爭優點，並且意味着，在時間和精力方面減小了大量的浪費。

　　實際上，持續交付有兩個相當重要的業務收益：

• 第一，它讓你能更快地驗證新業務方案的結果，並根據真實的用戶反饋進行調整。尤爲是當業務方案有根本性缺陷時，你必定但願能儘早地發現，而不是花數月或數年的時間和大量的金錢來實施計劃後，才知道存在問題。
• 第二，與項目結束後的一次性大版本發佈相比，它能提供一種大幅下降交付風險的交付流程，並且成本的投入也更加具備可預見性。

　　另外，對於IT管理來講，它還提供另外兩種好處：

• 第一，項目經理們能看到項目的真實進度，由於，此時的「完成」是指：運行於真實生產環境中的可工做的軟件已經爲用戶帶來價值。
• 第二，經過規律性增量發佈，大大減小了每次發佈的風險。

　　實現持續交付

　　爲了可以成功實現持續交付，須要依賴於兩個基礎，一是技術基礎，二是組織基礎。而這兩個基礎有三大支柱：（1）全面的配置管理；（2）敏捷測試；（3）部署流水線。

　　配置管理：

　　就配置管理而言，爲了實現持續交付，有四個關鍵點：

• 第一，要能以全自動化的方式，構建、測試並部署你的應用。爲了作到這一點，源代碼、測試腳本、構建與部署腳本、數據庫遷移腳本等通通要歸入到版本管理。
• 第二，應用程序的部署時及運行時配置項須要以某種統一且集中地方式管理起來。
• 第三，要能用全自動化的流程在每種環境上建立或者進行配置變動。
• 第四，全部的開發工做必須在主幹上完成，並且，可以對較大的特性或重構作增量實現，以便應用程序一直保持在可工做狀態。若是必要的話，沒有開發完的特性能夠利用配置開關，使用戶沒法經過界面或公共接口使用它。

　　同時，有效的配置及發佈管理也依賴於整個交付過程當中開發團隊與運維團隊（包括DBA）之間的緊密合做。爲了確保運維需求被歸入項目考慮範圍，並 讓應用程序在開發初期就能部署到類生產環境中進行單一功能或跨功能測試，運維人員應在項目開始階段就成爲交付團隊的一員。這種協做也正是DevOps運動所倡導的重要的文化轉變之一。

　　敏捷測試

　　持續交付依賴的第二個支柱是敏捷測試方式。固然，它也一樣包含技術和組織兩方面。從工程角度來看，各個層次上的自動化測試是 必不可少的，包括單元級別、組件級別，系統級別（功能與非功能測試）。要確保作到：若是自動化組合套件所有成功經過了，那軟件自己就達到了可發佈質量， 即：在生產環境中沒有迴歸缺陷，知足業務須要——包括容量和可用性方面的要求。

　　敏捷測試要求在整個交付過程當中的質量內嵌。也就是說，測試再也不是一個「階段」，而應該是在整個交付過程當中持續發生的一種活動。一樣，軟件的質量 再也不只是測試人 員或QA的責任，而是整個交付團隊的責任。測試人員與分析人員應該在一塊兒，共同建立可測試的驗收條件。做爲開發過程的一部分，測試人員與開發人員應該合做 建立自動化的驗收測試，用於驗證所開發的內容知足驗證標準，這叫作「驗證測試驅動的開發（acceptance test-driven development）。開發人員要負責維護驗收測試，並確保它們一直能夠成功經過。

　　部署流水線

　　持續交付的第三個支柱是部署流水線。從本質上講，部署流水線是現有交付過程的一個模型，是整個價值流的一部分，即從提交到發佈的那一段價值流。能夠用像Go這 樣的工具對其進行建模。對於應用程序的任何修改（包括配置）都要從頭至尾經過這個部署流水線，即先對系統進行構建，並基於該構建產物運行自動化測試，而後 放到某處，以便後續部署到測試環境和生產環境。能夠把部署流水線看作是持續集成的一個延伸，即：它將持續集成從開發團隊擴展到了測試和運維團隊。

　　用來建模和管理部署流水線的工具會記錄每一次構建歷史，它會記錄每一個構建所對應的版本控制庫中的版本號，誰把它部署到了哪一個環境，何時部署 的，部署的結果是「成功」，仍是「失敗」。這個部署流水線應該強制你的部署工做流（包括認證和受權），並能對整個交付流程進行審計。因爲這個流水線是對你 的開發及部署過程進行建模，因此，它爲發現流程瓶頸，持續改進交付過程提供了豐富的數據支持。

　　經過持續交付來管理項目

　　毫無疑問，對於剛剛接觸持續交付的團隊來講，對其所要求的紀律性會感到吃驚。不少直覺上應該如何管理項目的方式（包括團隊成員之間如何互動）都 須要改變。對團隊來講，當實施持續交付時，和全部的敏捷方法同樣，最重要的事情是經過回顧，持續檢討他們正在作的事情，並對工做方式和過程作增量式的改 變，並不斷地改進它。

　　從新調整你的直覺

　　每一個項目天生都有一種節奏和風格。傳統的交付項目在項目開始和中期，總會有一個漂亮而體面的進度報告。然而，當到了某個時間點後，客戶和管理層 經常會有一些令其不悅的發現：儘管大部份內容都「開發完成」了，但在集成階段，部署到具備現實負載的類生產環境中的應用程序老是不能工做得很好。

　　此時，這個項目就進行了所謂的「兩難境地」，或叫「死亡行軍」，人們在很大的壓力上加班工做，試圖修復整個系統。這令每一個人都極不滿意，而事實上， 在某些領域，這種失控模式已經成爲一種屢見不鮮。

　　在那些實踐持續交付的項目中，開始時進展可能比較慢。由於項目一開始要創建基礎設施，對構建、測試和部署作自動化，並在獲得成功構建的產品後， 在類生產環境中執行驗收測試。這讓團隊成員，尤爲是剛接觸它的管理者，感到不舒服。然而，這正說明它起做用了。持續交付的影響表如今它把痛苦提早了，從而 讓交付過程更加平穩、真實且可度量。

　　你原來體會到的是「開發完成「，與「真正完成」不同。現實中，真正的「完成」是指發佈給用戶，或者至少在集成環境上嚴格地進行驗收和迴歸測試 後，在類生產環境中向客戶演示。在新功能開發完後，其實還有不少工做要作：交付過程當中的這部分被叫作最後一哩。持續交付堅持認爲：「只有過了這一哩」，工 做纔算完成，根本就沒有「完成了百分之五十」這個說法，因此，這讓整個交付進度看上去比較慢。

　　然 而，經過持續交付，你能獲得可持續性。首先，由於持續交付意味着軟件一直處於可發佈狀態，因此能夠把原來的測試與集成階段移掉，這就會大大下降項目風險。 在這兩個階段，常常會發現嚴重問題，甚至是整個架構的缺陷。而修復這些問題的時間則很難預期。經過持續交付，這些問題在交付過程的早期就會被發現，些修復 成本每每比較低。

　　其次，對於新開發的特性來講，能更快地從客戶和用戶那裏獲得反饋。經過增量開發和持續發佈給用戶，你能在特性創做過程當中就獲得早期反饋，並不斷調整。這樣，軟件的演進能夠更快速地知足用戶的需求。

　　設法進行增量開發

　　在主幹上增量開發時，爲了可以將大的特性拆分紅小的、有價值的、可測試且相對獨立的用戶故事，須要分析人員、測試人員及開發團隊的緊密合做。這麼作，有幾個好處。

　　可能最重要的好處就是，它促使團隊將一個功能裏，關鍵的部分和非關鍵部分區分開來，這讓客戶能在更小的粒度上作決策。將一個「必須作」的特性分解成多個小的、可增量開發的小需求，能更有效地區分出哪些是該功能的核心，哪些是外圍需求。

　　而後，你能夠將功能的核心部分（最初的最直接的實現）給用戶進行測試，並找出用戶接下來想作什麼。這樣能夠給客戶一些具體的數據，讓他們更好地 對該功能的剩餘工做進行優先級的排序。固然，也極可能在他們看過之後，客戶但願將後續的時間花在其它功能上了。並且，假如客戶看過之後。認爲這個特性沒有 什麼價值，你能夠立刻停下來，再也不浪費精力在這上面了。

　　增量開發依賴於每一個人天天都可以提交一次，這樣，應用程序才能夠持續集成。對於那些習慣於在長生命週期分支上開發新特性或每一個分支對應一類客戶 的團隊來講，這看上去是不可能的。好消息是，在主幹上開發是可行的，對於很大的團隊也是可行的。壞消息是，它要求應用程序由鬆耦合的組件構成，並有良好的 架構。它還要求，能夠經過配置項在UI上能控制特性的開與關，這樣，你才能能夠靈活地控制，當功能準備好後，再打開開關。即便一些新功能只開發到一半，你 也能持續地發佈你的軟件。

　　然而，這樣作的收益也很大：你能持續不斷地把已經作好的功能交付給客戶，而不用絞盡腦汁地猜想哪一個功能有價值。頻繁地發佈有價值的新功能是提升收入的 最好方式。

　　我怎麼知道我是否是真的在持續交付？

　　持續交付是否須要一個像「Nokia 測試」那樣的checklist呢？實際上，沒有那個必要，由於有一個很是簡單的方法來驗證，你是否是真的在持續交付：你的軟件是否是一直處於產品可發佈 狀態。你只要按個回車鍵就能夠把 它發佈給用戶。若是你的發佈過程很痛苦，並且不太頻繁，而且在發佈以前還有一個充滿風險的集成階段，那麼你就沒有在作持續交付。

　　持續交付中最重要的度量是週期時間（cycle time）：從決定實現某個想法開始，到將其發佈給用戶爲止這段時間長度。有幾個緣由讓它成爲一個很重要的度量：

• 第一，這是一個全局度量指標，用於度量整個過程的有效性。
• 第二，這是一個團隊度量指標，而不是一個我的度量指標——只整個團隊關注於改進交付過程，纔有可能改變週期時間。

　　部署流水線提供了部分答案：部署流水線的實現會給你提供一些你須要的數據，主要是從提交到發佈這段時間的。那麼，只要你有一種方式將提交與特性關聯起來，你就能夠看到某個特性的週期時間。若是如今的工具不能讓你收集這些數據，那就找一個去吧。

　　這樣，你就能夠制定一個持續改進流程，應用約束理念 ，或者使用看板，在交付過程當中找到瓶頸，並想辦法移除它們。持續交付能夠也應該一樣使用持續改進的方式減小成本，提升收入的增量地方式實現。