如何使用 TFS 实现构建管道
我尝试使用 TFS 实现构建管道。
我们已经让 TFS 在每次提交后构建我们的项目。 但构建时间太长，因此我们希望将构建分为两个阶段。 持续集成文献建议采用这种技术。
所以我正在寻找的是做以下事情。
- 开发人员检查他的源代码。
- TFS 自动触发构建来编译代码并运行一些基本测试（我们已经有了）。 开发人员得到快速反馈，表明他的更改没有破坏一些明显的东西。
- 接下来，如果构建成功，则会触发新的 TFS 任务/构建，该任务/构建会获取前一阶段的工件并运行一些更耗时的测试。
关于如何实现这一点有什么想法吗？
I try to implement a build pipeline using TFS.
We already have TFS building our projects after each commit. But the build take too long so we would like to split the build into two stages. Continuous integration literature suggest this technique.
So what I am looking for is something to do the following.
- Developer checks in his source code.
- TFS automatically triggers a build to compile the code and run some basic tests (we already have that). The developer gets quick feedback that his changes did not break something obvious.
- Next if the build succeeded a new TFS task/build is triggered which takes the artifacts from the previous stage and runs some more time consuming tests.
Any ideas on how to implement this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
1) 编写一个监听 BuildCompleted 事件的服务。 IIS Web 服务示例代码。 自托管 WCF 示例代码。 在事件处理程序中，调用 TFS Build API 启动定义附加任务的单独构建类型，或者直接从此处执行自定义代码。
2) 使用 TFS 注册您的服务，添加 成功构建的服务器端过滤器。
1) Write a service that listens for the BuildCompleted event. IIS webservice sample code. Self-hosted WCF sample code. In your event handler, either call the TFS Build API to kick off a separate build type that defines additional tasks, or simply execute custom code directly from here.
2) Register your service with TFS, adding a server side filter on successful builds.
目前，我们正在使用 MSBuild 中的
At the moment we're doing this using the
<AfterEndToEndIteration>target in MSBuild, and<Exec>ing TfsBuild.exe.您可以让中间版本或次要版本将生成的程序集签入源代码管理中。 这样，您就可以让其他构建使用已编译的 DLL 来打包和构建系统的第二部分。
您可以让“更大的”组装构建侦听库构建中的签入，并组装依赖于该构建的构建。
当然，您可以签入二进制代码，但除非您做了一些奇怪的事情，否则您应该有足够的硬盘空间。
You could have your intermediary, or minor builds check-in the resulting assemblies into source-control. That way you can have the other build use the already compiled DLL's to package and build the second part of the system.
You could have the "bigger" assembling build listen to check-ins from the library builds and assemble the builds dependant on that one.
Sure you get to check-in binary code, but unless your doing something strange you should have enough harddrive space.