在上篇《研發協同平臺持續集成實踐》一文中我們分享了為什么要做持續集成，技術選型，工作原理以及實踐落地。今天我們從架構上來分享一下架構層面的設計和演進。

持續集成1.0

在最開始設計的過程中，本著一切從需求出發，一切以實現業務為原則，我們對主要的業務需求進行了梳理：

• 開發人員希望能快速交付需求

• 測試人員希望在開發人員完成開發后，能夠快速根據新的代碼集構建獨立的環境進行測試驗證

• 不同需求的交付互不影響

• 為ERP產品服務

• 一個ERP站點，一個數據庫

對上述需求進行整理和挖掘后，我們在設計上整理出以下幾點：

• 一個需求，創建一個新的分支進行開發交付，以需求為最小單元進行交付。

• 一個分支，構建一個獨立的ERP站點進行測試，這里一個ERP站點就是一個測試環境。

• 一個ERP站點，對應一個獨立的數據庫

• 需求、分支、ERP站點、數據庫是一一對應的關系

在業務上以需求為出發點，在使用上以分支為操作單元，這樣做的優點是：

• 用戶使用便捷：

• • 創建分支，綁定需求

  • 拉取分支代碼開發、自測

  • 提交分支，以分支為單元構建環境測試

• 能快速實現，進行發布驗證

在上面的設計中，以分支出發來構建站點，那么一個ERP站點包含什么，如何構建以及銷毀呢？

ERP站點組成-?一個可運行ERP站點包括站點程序集、配置和數據庫

站點程序集- 通過代碼倉庫中的分支代碼編譯產生

配置- 包括本地開發默認配置、測試環境默認配置和自定義配置。默認配置從代碼倉庫模板中來；自定義配置，按照約定放在代碼倉庫中的自定義配置目錄下，由用戶自行選擇配置目錄來確定。

數據庫- 在創建分支時，創建數據庫，從最新測試基準庫還原而來，基準庫每天會定時備份

站點構建

站點銷毀

在需求交付以后，平臺會自動銷毀需求對應的開發分支，同時也會銷毀分支對應的ERP站點。

• • 銷毀構建記錄

  • 銷毀站點容器

  • 銷毀對應的數據庫

持續集成1.x

持續集成1.0版本在上線以后，可以覆蓋核心業務場景，但是隨著應用的深入，場景也越來越多，其中兩個主要需求場景是：

• 需求測試除了ERP站點，還依賴其它服務：

• • ERP系統中的文檔上傳，瀏覽等功能依賴文檔服務

  • ERP系統中的審批相關功能依賴工作流服務

  • ERP系統和其他系統之間的集成依賴集成服務

• 1.0版本一個分支只能構建一個站點， 這一些場景下需要從一個代碼分支構建出多個站點，做不同需求的測試

上面的兩個需求中，出現了兩個比較大的變化：

• 一個完整的測試環境，不單單包含一個ERP站點，還包括其他應用服務。這打破原有的一個站點，一個環境的設計

• 一個代碼分支，可構建出多個對應的站點（多個環境），這打破原有的的一個分支一個站點的設計

這時的需求，原有的設計本質上已不能滿足，有兩個核心要素缺失：

• 原有的設計是構建一個ERP站點，但更合理的是要構建一個可供測試的環境，這個環境可以只包括一個ERP站點，也可以包括其他的應用服務

• 原有的設計師一個分支構建一個站點（一個環境），但合理的是環境應該可靈活定義。一個環境即可以從一個分支構建而來，也可以從多個分支構建而來。多個不同的環境也可以從相同的分支構建而來。

按照更加合理的設計，在構建的架構設計上是需要做比較大的改動的。但是基于當時正在做持續集成1.0的推廣，一旦進行大的改動，影響面比較大。綜合評估影響面，資源方面的因素，最終決定不對架構做重構，只在功能上實現做改進來實現需求。
進一步分析新的需求場景：

• ERP站點鎖依賴的服務，是都為ERP系統功能服務的，我們定義它們為配套服務。并且這些配套服務（文檔服務、工作流服務、集成服務）都是現有的直接可運行的服務，并不需要從代碼構建而來。所以可以直接準備好可運行的服務鏡像，啟動容器即可。不過這里有兩個需要注意的點是：

ERP的版本和服務鏡像的版本是有匹配關系的，并不能完全做到向下兼容

ERP所依賴的這些應用服務和ERP耦合都還比較緊，在這些應用服務部署完成后，還需要修改ERP的配置，這里包括文件配置和數據庫配置都要做調整

• 針對一個分支構建多個環境的需求，我們當時的策略是克隆分支，再從克隆分支上部署一個站點（環境）

• 針對上述需求，重點是要實現配套服務的持續構建。那么配套服務包含什么，如何構建和銷毀呢？

  配套服務的組成-配套服務包括服務容器鏡像和配置服務鏡像- 由相應的服務團隊提供可運行程序集，研發系統平臺團隊依此構建服務鏡像以及維護服務鏡像和ERP版本之間的關系

  配置-在ERP系統的配置文件和數據庫中，添加相應的配套服務配置信息。在配置服務中，添加ERP系統配置信息

  配套服務構建

  配套服務銷毀

  在刪除配套服務時，會銷毀配套服務：

  • • 銷毀配套服務容器

    • 刪除ERP系統中的配套服務配置信息

  持續集成2.0

  持續集成1.x版本在功能上已能很好的滿足用戶需求，但是隨著ERP2.0的發布，ERP產品提供了更加靈活的部署架構來支撐萬億級客戶。主要包括集中部署不分庫，分離部署分庫和分離部署不分庫。

  • 分離部署?- ERP的各個子系統分開部署為各個獨立的子站點

  • 集中部署?- 所有的ERP子系統部署在一起，一個ERP站點

  • 分庫?- ERP的各子系統獨立使用各自的數據庫

  • 不分庫?- ERP的子系統都使用一個數據庫

  • 集中部署不分庫：ERP（包含售樓、成本、計劃系統）部署在一起，一個站點，使用一個數據庫

  • 分離部署分庫：售樓系統部署為主站，成本系統和計劃系統部署為從站。主站使用一個數據庫，從站使用另外一個數據庫

  • 分離部署不分庫：售樓系統部署為主站，成本系統和計劃系統部署為從站。主站和從站都使用同一個數據庫

  客戶如果是分離部署，這就要求原有的ERP產品開發必須拆分成各個子系統，因為各個子系統的系統是分離的，它們的需求需要分開獨立交付。盡管在開發模式上各個子系統是獨立的，但ERP系統作為一個完整的產品，各子系統之間是需要頻繁的集成在一起測試的。并且在分庫的場景下，一個環境也不在只對應一個數據庫。

  • 分離部署?- 要求一個環境包含多個站點（服務）

  • 集中部署?- 要求一個站點（服務）可以從多個代碼分支構建

  • 分庫?- 要求一個環境可同時使用多個數據庫
    針對上述支撐ERP2.0產品持續集成新的需求，結合1.X中配套服務的實現，我們對持續集成的整體架構設計做了重構

  • 環境?- 一切以環境為核心，在持續集成中我們要構建的是可用的、針對不同用途的測試環境。環境可隨時新增、刪除，也可靈活配置。這樣，用戶可以隨時新增、配置、構建一個用戶想要的環境。

  • 服務?- 一個測試環境由一個或多個服務組成，ERP站點是一個服務，文檔服務也是一個服務，工作流還是一個服務。環境中的服務可靈活新增、配置、刪除

  • 數據庫?- 數據庫獨立創建、刪除，不再和分支綁定。在環境中靈活配置要使用的數據庫，可配置一個或多個

  • 持續集成管道?- 一種服務類型對應一個持續集成管道，ERP站點可定義自己的持續集成管道，工作流服務也可以定義自己的持續集成管道。每個持續集成管道由不同的作業組成。

  • 作業?- 不同的作業相互組合構建成一個持續集成管道。一個作業又由不同的命令組合而成

  • 命令?- 命令是持續集成過程的最小執行單元。研發協同平臺定義了一批默認的命令集。不同命令可組合成不同功能的作業。
    重構后，環境、服務、數據庫即互相獨立，又可以通過靈活的組合不同的服務和數據庫來構建不同的環境，經過2.0的重構后，平臺已經能全場景支撐用戶的持續集成需求了。

  寫在最后

  雖然當前的設計已經能很好的支撐當前的用戶持續集成需求，但是ERP2.0產品還在不斷進化，進化則帶來更多的變化，協同平臺也在持續支撐和改進，架構上也要持續的進行優化演進。

  ------ END ------
  

  作者簡介

  陸同學：?架構師，負責研發協同平臺產品的架構規劃與設計工作。

  也許您還想看

  研發協同平臺持續集成實踐
  

  如何解決大批量數據保存的性能問題

  【復雜系統遷移 .NET Core平臺系列】之界面層
  

  【復雜系統遷移 .NET Core平臺系列】之遷移項目工程
  

總結

以上是生活随笔為你收集整理的研发协同平台持续集成2.0架构演进的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。