Team Foundation Server 2013的非确定性构建服务器行为

Question

由于我们的团队不断增长构建服务器的需求，直到最终成为我们解决的项目。

我们有一个主控项目，它在提交到开发分支后排队进行自动部署。问题是，构建服务器可以排队相同的构建，相同的修订，并得到非常不同的结果。有时候我们会得到一个干净的版本，按预期部署到我们的测试服务器。在其他时候，我们可以排队构建并获得“无法复制文件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作为问题的可能来源（错误的解决方案排序）。这适用于以前的版本，但症状看起来非常相似。

Answer 1

我已通过生成服务器中的设置解决了此问题：选项卡上的MSBuild Multi-Proc。我有这个设置为True（默认），并得到了问题中提到的随机错误。将其转换为False已允许几天的代码检查，以便与该产品预期的工作完全相同地进行构建，测试和部署。

我的研究指向MSBuild和Visual Studio扫描项目中依赖项的方法之间的区别，但我还没有找到解决解决方案文件中这些差异的方法，并试图尽可能简化。切换到单一流程构建已将构建时间从3分钟增加到6分钟，但是我发现在面对非确定性和确定性结果之间进行选择时可以接受的损失。