Tfs 使用Team Foundation Server 2013的不确定性生成服务器行为

Tfs 使用Team Foundation Server 2013的不确定性生成服务器行为,tfs,msbuild,Tfs,Msbuild,随着我们团队的发展,对构建服务器的需求不断增长,直到它最终成为我们处理的项目 我们有一个主项目,它在提交到开发分支后排队等待自动部署。问题在于,构建服务器可以将相同的构建、相同的修订排队,并获得完全不同的结果。有时我们会得到一个干净的构建,按照预期部署到测试服务器。在其他情况下,我们可以对a生成进行排队,并获得“无法复制文件C:\Builds\7424\Project Name\Container build\bin\somerandomreference。对路径C:\Builds\7424\P

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

我们有一个主项目,它在提交到开发分支后排队等待自动部署。问题在于,构建服务器可以将相同的构建、相同的修订排队,并获得完全不同的结果。有时我们会得到一个干净的构建,按照预期部署到测试服务器。在其他情况下,我们可以对a生成进行排队,并获得“无法复制文件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。最初我们排除了构建文件夹,现在我们完全关闭了它

没有人使用这台机器,它专用于构建服务器角色,不运行其他软件,只包含构建过程所需的安装

我是否缺少构建服务器的最佳实践?对于构建服务器应该以可复制的方式构建源代码的相同分支和版本(即使是可复制的失败),我是否过于乐观了

更新:删除整个构建文件夹并进行设置备份后,我们得到了以下结果(解决方案编译中没有错误,但没有测试结果或输出):

更新2:流程似乎仍有问题,但不太常见。以下是今天早上发生的一个非致命错误的示例:

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' 因为它正被另一个进程使用


我目前正在调查问题的可能来源(不正确的解决方案顺序)。这适用于以前的版本,但症状似乎非常相似。

我已通过生成服务器中的设置解决了此问题:
进程
选项卡上的MSBuild Multi-Proc。我将此设置为
True
(默认设置),并得到问题中指出的随机错误。将此项切换到
False
允许几天的签入代码完全按照产品预期的工作方式构建、测试和部署


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

我已通过生成服务器中的设置解决了此问题:
MSBuild Multi-Proc
位于
进程
选项卡上。我将此设置为
True
(默认设置),并得到问题中指出的随机错误。将此项切换到
False
允许几天的签入代码完全按照产品预期的工作方式构建、测试和部署


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

您是否修改了构建过程模板?听起来您做了一些修改,这些修改会导致生成过程出现问题,而不是模板中固有的问题。所有生成脚本都没有被修改。奇怪的是,这个错误发生了几次,然后也消失了(除了时间之外,我没有任何干预)。您的项目文件中有构建前/构建后操作吗?没有构建前/构建后操作。对生成的唯一调整是MSBuild参数/p:VisualStudioVersion=12.0/p:DeployOnBuild=true;PublishProfile=Stage,这是web项目的标准自动部署。您是否修改了构建过程模板?听起来您做了一些修改,这些修改会导致生成过程出现问题,而不是模板中固有的问题。所有生成脚本都没有被修改。奇怪的是,这个错误发生了几次,然后也消失了(除了时间之外,我没有任何干预)。您的项目文件中有构建前/构建后操作吗?没有构建前/构建后操作。对生成的唯一调整是MSBuild参数/p:VisualStudioVersion=12.0/p:DeployOnBuild=true;PublishProfile=Stage,这是web项目的标准自动部署。
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)