持續傳遞：價值主張​

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

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

什麼是持續傳遞？

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

對於很多需要幾個月時間才能發布新版本的公司來說，在一天之內發布數次似乎是天方夜譚。然而，遵循《持續傳遞》一書中的原則與實踐，一些原來一年才能發布幾次新版本的公司，也已經能在一個月內發布數次，或者更頻繁了。這是一種巨大的競爭優勢，而且意味著，在時間和精力方面減少了大量的浪費。

實際上，持續傳遞有兩個至關重要的業務收益：

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

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

• 第一，專案經理們能看到項目的真實進度，因為，此時的“完成”是指：運行於真實生產環境中的可工作的軟體已經為使用者帶來價值。
• 第二，通過規律性增量發布，大大減少了每次發布的風險。

實現持續傳遞

為了能夠成功實現持續傳遞，需要依賴於兩個基礎，一是技術基礎，二是組織基礎。而這兩個基礎有三大支柱：（1）全面的組態管理；（2）敏捷測試；（3）部署流水線。

組態管理：

就組態管理而言，為了實現持續傳遞，有四個關鍵點：

• 第一，要能以全自動化的方式，構建、測試並部署你的應用。為了做到這一點，原始碼、測試指令碼、構建與部署指令碼、資料庫遷移指令碼等統統要納入到版本管理。
• 第二，應用程式的部署時及運行時配置項需要以某種統一且集中地方式管理起來。
• 第三，要能用全自動化的流程在每種環境上建立或者進行配置變更。
• 第四，所有的開發工作必須在主幹上完成，而且，能夠對較大的特性或重構做增量實現，以便應用程式一直保持在可工作狀態。如果必要的話，沒有開發完的特性可以利用配置開關，使使用者無法通過介面或公用介面使用它。

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

敏捷測試

持續傳遞依賴的第二個支柱是敏捷測試方式。當然，它也同樣包含技術和組織兩方面。從工程角度來看，各個層次上的自動化測試是必不可少的，包括單元層級、組件層級，系統層級（功能與非功能測試）。要確保做到：如果自動化組合套件全部成功通過了，那軟體本身就達到了可發布品質，即：在生產環境中沒有迴歸缺陷，滿足業務需要——包括容量和可用性方面的要求。

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

部署流水線

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

用來建模和管理部署流水線的工具會記錄每一次構建曆史，它會記錄每個構建所對應的版本控制庫中的版本號碼，誰把它部署到了哪個環境，什麼時候部署的，部署的結果是“成功”，還是“失敗”。這個部署流水線應該強制你的部署工作流程（包括認證和授權），並能對整個交付流程進行審計。由於這個流水線是對你的開發及部署過程進行建模，所以，它為發現流程瓶頸，持續改進交付過程提供了豐富的資料支援。

通過持續傳遞來管理項目

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

重新調整你的直覺

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

此時，這個項目就進行了所謂的“兩難境地”，或叫“死亡行軍”，人們在很大的壓力上加班工作，試圖修複整個系統。這令每個人都極不滿意，而事實上，
在某些領域，這種失控模式已經成為一種家常便飯。

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

你原來體會到的是“開發完成“，與“真正完成”不一樣。現實中，真正的“完成”是指發布給使用者，或者至少在Integration Environment上嚴格地進行驗收和迴歸測試後，在類生產環境中向客戶示範。在新功能開發完後，其實還有很多工作要做：交付過程中的這部分被叫做最後一哩。持續傳遞堅持認為：“只有過了這一哩”，工作才算完成，根本就沒有“完成了百分之五十”這個說法，所以，這讓整個交付進度看上去比較慢。

然 而，通過持續傳遞，你能得到可持久性。首先，因為持續傳遞意味著軟體一直處於可發布狀態，所以可以把原來的測試與整合階段移掉，這就會大大降低項目風險。在這兩個階段，經常會發現嚴重問題，甚至是整個架構的缺陷。而修複這些問題的時間則很難預期。通過持續傳遞，這些問題在交付過程的早期就會被發現，些修複成本往往比較低。

其次，對於新開發的特性來說，能更快地從客戶和使用者那裡得到反饋。通過漸進式開發和持續發布給使用者，你能在特性創作過程中就得到早期反饋，並不斷調整。這樣，軟體的演化可以更快速地滿足使用者的需求。

設法進行漸進式開發

在主幹上漸進式開發時，為了能夠將大的特性拆分成小的、有價值的、可測試且相對獨立的使用者故事，需要分析人員、測試人員及Team Dev的緊密合作。這麼做，有幾個好處。

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

然後，你可以將功能的核心部分（最初的最直接的實現）給使用者進行測試，並找出使用者接下來想做什麼。這樣可以給客戶一些具體的資料，讓他們更好地對該功能的剩餘工作進行優先順序的排序。當然，也很可能在他們看過以後，客戶希望將後續的時間花在其它功能上了。而且，假如客戶看過以後。認為這個特性沒有什麼價值，你可以馬上停下來，不再浪費精力在這上面了。

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

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

我怎麼知道我是不是真的在持續傳遞？

持續傳遞是否需要一個像“Nokia 測試”那樣的checklist呢？實際上，沒有那個必要，因為有一個非常簡單的方法來驗證，你是不是真的在持續傳遞：你的軟體是不是一直處於產品可發布狀態。你只要按個斷行符號鍵就可以把 它發布給使用者。如果你的發布過程很痛苦，而且不太頻繁，並且在發布之前還有一個充滿風險的整合階段，那麼你就沒有在做持續傳遞。

持續傳遞中最重要的度量是周期時間（cycle time）：從決定實現某個想法開始，到將其發布給使用者為止這段時間長度。有幾個原因讓它成為一個很重要的度量：

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

部署流水線提供了部分答案：部署流水線的實現會給你提供一些你需要的資料，主要是從提交到發布這段時間的。那麼，只要你有一種方式將提交與特性關聯起來，你就可以看到某個特性的周期時間。如果現在的工具不能讓你收集這些資料，那就找一個去吧。

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

關於更多關於“持續傳遞”的原則、實踐與案例，請猛擊這裡，訪問持續傳遞中文站。

原文刊登於InfoIT。