Team Foundation Server 2013的非確定性構建服務器行爲

由於我們的團隊不斷增長構建服務器的需求，直到最終成爲我們解決的項目。Team Foundation Server 2013的非確定性構建服務器行爲

我們有一個主控項目，它在提交到開發分支後排隊進行自動部署。問題是，構建服務器可以排隊相同的構建，相同的修訂，並得到非常不同的結果。有時候我們會得到一個乾淨的版本，按預期部署到我們的測試服務器。在其他時候，我們可以排隊構建並獲得「無法複製文件C：\ Builds \ 7424 \ Project Name \ Container Build \ bin \ somerandomreference。訪問路徑C：\ Builds \ 7424 \ Project Name \ Container Build \ bin \ somerandomreference被拒絕「。

或者我們得到：無法複製文件「Scripts \ somerandom.js」，因爲找不到它。

或者我們得到「無法複製... EntityFrameWork.XML」，因爲它正在被另一個進程使用。

這些讓我相信問題在於我們的構建重疊，所以我們已經設置了隊列來添加額外的提交，直到先前的構建完成。

唯一的防病毒軟件是運行構建服務器的Windows 8.1計算機上的默認Microsoft Windows Defender。最初我們排除了構建文件夾，現在我們把它完全關閉。

沒有人使用這臺機器，它專用於構建服務器角色，並且不運行其他軟件，只包含我們構建過程的需求安裝。

我是否缺少構建服務器的最佳實踐？我是否樂觀地期望構建服務器應該以可重現的方式構建相同的分支和版本源（即使它是可重現的失敗）？

更新：刪除整個生成文件夾，並設置備份之後，我們得到這個（溶液編譯零次失誤，但沒有測試結果或輸出）：

Exception Message: Error HRESULT E_FAIL has been returned from a call to a COM component. (type COMException) 
Exception Stack Trace: at Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.DataStoreNative.BeginDataStoreInit(IntPtr handle, String defaultCachePath, String instanceId, Int32 cacheVersion) 
    at Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.Datastore.BeginDataStoreInit(String defaultCachePath, String instanceId, Int32 cacheVersion) 
    at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.InitializeInternal() 
    at Microsoft.TeamFoundation.Client.TfsTeamProjectCollection.InitializeTeamFoundationObject(String fullName, Object instance) 
    at Microsoft.TeamFoundation.Client.TfsConnection.CreateServiceInstance(Assembly assembly, String fullName) 
    at Microsoft.TeamFoundation.Client.TfsConnection.GetService(Type serviceType) 
    at Microsoft.TeamFoundation.Client.TfsConnection.GetServiceT 
    at System.Activities.Runtime.ActivityExecutor.ExecuteInResolutionContextT 
    at System.Activities.InArgument`1.TryPopulateValue(LocationEnvironment targetEnvironment, ActivityInstance activityInstance, ActivityExecutor executor) 
    at System.Activities.ActivityInstance.InternalTryPopulateArgumentValueOrScheduleExpression(RuntimeArgument argument, Int32 nextArgumentIndex, ActivityExecutor executor, IDictionary`2 argumentValueOverrides, Location resultLocation, Boolean isDynamicUpdate) 
    at System.Activities.ActivityInstance.ResolveArguments(ActivityExecutor executor, IDictionary`2 argumentValueOverrides, Location resultLocation, Int32 startIndex) 
    at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

UPDATE2：過程似乎是仍然有問題，但不太常見。下面是今天早上非致命錯誤的例子：

C：\ WINDOWS \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets （3540）：無法複製「 C：\ Builds \ 7419 \ Policy Tracker \ Container Build \ src \ Stage \ packages \ Microsoft.Owin.Security.Cookies.3.0.1 \ lib \ net45 \ Microsoft.Owin.Security.Cookies.dll「」C： \ Builds \ 7419 \ Policy Tracker \ Container Build \ bin \ Microsoft.Owin.Security.Cookies.dll「。從 1000ms開始重試1。該進程無法訪問文件'C：\ Builds \ 7419 \ Policy Tracker \ Container Build \ bin \ Microsoft.Owin.Security.Cookies.dll' 因爲它正在被另一個進程使用。

我目前正在投資http://blogs.msdn.com/b/visualstudio/archive/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx作爲問題的可能來源（錯誤的解決方案排序）。這適用於以前的版本，但症狀看起來非常相似。

來源

2015-06-29 Godeke

您是否修改了構建過程模板？這聽起來像你已經做了一些修改，造成構建過程中的問題，而不是模板中固有的問題。 –

沒有任何構建腳本已被更改。奇怪的是，這個錯誤發生了幾次，然後也消失了（除了時間之外，我沒有任何干預）。 – Godeke

您的項目文件中是否有前/後編譯操作？ –

我已通過生成服務器中的設置解決了此問題：選項卡上的MSBuild Multi-Proc。我有這個設置爲True（默認），並得到了問題中提到的隨機錯誤。將其轉換爲False已允許幾天的代碼檢查，以便與該產品預期的工作完全相同地進行構建，測試和部署。

我的研究指向MSBuild和Visual Studio掃描項目中依賴項的方法之間的區別，但我還沒有找到解決解決方案文件中這些差異的方法，並試圖儘可能簡化。切換到單一流程構建已將構建時間從3分鐘增加到6分鐘，但是我發現在面對非確定性和確定性結果之間進行選擇時可以接受的損失。

來源

2015-07-02 15:46:00 Godeke

Team Foundation Server 2013的非確定性構建服務器行爲

回答

相關問題