TFS 2013 构建代理共享公共构建文件夹 [英] TFS 2013 build agents sharing common build folder

查看:40
本文介绍了TFS 2013 构建代理共享公共构建文件夹的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在本地使用 TFS 2013.我在构建机器上配置了四个构建代理.几个构建定义编译 ASP .NET 网站.我配置了 msbuild 参数以将 IIS 应用程序部署到位于 Rackspace 中的集成服务器.

I'm using TFS 2013 on premises. I have four build agents configured on a Build machine. Several build definitions compile ASP .NET websites. I configured the msbuild parameters to deploy the IIS application to the integration server, which sits out there in Rackspace.

默认情况下,webdeploy 通过比较文件日期进行差异化部署.就我而言,这是一个很大的优势,因为将文件从我们的网络复制到 Rackspace 需要相当长的时间.现在,为了保留文件日期,构建代理必须编译相同的基本源代码集.在每次构建时,只有差异源代码会生成一个新的 DLL,从而最大限度地减少部署的文件数量.

By default webdeploy does differential deployments by comparing file dates. In my case that's a big plus because copying files from our network to Rackspace takes quite some time. Now, in order to preserve file dates the build agent has to compile the same base set of source code. On every build only the differential source code yields a new DLL, minimizing the number of files deployed.

所有这些都可以正常工作,但需要注意的是:必须将给定的构建定义分配给构建代理(通过代理名称或标签).问题是当分配给同一代理的所有构建都排队时,我会产生很多意外情况.他们排队等待,直到前一个构建完成.

All of that works fine, with a caveat: a given build definition has to be assigned to a build agent (by agent name or tag). The problem is I create a lot of contingency when all builds assigned to the same agent are queued up. They wait in line until the previous build is done.

在理想的世界中,任何代理都应该能够处理任何构建,但编译的源代码必须相同,无论代理如何.

In an ideal world any agent should be able to take care of any build, but the source code being compiled has to be the same, regardless of the agent.

我尝试将所有代理的工作文件夹更改为指向同一位置,但我收到错误消息,因为两个代理无法映射到同一文件夹.我猜每个代理有一个工作区.

I tried changing the working folder of all agents to point to the same location but I get an error because two agents can't be mapped to the same folder. I guess there is one workspace per agent.

有什么想法吗?

推荐答案

我终于找到了解决方案.以下是您需要进行的所有更改:

Finally I found a way to do this. Here are all the changes you need to do:

  • 默认情况下,每个代理的工作文件夹是 $(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath).这意味着每个 BuildAgentId 有一个工作文件夹.我更改了它,以便所有代理共享相同的文件夹:$(SystemDrive)\Builds\WorkingFolder\$(BuildDefinitionPath)
  • 默认情况下,在运行时,工作流会创建一个类似于[BuildDefinitionId][AgentId][MachineName]"的工作区.由于所有代理共享相同的工作文件夹,因此尝试创建每个单独的工作区时会出错.对此的解决方案是在构建定义中:编辑 xaml 并查找名为从 Team Foundation 版本控制获取源代码"的活动.有一个名为 WrokspaceName 的属性.由于我希望每个构建定义有一个工作区,因此我将该属性设置为 BuildDetail.BuildDefinition.Name.
  • 保存您的自定义构建模板并创建使用它的构建.
  • 确保将选项1. TF VersionControl/1. Clean workspace"设置为 False.否则构建将清除每次构建的所有源代码.
  • 确保选项2. Build/3. Clean build"设置为false.否则构建将清除每次构建的输出二进制文件.
  • By default the working folder of each agent is $(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath). That means there's one working folder per BuildAgentId. I changed it so that all Agents share the same folder: $(SystemDrive)\Builds\WorkingFolder\$(BuildDefinitionPath)
  • By default at runtime the workflow creates a workspace that looks like "[BuildDefinitionId][AgentId][MachineName]". Because all agents share the same working folder there's an error trying to create each separate workspace. The solution to this is in the build definition: Edit the xaml and look for an activity called "Get sources from Team Foundation Version Control". There's a property called WrokspaceName. Since I want to have one workspace per build definition I set that property to the BuildDetail.BuildDefinition.Name.
  • Save your customized build template and create a build that uses it.
  • Make sure the option "1. TF VersionControl/1. Clean workspace" is set to False. Otherwise the build will wipe out all the source code on every build.
  • Make sure the option "2. Build/3. Clean build" is set to false. Otherwise the build will wipeout the output binaries on every build.

通过此设置,您可以在任何代理上排列相同的构建,并且所有这些都将指向相同的源代码和 bin 输出.当源代码更改时,仅重新编译受影响的二进制文件.我在模板中有一个自定义步骤,使用 msdeploy.exe 将输出文件部署到 IIS 到我们网络农场中的所有服务器.现在我的构建+部署需要一两分钟,因为只有在构建过程中更改的 dll 或内容会同步到服务器.

With this setup you can queue up the same build on any agent, and all of them will point to the same source code and bin output. When the source code changes only the affected binaries are recompiled. I have a custom step in the template that deploys the output files to IIS, to all the servers in our webfarm, using msdeploy.exe. Now my builds+deployments take one or two minutes, because only the dlls or content that changed during the build are synchronized to the servers.

这篇关于TFS 2013 构建代理共享公共构建文件夹的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆