持續交付與持續部署微服務

持續集成(Continuous Integration）與持續交付(Continuous Delivery )、持續部署（ContinuousDeployment）作為敏捷開發實踐，可以及早發現、解決問題，從而更早地將產品交付給客戶。及早地從客戶那里得到反饋，就可以及早地對產品進行修復和完善，交付更加完美的產品給客戶，最終形成了良好的可以持續的閉環。

什么是持續交付與持續部署

持續集成是持續交付和持續部署的基礎。持續集成使得整個開發團隊保持一致，消除了集成所引起的問題的延期。雖然持續集成使得代碼可以快速合并到主干中，但此時軟件仍然是未在生成環境中進行實際使用過的。軟件的功能是否正常，功能是否符合用戶的需求，這在持續集成階段仍然是未知的。只有將軟件部署到了生成環境，交付給用戶使用之后，才能檢驗出軟件真正的價值。而持續交付與持續部署的實踐，正是從持續集成到“最后一公里”的保障。

所謂交付，就是將最終的產品發布到線上環境，提供給用戶使用。對于一個微服務架構系統來說，將一個應用拆分成多個獨立的服務，每個服務都具有業務屬性，并且能獨立地被開發、測試、構建、部署。換言之，每個服務都是一個可交付的產品。那么在這種細粒度的情況下，如何有效保障每個服務的交付效率，快速實現其業務價值，是擺在微服務面前的一個難題。

而持續交付是一系列的開發實踐方法，用來確保代碼能夠快速、安全地部署到產品環境中，它通過將每一次改動都提交到一個模擬產品環境中，使用嚴格的自動化測試，確保業務應用和服務能符合預期。因為使用完全的自動化過程來把每個變更自動提交到測試環境中，所以當業務開發完成時，你有信心只需要按一次按鈕，就能將應用安全地部署到生產環境中。

而持續部署是持續交付的更高一級的階段。即當所有代碼所有的改動都通過了自動化測試之后，都能夠自動地部署到生產環境里。持續發布與持續部署一個重要的差別在于，持續發布需要人工來將應用部署到生成環境中（即部署前，應用需要人工來校驗一遍），而持續部署則是所有的流程都是自動化的，包括部署到生產環境的流程。圖11-1很好地描述了持續發布與持續部署之間的差異。

讓我們來探討下一個完整軟件的交付過程。假設現在需求已經明確，并且已經被劃分為小的單元模塊，如劃分成用戶故事，讓我們觀察下從開發人員拿到用戶故事，到這些用戶故事被實際部署到生產環境上的這個過程。對于這個過程來說，實際上時間越短越好，特別是對于那些急需獲得用戶反饋的敏捷開發方式的軟件產品。如果我們做的每一個用戶故事，甚至是每一次代碼的提交，都能夠被自動地部署到生產環境中去，那么這種頻繁近乎持續的部署，對于很多敏捷軟件開發團隊來說，就成了非常值得追求的目標了。

當然實施持續部署并非沒有投入和成本，如果產品的基礎和特點不同，那么獲得這種狀態所需要的投入就越大。對于那些缺乏自動化測試覆蓋的遺留系統，以及對安全性要求特別高的產品，它們要實現持續部署，甚至是頻繁部署，都需要巨大的投入。但是如果產品所處的市場環境要求它必須能夠及時做出相應的變化，不斷改進軟件服務的話，那么這種持續部署的能力就成了值得投入的目標。

持續部署，依賴于整個團隊對所寫代碼的自信。這種自信，不僅是開發人員對自己寫的代碼的自信，更多的是團隊或組織所有成員都抱有的基于客觀事實的自信。只有建立起這種自信，才能夠讓任何新的修改都能夠迅速地、有信心地部署到生產環境中。

在自信的基礎上，團隊要實現產品的持續部署，還需要建立自動化交付流水線（Pipeline)。

以自動化生產線進行對比，自動化測試只是其中一道質量保證的工序，而要將產品從需求轉變為最終交付給客戶的產品，自動化生產線是整個開發過程中極其重要的存在。特別是對于微服務這種多服務的產品而言，多個服務產品往往要集成在一起，才能為客戶提供完整的服務。多個產品的自動化交付流水線的設計也就成了一個很重要的問題。

產品在從需求到部署的過程中，會經歷若干種不同的環境，如QA環境、各種自動化測試運行環境、生產環境等。這些環境的搭建、配置、管理，產品在不同環境中的具體部署，都需要完善的工具支持。缺乏這些工具，生產流水線就不可能做到完全自動化和高效。與之配套的軟件有Team-City、Jenkins、GoCD等。

持續交付與持續部署的意義

總的來說，持續交付與持續部署在敏捷開發過程中，實現速度、效率、質量的軟件開發實踐，可以持續為用戶交付可用的軟件產品。其中包括:

頻繁的交付周期帶來了更迅速的對軟件的反饋。
可以迅速對產品進行改進，更好地適應用戶的需求和市場的變化。

需求分析、產品的用戶體驗和交互設計、開發、測試、運維等角色密切協作，相比于傳統的瀑布式軟件團隊，減少了浪費。

有力形成了“需求→開發→集成→測試→部署”的可持續的反饋閉環。

什么是持續交付流水線

在持續交付中，持續集成服務器將把開發到部署過程中的各個環節銜接起來，組成一個自動化的持續交付流水線，作為整個交付過程的協調中樞。依靠持續集成服務器，對軟件的修改能夠快速地、自動化地經過測試和驗證，最后部署到生產環境中去。在自動化測試和環境都具備的情況下，集成服務器可以減少開發人員大部分的手工工作。流水線應向團隊提供反饋，對每個人所參與的錯誤操作進行提示。

典型的持續交付流水線中，大致會經歷構建自動化和持續集成、測試自動化和部署自動化等階段。

1.自動化構建和持續集成

開發人員將實現的新功能集成到中央代碼庫中，并以此為基礎進行持續的構建和單元測試。這是最直接的反饋循環，持續交付流水線會通知開發團隊他們的應用程序代碼的健康情況。

2.自動化測試

在這個階段，新版本的應用程序將經過嚴格測試，以確保它滿足所有期望的系統質量。這包括軟件的所有相關方面，包括功能、安全性、性能等，這些都會由流水線來進行驗證。該階段可以涉及不同類型的自動或手動活動。

3.自動化部署

每次將應用程序安裝在測試環境前都需要重新部署，但自動化部署最為關鍵的是自動化部署的時機。由于前面的階段已經驗證了系統的整體質量，這是一個低風險的步驟。部署可以分階段進行，新版本最初可以先發布到生產環境的子集中，并在進行完整測試之后，推廣到所有生產環境中。這極大降低了新版本發布的風險。部署是自動的，這樣只需要花費幾分鐘就能向用戶提供可靠的新功能。

持續交付流水線的最佳實踐

下面總結了在構建持續交付流水線時一些好的實踐經驗。

1.做好配置管理

持續交付流水線需要有平臺配置和系統配置的支持，這樣就能允許團隊自動或手動按下按鈕來創建、維護和拆除一個完整的環境。

自動平臺配置可確保您的候選應用程序能夠部署到正確配置的且可重現的環境中去，然后進行測試。它還促進了橫向擴展性，并允許企業在沙箱環境中隨時嘗試新產品。

2.合理編排流水線

持續交付流水線中的多個階段涉及不同的人員團隊協作，并且所有人員都需要監測新版本的應用程序的發布。持續交付流水線的編排提供了整個流水線的頂層視圖，允許您自行定義和控制每個階段的具體動作，這樣就能細化整個軟件交付過程。

3.不要添加新的功能，直到通過質量測試

持續交付使您的組織能夠一個接一個地快速可靠地將新功能帶入生產環境中。這意味著每個單獨的功能需要在展開之前進行測試，確保該功能滿足整個系統的質量要求。

在傳統開發環境中，開發團隊通常試圖一次性實現一個完整的新版本，僅在項目接近完成時來解決軟件質量屬性（如魯棒性、可擴展性、可維護性等）。然而，隨著最終工期的臨近，以及迫于

預算的壓力，質量往往會首先被舍棄。

可以通過在獲得質量權之前不添加新功能的原則來避免不良的系統質量。在實踐中，您應該始

終首先滿足并保持質量水平，然后才考慮逐步向系統添加功能。使用持續交付，每個新功能都需要

從一開始就滿足整個系統所期望的質量水平。只有在達到此質量水平后，才能將該功能移至生產

環境。

配置管理

1.什么是配置管理

配置管理是指一個過程，通過該過程，將所有與項目相關的產物，以及它們之間的關系都被唯一定義、修改、存儲和檢索。這里的項目相關的產物可以是源代碼、需求文檔、設計文檔、測試文檔等，也包括了項目配置、庫文件、發布包、編譯工具等。

配置管理是軟件開發過程中極其重要的一部分，持續集成、部署流水線、自動化測試等若想真正發揮好作用，都必須做好配置管理工作。

2.如何進行配置管理

《持續交付》一書對配置管理做了重要的論述，并通過版本控制、依賴管理、軟件配置管理和環境管理四部分來分別分析了配置管理的重要性。以下是所總結的配置管理的實踐經驗。

版本控制:在版本控制方面，我們提倡將所有東西都提交到版本控制庫中，包括操作系統的配置信息。使用版本控制庫的好處是顯而易見，你可以放心地變更或刪除任何文件，版本控制庫可以幫你來回溯歷史。常用的版本控制庫有很多，包括Bazaar、Mercurial、Git、SVN等。這里的建議是，除非是歷史原因導致變更版本控制庫軟件比較困難，否則，采用Git等分布式版本控制庫軟件可以極大提高團隊協作的效率。對于提交變更而言，一個好的實踐是頻繁提交變更到主干，因為當你匯聚的更改越多，變更間隔的時間越長，合并到主干時發現的問題就會越多。頻繁提交代碼，就是一個頻繁集成代碼的過程。
依賴管理:對于一個頗具規模的軟件而言，很難不依賴第三方的軟件或第三方的庫文件的實現。當項目中依賴變多時，依賴關系將變得錯綜復雜，特別是某些軟件存在兼容性方面的問題，各個版本之間的接口還不能通用，這樣，通過手工等方式進行依賴的管理將變得極其困難。在實際開發中，我們傾向于使用依賴管理工具來幫助解決這些依賴管理，對于JAVA開發者而言，Maven或 Gradle是個不錯的選擇。建議在本地保存一份外部庫的副本，這樣可以加快開發的啟動速度。另外，將依賴庫的版本在團隊中進行統一，可以有效防止不同版本之間出現的奇怪問題。
軟件配置管理:幾乎所有的軟件都有配置文件，這使得軟件可以在不做修改的前提下，僅需要調整配置文件的內容，就實現軟件的差異化。不同的軟件部署到不同的生產環境中，其所使用的配置文件也是不同的。將軟件配置進行統一管理，這樣在軟件升級時，仍然能夠恢復用戶最初的軟件設置。一個好的事件是把配置信息當成源代碼看待，并對它進行測試。
環境配置管理:沒有哪個應用程序是孤島。每個應用程序都依賴于硬件、軟件、基本設施及外部系統才能正常工作。所以在提倡自動化方式管理環境時，還需要考慮環境配置信息，例如:

*應用程序所采用的各種操作系統或中間件，包括其版本、補丁級別及配置設置;

*應用程序所依賴的需要安裝到環境中的軟件包，以及這些軟件包的具體版本和配置;

*應用程序正常工作所必需的網絡拓撲結構;

*應用程序所依賴的所有外部服務，以及這些服務的版本和配置信息。

本書后續章節，也會探討微服務的集中化配置的問題。

持續交付與DevOps

對于交付成功的軟件來說，開發和運維是兩個必不可少的過程。在傳統的組織架構中，開發團隊和運維團隊往往是分屬于不同的部門，各自部門的職責可能會引人相互抵觸的目標:對于開發人員來說，開發人員的職責是負責交付新特性及對變更承擔責任;而運維人員則試圖保持所有功能能夠平穩運行，對他們來說，避免變更正是降低運行風險的一種最有力的手段。在這種互相沖突的目標面前，最終導致產品不能得到很好的更新，也就無法持續給用戶創造價值。

DevOps 正是為了打破開發團隊與運維團隊之間的壁壘而進行的一次嘗試。DevOps是Develop-ment與Operations的縮寫，DevOps推動了一套用于思考溝通和協作的過程和方法，用于促進開發、技術運營和質保部門之間的溝通、協作與整合,其推崇的團隊將會是一個結合開發、質量保證( QA)、IT運營等整個職責的跨職能團隊，如圖11-2所示。這也正是Amazon所提倡的“You Build It，YouRun It（誰開發，誰運維）”的開發模式。