持續交付：巨大的益處也伴隨著巨大的挑戰

本文最初發表在 IEEE軟件 雜志上， IEEE 軟件 雜志致力于發表嚴謹的、經過互相審校的文章，專注于當今世界的戰略科技。 為了滿足運行可靠且靈活企業所面臨的挑戰， IT 經理和技術管理者依賴 IT Pro 獲取最先進的解決方案 。

持續交付（CD）是一種軟件工程方法，團隊通過這種方式保持在短周期內生產有價值的軟件，并且保證能夠可靠地在任何時間發布軟件。CD正在獲得越來越多的關注與支持。

CD的提倡者認為它能夠讓組織變得更加迅速、高效，并且能夠可靠地為市場帶來服務方面的改善，并且最終能夠在競爭中脫穎而出 ¹ 。聽起來很棒，但實現CD可能會是一個很有挑戰的過程，尤其在一些已經形成了固定的發布環境的大公司中顯得尤為突出。

在本文中，我將介紹Paddy Power是如何實施CD的，這是一家書籍制作公司。我將描述我們最終實現的CD的能力，它所帶來的巨大利益，以及過程中所遇到的各種挑戰。這些經驗將為 其他實踐者提供一種實施CD的洞察力，而我們所指出的這些挑戰將為研究者們在設計自己的研究日程時提供一些有價值的參考。

背景

Paddy Power是一家發展迅速的公司，它的營業額大約在60億歐元，總共有大約4千名員工。它的服務遍及各種管控市場，通過投注點，電話和互聯網等方式提供服務。

公司的成長在相當程度上依靠的是不斷增長的大量自定義軟件應用程序。這些應用包括網站、移動應用、交易與價格系統、實時博彩數據分布系統，以及用 于投注點的軟件。開發這些軟件時用到了各種不同的技術棧，包括Java、Ruby、PHP和 .NET。為了運行這些應用，公司的IT基礎設施由跨越不同地區的數千臺服務器所構成。

這些應用是由技術部門負責開發與維護的，部門共有大約400名員工。每個軟件開發團隊的規模取決于應用的規模與復雜度，我們團隊的人數在2到26 人之間浮動，而多數團隊的規模在4到8人之間。每個應用的發布周期也各有不同。在過去，每個應用在一年之內的發布次數一般不超過6次。在每個發布周期內， 我們在周期的一開始收集各種需求，工程師們在幾個月的時間內進行開發工作，在周期結束前進行大量的測試與bug修復工作。隨后開發者將完成的軟件移交給運 維工程師，以部署到生產環境上。部署過程包含了大量的手工操作。

這種發布模式人為地拖延了在發布周期早期已完成的特性。這些特性能夠帶來的價值也被浪費了，而且無法獲得這些特性的早期反饋。

許多發布過程都是一種“恐怖”的體驗，因為這些發布流程沒有經過長期的實踐，并且其中包含了大量容易出錯的手工操作。由手工配置造成的一級故障并不鮮見。此外，發布操作缺乏效率，僅僅是搭建測試環境這一項就需要花上三個星期的時間。

為了改善這種情況，Paddy Power啟動了一個實施CD的計劃，公司創建了一個共有8人組成的專屬團隊，這些成員都具有兩年以上的相關經驗。

持續交付管道

因為我們必須要支持多種不同的應用程序，因此我們搭建了一個平臺，我們在平臺中為每個應用創建了一個CD管道。我們團隊將負責這個平臺的操作與維護，如果某個應用程序的開發團隊需要為他們的應用創建一個新的CD管道，就由我們來創建。

一個應用程序的管道與另一個應用的管道在階段的數量與類型上可能會有細微的差別，以實現對該應用的最優化。圖一展示了一個管道的示例。

代碼提交

代碼提交管道能夠為開發者所簽入的代碼提供第一時間的初始反饋。當某個開發者往軟件配置管理庫中簽入代碼時，這個階段就會自動觸發，對代碼進行編 譯并執行單元測試。當這個階段出現錯誤時，管道會自動中止并通知開發者。開發者隨即修改代碼，對變更進行結對審查，然后簽入新代碼。代碼提交階段將會再次 被觸發，并再次啟動管道的運行。如果一切正常的話，管道會自動進入下一階段。

圖1 —— 一個持續交付管道的示例。推進（promotion）—— 將管道的執行從一個階段轉向下一階段，可以自動執行或手工執行。隨著構建過程通過一個個管道中的階段，我們對于這次構建能夠在生產環境中正常運行的信心也在不斷增加。

構建

構建階段將會再次執行單元測試并生成一個代碼覆蓋率報告，隨后運行集成測試以及各種靜態代碼分析，并構建出需要發布的內容，然后將待發布內容上傳 到管理它們的庫中，以備部署或分布。之后的每個管道階段在運行中都會接觸到這些待發布內容。在我們使用CD實踐之前，發布到生產環境中的二進制文件可能會 與測試過的二進制文件不同，原因在于我們在每個階段中都會對這個軟件進行一次構建。而每次對軟件進行構建都有可能造成不同的結果，我們也經歷過由于不同的 編譯結果造成的bug。修復這種bug是一種非常令人受挫的體驗，因為同樣的軟件能夠在開發者與測試人員的環境中運行，卻無法在生產環境中正常運行。而 CD管道能夠消除這種bug，如果發生了任何錯誤，管道會立即停止并通知開發者，否則它將會自動進入下一階段。

驗收測試

驗收測試階段的主要目的是確保軟件完全符合用戶的需求。這一階段將創建驗收測試環境，這是一種類似于生產環境的環境，軟件將會部署在其中。這一階 段的流程包括加載服務器，對其進行配置（例如配置網絡與安全設置），將軟件部署在這些服務器上，并配置這些軟件。管道將會在這個環境中運行驗收測試集。

之前，搭建這個環境完全是手工完成的。在最復雜的一個應用程序中，搭建過程花費了某個開發者兩個星期的時間。即使對于小型應用來說，這一過程也要耗費半天時間。

對于新項目來說，搭建過程會更長。開發者需要向基礎設施團隊申請新的機器，請求Unix或Windows工程團隊配置這些機器，請求網絡工程師打開這些機器之間的連接，等等。整個過程會耗費一個月時間。

而在CD管道中，開發者不需要再進行這些活動了，管道會自動在幾分鐘之內完成整個環境的搭建。

與其它幾個階段類似，如果這一階段中出現了差錯，管道會立即停止并通知開發者，否則它將會自動進入下一階段。

圖2 —— 持續交付的益處。公司受到了這些益處的鼓舞，因此加大了對CD的投入。

性能測試

性能測試階段將衡量代碼變更會對軟件的性能產生怎樣的影響。管道會搭建性能測試環境，在這個環境中執行性能測試集，并將測試結果寫入對軟件質量進行集中式管理的工具中。

坦白地說，由于搭建一個性能測試環境所需要的精力投入過大，之前我們并沒有在開發階段中進行任何性能測試，我們只在大型發布之前才會執行性能測 試。而在CD管道中，每個通過了之前階段的代碼提交都會執行性能測試。開發者們能夠立即了解代碼的變更是否降低了軟件的性能。在這個時間點對問題進行診斷 以及修復比起在大型發布前修復問題的成本低得多。

手工測試

雖然我們的自動化測試已經很完善了，但有時手工測試還是必要的（比方說測試人員進行的探索性測試，以及業務人員進行的用戶驗收測試。） ²

之前，測試人員必要搭建一個手工測試環境，這讓他們感覺十分頭疼，因為中間包括了太多的手工、并且容易出錯的步驟。

而在CD流程中，他們不必再擔心這一點了。管道會自動搭建測試環境，并通過電子郵件通知測試人員訪問已部署的應用所需的一切信息。

當測試人員對測試結果感到滿意后，待發布的內容將從“潛在發布候選”狀態推進為“發布候選”狀態。此時，軟件已經通過了所有質量檢測，做好了部署 到生產環境的一切準備，只需一個按鈕就能夠將軟件發布到生產環境上。而之前，這種部署有時會因為部署流程和腳本的錯誤失敗。在CD中不存在手工部署步驟， 并且部署流程和腳本在之前的階段中已經經過了多次測試。

益處

目前為止，我們已經將20個應用程序轉移到CD流程中了，這些應用是由一個最大的軟件開發團隊開發的，他們的主要用戶是公司內部的業務人員。在所有的軟件團隊將應用程序轉移到CD的過程中，他們都實施了一種名為Kanban的敏捷方法 ³ 。

在這些應用程序中，CD體現出了以下6點主要的益處（見圖2）

加速了進入市場的時間

發布的頻繁大大提升了。在之前，每隔一至六個月才會有一次應用程序的發布。而如今，每個應用平均每周發布一次。某些應用在必要時可以在一天之內進行多次發布。

一個用戶故事從概念階段到進入生產環境的周期從幾個月縮減到了2至5天。

CD讓我們能夠將新軟件發布中內在的商業價值更快地交付給用戶，這種能力幫助公司在當今互相競爭的經濟環境中脫穎而出，

創建正確的產品

頻繁的發布能夠讓應用程序的開發團隊更快地獲取用戶的反饋，這使他們能夠專注于創建實用的特性。如果他們發現某個特性缺乏實用性，他們將停止對它 的繼續投入，這將幫助他們創建正確的產品。而之前，團隊可能會花費大量時間用于創建缺乏實用性的特性，而他們無法發現這一點，直到下一次重大的發布之后。 而在這時，他們已經在這些特性上白白浪費了幾個月的時間。

改進了生產力和效率

生產力和效率也得到了極大的改善。比方說，開發者們為了搭建并修復測試環境所消耗的時間曾經達到20%。而如今，CD管道會自動搭建這些環境。與之類似，測試人員也曾經花費了大量的時間用以搭建他們的測試環境，而他們現在也不用為此煩惱了。

運維工程師曾經需要花費幾天時間的努力才能夠將應用發布到生產環境中，而如今他們只需要點擊一個按鈕就夠了，管道會自動將應用發布到生產環境中。

此外，在過去，開發者和運維工程師為了排查和修復由老式發布實踐所造成的問題常常要花費大量的精力。而CD管道能夠消除這些問題，用于修復這些問題的時間與精力可以投入到更有價值的工作中。

可靠的發布

每次發布的風險大大降低了，并且整個發布流程也變得更加可靠。

正如我們之前所說，在CD流程中，部署流程與腳本在真正部署到生產環境之前都經過了反復測試。因此，部署流程與腳本中的大多數錯誤都已經被發現了。

由于發布的頻率提高了，因此每個發布中所包含的代碼量也減少了。因此找到并且修復存在的問題也變得更加簡單，也避免了因它們造成對系統的影響而浪費的時間。

此外，CD管道能夠在某個發布失敗時自動回滾，這也進一步降低了發布失敗的風險。

工程師們對此表示，與之前相比，他們在發布日所感覺到的壓力要小得多了。對他們來說，發布日與平常的任何一天沒有區別。

改善的產品質量

產品的質量也得到了極大的改善，整個應用中未關閉bug的數量減少了90%以上。

在CD流程中，代碼一旦提交之后，整個代碼庫會經歷一系列的測試。如果在測試中發現任何問題，開發者就會在進行下一項任務前修復這個問題。這種方 式就消除了許多可能出現的bug，在老式的發布實踐中，這些bug都會被記錄在bug跟蹤系統中。之前，bug追蹤系統中記錄了大量的bug，整個工作的 大約30%的時間都在進行bug的修復。而現如今，基本沒有人需要去修復由客戶所發現的bug了，并且由于bug變得非常罕見，團隊也不需要使用任何 bug追蹤系統了。

如果確實出現了在生產環境中找到bug這種罕見的情況，這個bug就會添加到團隊的看板板上，并且在幾天之內就能夠修復并發布。而在之前，客戶必須等到下一次的大型發布才能夠將這個bug修復，這段時間通常達到幾個月。

此外，在生產環境中出現一級故障的可能性也大大降低了。除了我們所陳述的原因之外，CD管道也消除了由于手工配置和易出錯的實踐而造成的錯誤。

更高的客戶滿意度

在使用CD流程之前，由于質量和發布方面的問題，用戶部門與軟件開發團隊之間充斥著不信任感和緊張感。經理們表示，兩者之間的關系如今已經得到了巨大的改進，并且開始建立起了信任關系。

挑戰

受到這些益處的鼓舞，公司加大了在CD上的投入，我們開始在整個公司內推行CD的實施，CD平臺的改進也成為了最高優先度的工作。然而，CD的實施也面臨著相當大的挑戰。

組織結構上的挑戰

最大的挑戰來自于組織結構。發布活動牽涉到公司內的多個部門，每個部門都有自身的利益、自己的工作方式，以及所控制的勢力范圍。由于各部門之間的 目標是相互競爭的關系，因此他們之間總是存在著緊張感。比方說，我們需要訪問服務器的root，而其它團隊控制著這種權限。要達到一種解決方案，需要大量 的磋商與談判，往往時間會超過6個月。

為了應對這種組織結構方面的挑戰，領導團隊重新調整了組織結構，以打破團隊之間的壁壘，并促進了協作式的文化，情況從此得到了改善。

雖然關于對組織結構進行轉變的文章很多 ⁴ ，但很少、甚至沒有什么文章是專注于介紹如何在組織中引進CD的。對于這個主題的進一步研究，例如更深入地理解這些挑戰，以及開發出能夠更高效地處理這些挑戰的策略和實踐，能夠極大地幫助某個組織平穩地過渡到CD流程。

流程上的挑戰

許多傳統的流程會阻礙CD的發展。比方說，某個已準備好進行發布的特性通常必須經過某個變更顧問委員會的批準通過，這會使它的發布時間最多延遲4天。如果某個特性從概念到準備發布只需要幾天時間就能夠完成，那么這4天時間對于這一特性的整個周期來說是個非常漫長的期限。

為了指出這些傳統流程（包含 ⁵ 業務部門、軟件開發部門以及運維部門等等）需要進行更多的探索，以開發出并驗證能夠適用于CD的其它替代流程。

技術上的挑戰

目前還不存在一種健壯的、能夠直接使用、并且具備高度自定義能力的CD解決方案。因此我們自行開發了一套方案，這個過程的成本很高。如果有工具能夠填補這一鴻溝，它將為公司節省大量資源。

在我們創建這個CD平臺時，我們使用了許多不同的工具與技術作為我們的構建塊。避免對提供商的依賴是一個很大的挑戰。如果能夠在得到廣泛接受的標準上開展工作、依賴于開放的API，并創建一種靈活的插件生態系統將有助于減輕這種挑戰。

處理那些無法適應CD流程的應用程序（例如大型的、整體性的應用程序）同樣也具有很大的挑戰性。在整個行業中存在著大量的這種應用。為了理解它們的特性，并找出以及開發出能夠處理這些挑戰的最佳策略或實踐，需要進行進一步的研究工作。

我們樂于通過與研究者和公司近距離的協作以解決前文所述的這些挑戰，讓更多的組織能夠簡單地從CD中受益。

請參考邊欄中的內容以快速了解關于CD這方面所做的其它研究。

致謝

我對我的同事Klaas-Jan Stol致以深深的謝意，他是本文的審校者。同樣也感謝本文的編輯，他們提供了很大的幫助，以及富有見解的留言。本文只代表了我個人的觀點，并不代表我的雇主的任何意見。

參考

1. J. Humble and D. Farley，《持續交付：發布可靠軟件的系統方法》（Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation）, Addison-Wesley Professional, 2010.
2. C. Kaner, J. Falk, and H.Q. Nguyen, 《計算機軟件測試（第二版）》（Testing Computer Software, 2nd ed.）, John Wiley & Sons, 1999.
3. D.J. Anderson, 《看法方法：科技企業漸進變革成功之道》（Kanban: Successful Evolutionary Change for Your Technology Business）, Blue Hole Press, 2010.
4. R. Todnem By, “《組織變革管理的評論》”“Organisational Change Management: A Critical Review,” J. Change Management, vol. 5, no. 4, 2005, pp. 369–380.
5. Rob, Effective IT Service Management: To ITIL and Beyond!, Springer, 2007.

關于作者

Lianping Chen 是一位就職于Paddy Power的高級軟件工程師，同時也是Lero —— 利默里克大學的愛爾蘭軟件工程研究中心的一位兼職博士研究員。他的研究興趣包括軟件需求與架構、持續交付、DevOps以及軟件產品線。Chen獲得了西 北工業大學軟件工程學科的碩士學位。可以通過lchen@paddypower.com聯系他。

本文最初發表在 IEEE 軟件 雜志上， IEEE 軟件 雜志致力于發表嚴謹的、經過互相審校的文章，專注于當今世界的戰略科技。 為了滿足運行可靠且靈活企業所面臨的挑戰， IT 經理和技術管理者依賴 IT Pro 獲取最先進的解決方案 。

查看英文原文： Continuous Delivery: Huge Benefits, but Challenges Too