Question

随着我们团队的发展，对构建服务器的需求不断增长，直到它最终成为我们解决的项目。

我们有一个主项目，在提交到开发分支后排队等待自动部署。问题是构建服务器可以排队相同的构建，相同的修订并获得截然不同的结果。有时我们会得到一个干净的构建，按预期部署到我们的测试服务器。在其他时候，我们可以对构建进行排队并获得＆＃34;无法复制文件C：\ Builds \ 7424 \ Project Name \ Container Build \ bin \ somerandomreference。访问路径C：\ Builds \ 7424 \ Project Name \ Container Build \ bin \ somerandomreference被拒绝＆＃34;。

或者我们得到：无法复制文件＆＃34; Scripts \ somerandom.js＆＃34;因为没找到。

或者我们得到＆＃34;无法复制...... EntityFrameWork.XML＆＃34;因为它正被另一个进程使用。

这些让我相信问题在于我们的构建重叠，所以我们设置队列以添加额外的提交，直到早期的构建完成。

唯一的防病毒软件是运行构建服务器的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）：无法复制＆＃34; C：\ Builds \ 7419 \ Policy Tracker \ Container Build \ src \ Stage \ packages \ Microsoft.Owin.Security.Cookies.3.0.1 \ lib \ net45 \ Microsoft.Owin.Security.Cookies。 DLL＆＃34; 到＆＃34; C：\ Builds \ 7419 \ Policy Tracker \ Container 建立\ BIN \ Microsoft.Owin.Security.Cookies.dll＆＃34 ;.开始重试1 1000毫秒。该进程无法访问文件＆＃C; \ Builds \ 7419 \ Policy Tracker \ Container Build \ bin \ Microsoft.Owin.Security.Cookies.dll＆＃39; 因为它正被另一个进程使用。

我目前正在投资http://blogs.msdn.com/b/visualstudio/archive/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx作为问题的可能来源（错误的解决方案订购）。这适用于以前的版本，但症状看起来非常相似。

Answer 1

我已通过MSBuild Multi-Proc标签上的构建服务器Process中的设置解决了此问题。我将此设置为True（默认值）并获得问题中记录的随机错误。将其翻转到False已经允许几天的签入代码来构建，测试和部署，就像预期产品一样。

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

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

1 个答案: