導入持續整合(CI)後，方案與專案架構方式
開始導入VSTS的Build功能來進行持續整合(CI)之後，一直有個疑惑困著我，那就是方案(.sln)與專案(.csproj and .vbproj)的組織方式，如上圖，CI服務在進行建置、測試、程式碼分析、Deploy等工作時都是以Git Repository為單位，而我們開發的專案通常一個方案含有多組專案的架構方式，而我在乎的點在於，個方案，內含二個(以上)的 API 或 Web 專案時，CI Server 如何針對某一 API 或 Web 專案進行自動化怖署？
方案的規劃
在向小風請教時，我找到一篇MSDN文件在討論方案(.sln)架構，原來方案的規劃也是有好幾種。
Single Solution
合適小型系統，一個方案包含所有專案項目，好處是，當你打開方案時，所有的程式碼就在那裡等你，並且它很容易設置參考，因為它們都是你的方案之內。當然，還是有可以引用第三方組件。示意圖如下：
From MSDN
Partitioned Solution
合適大型系統，每一個方案代表一個子系統應用程式。這些子系統可以在無需所有程式碼環境執行。也可以建立一個包含所有方案的主方案，利用它來建置整個應用程式。
From MSDN
Multiple Solutions
如果你需要在一個非常大的方案，可能會碰到方案之間可伸縮性(scalability limits)問題，那麼拆分多個方案。比較麻煩的是，方案之間的參考，另外，可能需要非常複雜的建置腳本。
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兩者各有優缺點。各位如何選擇呢？
沒有留言:
張貼留言
感謝您的留言，如果我的文章你喜歡或對你有幫助，按個「讚」或「分享」它，我會很高興的。