Team Foundation Server 2013 的不确定性构建服务器行为答案

【问题标题】：Nondeterministic build server behavior with Team Foundation Server 2013Team Foundation Server 2013 的不确定性构建服务器行为
【发布时间】：2015-07-02 23:46:00
【问题描述】：

随着我们团队的壮大，对构建服务器的需求也在增长，直到它最终成为我们处理的项目。

我们有一个主项目，它在提交到开发分支后排队等待自动部署。问题是构建服务器可以排队相同的构建，相同的修订并获得截然不同的结果。有时我们会得到一个干净的构建，并按预期部署到我们的测试服务器。在其他时候，我们可以将构建排队并得到“无法复制文件 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"。开始重试 1 中 1000 毫秒。该进程无法访问文件'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 作为问题的可能来源（不正确的解决方案排序）。这适用于以前的版本，但症状似乎非常相似。

【问题讨论】：

您是否修改了构建过程模板？听起来您做了一些修改，导致构建过程出现问题，而不是模板固有的问题。
没有任何构建脚本被改变。奇怪的是，这个错误发生了几次，然后也消失了（我没有任何干预，除了时间）。
您的项目文件中是否有构建前/构建后的操作？
无前置/后置操作。对构建的唯一调整是 MSBuild Arguments /p:VisualStudioVersion=12.0 /p:DeployOnBuild=true;PublishProfile=Stage 这是一个非常标准的 Web 项目自动部署。

标签： tfs msbuild

【解决方案1】：

我已经通过构建服务器中的设置解决了这个问题：MSBuild Multi-Proc 在Process 选项卡上。我将此设置为True（默认值）并且得到了问题中提到的随机错误。将其转至 False 后，我们可以在几天内签入代码，以完全按照产品的预期工作方式构建、测试和部署。

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

【讨论】：