導入持續整合(CI)後,方案與專案架構方式

導入持續整合(CI)後,方案與專案架構方式

Select Repository source

開始導入VSTS的Build功能來進行持續整合(CI)之後,一直有個疑惑困著我,那就是方案(.sln)與專案(.csproj and .vbproj)的組織方式,如上圖,CI服務在進行建置、測試、程式碼分析、Deploy等工作時都是以Git Repository為單位,而我們開發的專案通常一個方案含有多組專案的架構方式,而我在乎的點在於,個方案,內含二個(以上)的 API 或 Web 專案時,CI Server 如何針對某一 API 或 Web 專案進行自動化怖署?

方案的規劃

在向小風請教時,我找到一篇MSDN文件在討論方案(.sln)架構,原來方案的規劃也是有好幾種。

Single Solution

合適小型系統,一個方案包含所有專案項目,好處是,當你打開方案時,所有的程式碼就在那裡等你,並且它很容易設置參考,因為它們都是你的方案之內。當然,還是有可以引用第三方組件。示意圖如下:

Single Solution file
From MSDN

Partitioned Solution

合適大型系統,每一個方案代表一個子系統應用程式。這些子系統可以在無需所有程式碼環境執行。也可以建立一個包含所有方案的主方案,利用它來建置整個應用程式。

Partitioned Solution
From MSDN

Multiple Solutions

如果你需要在一個非常大的方案,可能會碰到方案之間可伸縮性(scalability limits)問題,那麼拆分多個方案。比較麻煩的是,方案之間的參考,另外,可能需要非常複雜的建置腳本。

Multiple Solutions
From MSDN

小風小結

CI的方案-專案架構,向小風討教之後,大致偏向MSDN文件Single Solution與Multiple Solutions兩種。Single Solution的處理麻煩一些些,那就是為此方案內的專案去產生各自的.sln方案檔,那麼VSTS的Build Service在選擇步驟時,就能指定特定的.sln檔案為目標來進行作業。Multiple Solutions的話,那麼切分不同的 git repository 來進行管理(或以專案來區分),這樣的能化分系統邊界,其他共用部分,透過架設私有NuGet Server也能很容易解決。

Single Solution與Multiple Solutions兩者各有優缺點。各位如何選擇呢?

參考資料:

沒有留言:

張貼留言

感謝您的留言,如果我的文章你喜歡或對你有幫助,按個「讚」或「+1」,我會很高興的。

无觅相关文章插件,迅速提升网站流量