如何才能做到持續交付？

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

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

　　​什么是持續交付?

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

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

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

　　第一，它讓你能更快地驗證新業務方案的結果，并根據真實的用戶反饋進行調整。尤其是當業務方案有根本性缺陷時，你一定希望能盡早地發現，而不是花數月或數年的時間和大量的金錢來實施計劃后，才知道存在問題。

　　第二，與項目結束后的一次性大版本發布相比，它能提供一種大幅降低交付風險的交付流程，而且成本的投入也更加具有可預見性。

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

　　第一，項目經理們能看到項目的真實進度，因為，此時的“完成”是指：運行于真實生產環境中的可工作的軟件已經為用戶帶來價值。

　　第二，通過規律性增量發布，大大減少了每次發布的風險。

　　實現持續交付

　　為了能夠成功實現持續交付，需要依賴于兩個基礎，一是技術基礎，二是組織基礎。而這兩個基礎有三大支柱：(1)全面的配置管理;(2)敏捷測試;(3)部署流水線。

　　配置管理：

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

　　第一，要能以全自動化的方式，構建、測試并部署你的應用。為了做到這一點，源代碼、測試腳本、構建與部署腳本、數據庫遷移腳本等統統要納入到版本管理。

　　第二，應用程序的部署時及運行時配置項需要以某種統一且集中地方式管理起來。

　　第三，要能用全自動化的流程在每種環境上創建或者進行配置變更。

　　第四，所有的開發工作必須在主干上完成，而且，能夠對較大的特性或重構做增量實現，以便應用程序一直保持在可工作狀態。如果必要的話，沒有開發完的特性可以利用配置開關，使用戶無法通過界面或公共接口使用它。

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

　　敏捷測試

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

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

　　部署流水線

　　持續交付的第三個支柱是部署流水線。從本質上講，部署流水線是現有交付過程的一個模型，是整個價值流的一部分，即從提交到發布的那一段價值流?？梢杂孟馟o這 樣的工具對其進行建模。對于應用程序的任何修改(包括配置)都要從頭到尾通過這個部署流水線，即先對系統進行構建，并基于該構建產物運行自動化測試，然后放到某處，以便后續部署到測試環境和生產環境?？梢园巡渴鹆魉€看做是持續集成的一個延伸，即：它將持續集成從開發團隊擴展到了測試和運維團隊。

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

　　通過持續交付來管理項目

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

　　重新調整你的直覺

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

原文轉自：http://www.anti-gravitydesign.com