前期我們提到，在研發程序中，可能由于迭代變化或需求調整等等原因會導致團隊欠很多技術債，從而導致隨著專案的運行，技術債務越積越多，導致給用戶交付越來越慢，交付的軟體質量越來越差，最終不可控，拖延整體交付進度，系統不可控等很多問題，

在實際研發作業程序中，我們基于一些工程學的方法，借助一些工具與方法，結合科學的流程，能夠對降低技術負債起到一定的作用，

最近筆者學習和閱讀了一些技術類書籍，其中領導推薦的一本《持續交付發布可靠軟體的系統方法》書籍中所提到的理念和實踐方法，對提升發布效率、減少技術債等就有一定的幫助，可供軟體研發實踐參考，

下面就結合筆者的一些實踐，以及該書的一些理念，僅僅從持續交付中一些小的點來做一些分享，在實踐中可以作為一些參考，可以幫助改善作業質量，減少一些技術債務，提高持續交付的質量和效能，

提到持續交付，我們都知道，它是一種軟體工程手法，其目的讓軟體產品的產出程序在一個短周期內完成，以保證軟體可以穩定、持續的保持在隨時可以發布的狀況，軟體研發程序中，我們不僅僅要保證軟體產品當前可用，而且希望保證它持續長時間可用，甚至隨時隨地有了需求的變更后，都能夠快速實作、快速完成、快速部署和交付，尤其是當軟體面臨客戶的緊急需求變更時候的交付訴求，這種能夠快速交付的能力就顯得尤為重要，

持續交付的目標在于讓軟體的構建、測驗與發布變得更快以及更頻繁，通過這種方式來減少軟體開發的成本與時間，減少風險，持續交付往往與持續部署混淆，持續部署意味著所有的變更都會被自動部署到生產環境中，持續交付意味著所有的變更都可以被部署到生產環境中，但是出于業務考慮，可以選擇不部署，如果要實施持續部署，必須先實施持續交付，持續交付往往伴隨著持續部署，與自動化測驗及自動化部署配合開展，幾項作業之間相互協調，相輔相成，

二、關于持續交付

關于持續交付，我們接下來嘗試分享和回答下面幾個問題：

1)持續交付是在解決什么問題，為什么要做持續交付，它能帶來什么？

2)持續交付怎么做？持續交付什么時候做？

首先，看第一個問題，持續交付在解決什么問題，關于交付，從在不同的角度對交付進行解讀會有不同含義，面對用戶的交付，面的客戶的交付，面對甲方乙方，做一款產品的交付，做一個專案的交付，其交付方式，交付質量，交付物可能都是有一定差別的，我們這里縮小范圍，僅描述研發團隊對用戶的軟體交付，討論持續交付如何實踐，

對于產品研發團隊來說，產品的版本的更新迭代和交付，最終經過集成測驗、系統測驗等測驗后的軟體版本通過部署交付到用戶環境，最終除錯跑起來，達到可提供給客戶服務和使用的狀態即理解為軟體交付，

在交付之前，我們需要進行多輪回歸驗證，經過單元測驗、配置項測驗、集成測驗、系統驗收測驗，兼容性測驗，發現軟體缺陷之后，Bug修復之后的回歸測驗，而我們希望每一輪的回歸測驗能夠盡可能快，Bug修復能夠不帶來新的問題，開發人員在引入任何回歸錯誤時（包括缺陷、性能問題、安全問題、可用性問題等），都能快速得到反饋，只有快速發現問題，快速修復問題，快速反饋問題修復結果，才能讓整個環節加速，一旦發現軟體中的問題，就立即加以解決，從而保持代碼的主干master隨時都始終處于可部署狀態，這樣就實作了一定意義上的快速實作，再加上這個程序中，代碼compile、代碼build，都是以工具方式，通過代碼驅動，那就初步實作了持續集成，

我們希望通過持續集成，結合持續交付的作用，將集成后的代碼部署到類生產環境，確保可以以可持續的方式快速向客戶發布新的更改，如果代碼沒有問題，可以繼續手動部署到生產環境中，

對于專案實施團隊來說，持續交付是要將客戶要求實作的功能部署到客戶的生產環境，通過驗收即為交付，對于最終用戶來說，持續交付是最終用戶可以使用相關的功能即為交付，持續交付是指持續的將各類變更（包括新功能、缺陷修復、配置變化、實驗等）安全、快速、高質量地落實到生產環境或用戶手中的能力，持續交付的能力通過自動化流水線的方式實作，減少研發程序中不必要的浪費，近而縮短整個研發程序中所有需求的交付周期，持續交付是一個整體程序，從一個業務端的想法到系統功能可以面對客戶的全流程，簡單來講就是，持續交付能夠幫助提高交付效率，節約成本，

其次，持續交付怎么做？建議在專案初期，專案立項時候，就開始著手準備，根據專案的形態，是分布式，還是單體應用，是單獨的資訊管理系統，還是需要多端互動的系統，基于公有云、還是私有化部署等等，結合專案的實際分析，具體選擇是直接寫腳本，還是通過工具完成，持續交付開展越早越好，越是前期，模塊越小，集成時候出錯概率越小，遇到問題也容易解決，越是大規模多模塊的復雜系統，軟體問題的處理難度越大，耗費的時間也越多，

盡早開展持續集成，盡早讓測驗介入，這條原則，在軟體工程實踐中，強調多次都不為過，持續交付適合建立了發布流水線，有單元測驗與自動化測驗的團隊做，要想持續交付，通過這些腳本去測驗業務代碼，能夠實作對結果的快速反饋，而前幾年流行的TDD模式，就是在通過強調寫業務代碼之前，需要先寫好單元測驗測驗代碼，并將單元測驗代碼集成，通過測驗代碼驗證業務代碼的方式提高業務系統軟體質量，在這樣的作業模式下，通過測驗代碼驅動開發業務代碼，我們對于覆寫率提出一定數量方面的要求也很有幫助，

三、持續交付的發法和原則

在實際開展持續交付程序中，也可以根據實際情況進行，有些界面設計之類可能根據用戶喜好不同，風格變化可能比較頻繁，此類作業不可少，但是又不影響代碼構建，對于此類，我們可以另辟分支開展，針對業務代碼，可以考慮參考這幾個原則開展：

◆堅持精簡原則，選擇適合自己業務的來實作，盡可能拆分模塊，細化小模塊做持續交付，

◆持續盡早開展，并分解問題，不斷試錯糾錯，在不斷的支持分解和解決問題中持續優化交付流程，

◆堅持快速反饋，不是一味的埋頭苦干，提早確認和反饋風險，在快速反饋中，盡早完成和解決問題，

◆持續改進并衡量，改進和衡量方式同樣重要，

前期做好規劃，盡早開展，在實際開展程序中，不斷分析優化，持續解決問題，隨后進行問題回歸與驗證，作為下次優化的起點，采取PDCA作業模式，不斷執行-檢查-分析-調整，持續迭代，而這種小規模，小版本迭代，小步快跑的方式，有助于提升持續交付成功率，

我們建議頻繁提交，小代碼塊提交，盡量避免很長時間不提交，卻一次性提交大量代碼，這種方式，一旦提交后構建失敗，導致對問題的分析定位也是耗時巨大，少量代碼頻繁提交，每個模塊只做每個模塊的事情，于軟體設計模式清晰，也對代碼構建有好處，提交后即使出錯，也好排查，易于快速迭代，實作快速編譯、快速構建、有助于快速交付，

四、持續交付的實踐

在軟體團隊，我們知道以前有一個角色叫做SCM，軟體配置管理工程師，他專門會負責代碼的構建、集成，以及配置項、代碼基線與版本等的管理，但近年來，隨著DevOps的流行，加上敏捷的口號，該職位只在一些大中公司中存在，但SCM的關鍵性毋庸置疑，軟體的集成，軟體的配置項，代碼管理等環節，是軟體能夠從零散的代碼得以組裝，成為可執行可運行的軟體的必要環節，于交付而言不可或缺，

SCM工程師在軟體配置管理程序中的這些活動：配置標識、配置控制、配置狀態發布、配置的評審，現在逐步融入在持續集成環節，配置管理是軟體生命周期里，對定義各類配置項，建立各類基線、描述相關軟體配置項及其檔案的程序很重要，在持續交付程序中，把一些之前需要手動操作的，通過腳本或工具連起來，用代碼去自動化的實作，有助于落地持續交付，逐漸借助一些工具，在實踐中能夠幫助我們實作持續交付，比如以前就有cruise control、hudson、Jenkins、 TeamCity、等一些出名的CICD工具，隨后出現了Travis CI、Gitlab CI等；但是Jenkins由于其免費，跨平臺，支持docker化安裝，支持上千個插件的擴展版本，可以集成幾乎所有市場上可用的工具和服務，現在依然收到很廣泛的使用，Jenkins支持插件化安裝并擴展為最大的開源CI工具之一，可幫助工程團隊自動化部署，在實際的開展程序中，可以參考相關幫助檔案進行，關于jenkins的實踐與應用使用，網上資料很多，這里暫不展開詳細描述具體工具的使用細節，

五、寫到最后

持續交付并非一蹴而就，我們可以借助一些工具結合實際業務快速實作，結合持續集成、持續交付、持續部署幾個活動相輔相成，經過在專案中的磨合實踐、除錯、優化，并最終形成適合團隊的持續交付作業流程，在實際中，可能專案不同，業務不同，也需要適當調整，可以根據實際業務的規模，以及專案周期的長短，選擇適當的工具，能夠最快速的用于解決專案實際問題，助力快速交付，才是最好的，

標籤：其他

上一篇：通過持續交付提升發布效率

下一篇：高并發環境下構建快取服務，你需要注意這6點