持續集成策略 - 項目參考與分支/合併

Question

假設您在遺留代碼庫（企業API）中有7個核心項目。代碼庫大約有50個引用一個或多個核心項目的應用程序。只有50個應用程序中的一部分在vss遷移之後仍然可以工作，而手動遷移是梨形的。爲了讓應用程序重新運行，很多已從企業API中取出並放入了自己的TFS項目。

我試圖說服同事，他們應該不使核心項目的一個分支，並把副本分開TFS的項目，只有釋放PROD後合併增加的核心項目回企業API。顯而易見，持續集成將會更加困難，因爲它不那麼頻繁。

我試圖說服同事們將核心項目從企業API中拿出來放在他們自己的TFS項目中，然後引用bin/Debug會更好。

對Branch來說更好，將分支複製到單獨的TFS項目然後合併（並在最後看到衝突）還是更好地封裝核心項目並強制20個團隊只使用一個副本每個核心項目的內容？

Answer 1

我敢肯定你希望讓你的團隊參考已經構​​建的核心API的二進制文件。重用的正確粒度是發佈的粒度（版本化版本），參見Robert C Martin的96年的C++報告和我們的解釋：http://www.urbancode.com/html/resources/articles/reuse-maturity-model.html

基本上，團隊看起來很恐慌，只是做最簡單的事情這可以讓他們回來並能夠交付。這條路線是可以理解的，但我認爲如果他們承認把共同的庫作爲共享代碼庫並且重用代碼而不是dll是最好的，並且技術債務要穩定的話纔是最好的。

Answer 2

這實際上取決於您的共享代碼的成熟度。我會說，你可以按照有三種方法，各有其優缺點：

選項1：直接引用他們離開自己的團隊項目

Team Project Application 1 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> Application 1 
       --> Application1.sln 

Team Project Application 2 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> Application 2 
       --> Application1.sln 

Team Project CoreProject 1 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> CoreProject1.csproj 

的使用這種方法，您可以設置您創建的CI將讓所有應用程序在您簽入CoreProject後開始構建。
你一定要有團隊項目中本地具有傳統映射（否則編譯將打破）

這是一個很好的方法，如果你不斷改變CoreProject &需要那些迅速反映到所有受影響的應用程序的變化。
這也意味着如果某個CoreProject發生了重大變化，那麼您可以在某個App上負擔不穩定性。

選項2：通過分支

Team Project Application 1 
--> Development 
     --> ... 
--> MAIN 
     --> SharedSources 
      --> CoreProject1_branch 
       --> CoreProject1.csproj 
     --> Sources 
      --> Application 1 
       ---> Application1.sln 

Team Project Application 2 
--> Development 
     --> ... 
--> MAIN 
     --> SharedSources 
      --> CoreProject1_branch 
       --> CoreProject1.csproj 
     --> Sources 
      --> Application 2 
       ---> Application1.sln 

Team Project CoreProject 1 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> CoreProject1.csproj 

用這種方法間接引用他們，每次都在CoreProject1變化檢查的時候，你需要組織合併到每個受影響的應用程序。這需要付出一定的努力，但是可以讓您有時間在自己的操場上穩定CoreProject，然後將其合併到您的應用程序中。
這種方法意味着你也有每個CoreProject的構建定義。
一般來說，如果您重視CoreProject的穩定性，那麼這是一種很好的方法，如果更改會造成麻煩，則不能「污染」您的應用程序。這是我們的做法。

方案3：請在每個應用程序

Team Project Application 1 
--> Development 
     --> ... 
--> MAIN 
     --> SharedBinaries 
      --> CoreProject1_branch 
       --> CoreProject1.dll 
     --> Sources 
      --> Application 1 
       ---> Application1.sln 

Team Project Application 2 
--> Development 
     --> ... 
--> MAIN 
     --> SharedBinaries 
      --> CoreProject1_branch 
       --> CoreProject1.dll 
     --> Sources 
      --> Application 2 
       ---> Application1.sln 

Team Project CoreProject 1 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> CoreProject1.csproj 

採用這種方法文件引用，你倒是需要在CoreApplication建立到每個應用程序的二進制輸出進行檢查。
只有在確信CoreApplication穩定的情況下才建議您這樣做，因爲您不需要定期對其進行調試。

基本上選項2 &選項3是類似的，由衆所周知的辯論「項目與文件參考」分開。有關SO資源，請參見here，可通過搜索檢索更多內容。

如果您的核心項目由於不斷變化和/或具有較低的單元測試覆蓋率，您應該選擇選項2（或3）。
如果您對自己的品質有信心，選擇1是一個不錯的選擇，因爲它會大大提高您的整體生產力。

根據您提供的相當大的數量（20人，50個解決方案，7個核心項目），您不需要任何有關您的產品和質量的知識，我可以選擇2/3。

另一個重要提示：它經常發生的事情經常是共享項目沒有任何分離測試的手段。如果是這種情況，核心項目沒有自己的單元測試，沒有專門的測試計劃等，除了選項1之外別無他法。

關於此事的另一個很好的資源是ALM護林員的work。