過去十年中，一個劃時代的改變就是：基於Web的業務模式對傳統企業業務模式的衝擊。亞馬遜就是歷史最長，也最明顯的例子之一，而越來越多的公司（從航空到金融服務）開始依賴軟件打造其競爭優勢了。
依靠軟件來運行的業務有兩個關鍵組件：一是你想如何改變世界的願景，二是儘早收集用戶的反饋。精益創業運動特別強調反饋的重要性，這不僅僅體現在創業公司。像亞馬遜、NetFlix、和臉譜這樣的公司也持續不斷地對其網站進行小步改進，從而增加收入，並改善網站用戶的體驗。
什麼是持續交付？
想在用戶與項目團隊（包括客戶或者Product Owner）之間建立緊密的反饋環，依賴於你是否有這樣的能力，即：通過持續交付新的軟件版本，驗證新的想法和軟件的改動，並能衡量這些改動對收入的影響。
對於很多需要幾個月時間才能發佈新版本的公司來說，在一天之內發佈數次似乎是天方夜譚。然而，遵循《持續交付》一書中的原則與實踐，一些原來一年才能發佈幾次新版本的公司，也已經能在一個月內發佈數次，或者更頻繁了。這是一種巨大的競爭優勢，而且意味着，在時間和精力方面減少了大量的浪費。
實際上，持續交付有兩個至關重要的業務收益：
- 第一，它讓你能更快地驗證新業務方案的結果，並根據真實的用戶反饋進行調整。尤其是當業務方案有根本性缺陷時，你一定希望能儘早地發現，而不是花數月或數年的時間和大量的金錢來實施計劃後，才知道存在問題。
- 第二，與項目結束後的一次性大版本發佈相比，它能提供一種大幅降低交付風險的交付流程，而且成本的投入也更加具有可預見性。
另外，對於IT管理來說，它還提供另外兩種好處：
- 第一，項目經理們能看到項目的真實進度，因爲，此時的“完成”是指：運行於真實生產環境中的可工作的軟件已經爲用戶帶來價值。
- 第二，通過規律性增量發佈，大大減少了每次發佈的風險。
實現持續交付
爲了能夠成功實現持續交付，需要依賴於兩個基礎，一是技術基礎，二是組織基礎。而這兩個基礎有三大支柱：（1）全面的配置管理；（2）敏捷測試；（3）部署流水線。
配置管理：
就配置管理而言，爲了實現持續交付，有四個關鍵點：
- 第一，要能以全自動化的方式，構建、測試並部署你的應用。爲了做到這一點，源代碼、測試腳本、構建與部署腳本、數據庫遷移腳本等統統要納入到版本管理。
- 第二，應用程序的部署時及運行時配置項需要以某種統一且集中地方式管理起來。
- 第三，要能用全自動化的流程在每種環境上創建或者進行配置變更。
- 第四，所有的開發工作必須在主幹上完成，而且，能夠對較大的特性或重構做增量實現，以便應用程序一直保持在可工作狀態。如果必要的話，沒有開發完的特性可以利用配置開關，使用戶無法通過界面或公共接口使用它。
同時，有效的配置及發佈管理也依賴於整個交付過程中開發團隊與運維團隊（包括DBA）之間的緊密合作。爲了確保運維需求被納入項目考慮範圍，並讓應用程序在開發初期就能部署到類生產環境中進行單一功能或跨功能測試，運維人員應在項目開始階段就成爲交付團隊的一員。這種協作也正是DevOps運動所倡導的重要的文化轉變之一。
敏捷測試
持續交付依賴的第二個支柱是敏捷測試方式。當然，它也同樣包含技術和組織兩方面。從工程角度來看，各個層次上的自動化測試是必不可少的，包括單元級別、組件級別，系統級別（功能與非功能測試）。要確保做到：如果自動化組合套件全部成功通過了，那軟件本身就達到了可發佈質量，即：在生產環境中沒有迴歸缺陷，滿足業務需要——包括容量和可用性方面的要求。
敏捷測試要求在整個交付過程中的質量內嵌。也就是說，測試不再是一個“階段”，而應該是在整個交付過程中持續發生的一種活動。同樣，軟件的質量不再只是測試人 員或QA的責任，而是整個交付團隊的責任。測試人員與分析人員應該在一起，共同創建可測試的驗收條件。作爲開發過程的一部分，測試人員與開發人員應該合作創建自動化的驗收測試，用於驗證所開發的內容滿足驗證標準，這叫做“驗證測試驅動的開發（acceptance test-driven development）。開發人員要負責維護驗收測試，並確保它們一直可以成功通過。
部署流水線
持續交付的第三個支柱是部署流水線。從本質上講，部署流水線是現有交付過程的一個模型，是整個價值流的一部分，即從提交到發佈的那一段價值流。可以用像Go這 樣的工具對其進行建模。對於應用程序的任何修改（包括配置）都要從頭到尾通過這個部署流水線，即先對系統進行構建，並基於該構建產物運行自動化測試，然後放到某處，以便後續部署到測試環境和生產環境。可以把部署流水線看做是持續集成的一個延伸，即：它將持續集成從開發團隊擴展到了測試和運維團隊。
用來建模和管理部署流水線的工具會記錄每一次構建歷史，它會記錄每個構建所對應的版本控制庫中的版本號，誰把它部署到了哪個環境，什麼時候部署的，部署的結果是“成功”，還是“失敗”。這個部署流水線應該強制你的部署工作流（包括認證和授權），並能對整個交付流程進行審計。由於這個流水線是對你的開發及部署過程進行建模，所以，它爲發現流程瓶頸，持續改進交付過程提供了豐富的數據支持。
通過持續交付來管理項目
毫無疑問，對於剛剛接觸持續交付的團隊來說，對其所要求的紀律性會感到喫驚。很多直覺上應該如何管理項目的方式（包括團隊成員之間如何互動）都需要改變。對團隊來說，當實施持續交付時，和所有的敏捷方法一樣，最重要的事情是通過回顧，持續反省他們正在做的事情，並對工作方式和過程做增量式的改變，並不斷地改進它。
重新調整你的直覺
每個項目天生都有一種節奏和風格。傳統的交付項目在項目開始和中期，總會有一個漂亮而體面的進度報告。然而，當到了某個時間點後，客戶和管理層常常會有一些令其不悅的發現：儘管大部分內容都“開發完成”了，但在集成階段，部署到具有現實負載的類生產環境中的應用程序總是不能工作得很好。
此時，這個項目就進行了所謂的“兩難境地”，或叫“死亡行軍”，人們在很大的壓力上加班工作，試圖修復整個系統。這令每個人都極不滿意，而事實上， 在某些領域，這種失控模式已經成爲一種家常便飯。
在那些實踐持續交付的項目中，開始時進展可能比較慢。因爲項目一開始要建立基礎設施，對構建、測試和部署做自動化，並在得到成功構建的產品後，在類生產環境中執行驗收測試。這讓團隊成員，尤其是剛接觸它的管理者，感到不舒服。然而，這正說明它起作用了。持續交付的影響表現在它把痛苦提前了，從而讓交付過程更加平穩、真實且可度量。
你原來體會到的是“開發完成“，與“真正完成”不一樣。現實中，真正的“完成”是指發佈給用戶，或者至少在集成環境上嚴格地進行驗收和迴歸測試後，在類生產環境中向客戶演示。在新功能開發完後，其實還有很多工作要做：交付過程中的這部分被叫做最後一哩。持續交付堅持認爲：“只有過了這一哩”，工作纔算完成，根本就沒有“完成了百分之五十”這個說法，所以，這讓整個交付進度看上去比較慢。
然 而，通過持續交付，你能得到可持續性。首先，因爲持續交付意味着軟件一直處於可發佈狀態，所以可以把原來的測試與集成階段移掉，這就會大大降低項目風險。在這兩個階段，經常會發現嚴重問題，甚至是整個架構的缺陷。而修復這些問題的時間則很難預期。通過持續交付，這些問題在交付過程的早期就會被發現，些修復成本往往比較低。
其次，對於新開發的特性來說，能更快地從客戶和用戶那裏得到反饋。通過增量開發和持續發佈給用戶，你能在特性創作過程中就得到早期反饋，並不斷調整。這樣，軟件的演進可以更快速地滿足用戶的需求。
設法進行增量開發
在主幹上增量開發時，爲了能夠將大的特性拆分成小的、有價值的、可測試且相對獨立的用戶故事，需要分析人員、測試人員及開發團隊的緊密合作。這麼做，有幾個好處。
可能最重要的好處就是，它促使團隊將一個功能裏，關鍵的部分和非關鍵部分區分開來，這讓客戶能在更小的粒度上做決策。將一個“必須做”的特性分解成多個小的、可增量開發的小需求，能更有效地區分出哪些是該功能的核心，哪些是外圍需求。
然後，你可以將功能的核心部分（最初的最直接的實現）給用戶進行測試，並找出用戶接下來想做什麼。這樣可以給客戶一些具體的數據，讓他們更好地對該功能的剩餘工作進行優先級的排序。當然，也很可能在他們看過以後，客戶希望將後續的時間花在其它功能上了。而且，假如客戶看過以後。認爲這個特性沒有什麼價值，你可以馬上停下來，不再浪費精力在這上面了。
增量開發依賴於每個人每天都能夠提交一次，這樣，應用程序纔可以持續集成。對於那些習慣於在長生命週期分支上開發新特性或每個分支對應一類客戶的團隊來說，這看上去是不可能的。好消息是，在主幹上開發是可行的，對於很大的團隊也是可行的。壞消息是，它要求應用程序由松耦合的組件構成，並有良好的架構。它還要求，可以通過配置項在UI上能控制特性的開與關，這樣，你才能可以靈活地控制，當功能準備好後，再打開開關。即使一些新功能只開發到一半，你也能持續地發佈你的軟件。
然而，這樣做的收益也很大：你能持續不斷地把已經做好的功能交付給客戶，而不用絞盡腦汁地猜測哪個功能有價值。頻繁地發佈有價值的新功能是提高收入的 最好方式。
我怎麼知道我是不是真的在持續交付？
持續交付是否需要一個像“Nokia 測試”那樣的checklist呢？實際上，沒有那個必要，因爲有一個非常簡單的方法來驗證，你是不是真的在持續交付：你的軟件是不是一直處於產品可發佈狀態。你只要按個回車鍵就可以把 它發佈給用戶。如果你的發佈過程很痛苦，而且不太頻繁，並且在發佈之前還有一個充滿風險的集成階段，那麼你就沒有在做持續交付。
持續交付中最重要的度量是週期時間（cycle time）：從決定實現某個想法開始，到將其發佈給用戶爲止這段時間長度。有幾個原因讓它成爲一個很重要的度量：
- 第一，這是一個全局度量指標，用於度量整個過程的有效性。
- 第二，這是一個團隊度量指標，而不是一個個人度量指標——只整個團隊關注於改進交付過程，纔有可能改變週期時間。
部署流水線提供了部分答案：部署流水線的實現會給你提供一些你需要的數據，主要是從提交到發佈這段時間的。那麼，只要你有一種方式將提交與特性關聯起來，你就可以看到某個特性的週期時間。如果現在的工具不能讓你收集這些數據，那就找一個去吧。
這樣，你就可以制定一個持續改進流程，應用約束理念 ，或者使用看板，在交付過程中找到瓶頸，並想辦法移除它們。持續交付可以也應該同樣使用持續改進的方式減少成本，提高收入的增量地方式實現。
關於更多關於“持續交付”的原則、實踐與案例，請猛擊這裏，訪問持續交付中文站。
原文刊登於InfoIT。