在触发 TFS 团队构建期间排除特定路径答案

【问题标题】：Exclude specific paths during triggering TFS team build在触发 TFS 团队构建期间排除特定路径
【发布时间】：2015-05-31 14:05:22
【问题描述】：

我正在配置与 TFS 2012 的持续集成。我有一个问题需要解决。我需要排除一些触发构建的路径。

例如我有：

$/Project1
$/Project2

而且我希望在每次签入 $/Project1 后触发构建。它必须同时构建 $/Project1 和 $/Project2。但是在签入 $/Project2 之后，我不想触发该构建定义的构建。

在 Build Definition 的 Source Settings 中只有“Active”和“Cloaked”功能，但这不是我需要的。

非常感谢。

附：值得的解决方案是在签到时添加评论***NO_CI***。如果有其他方法就好了。

【问题讨论】：

为什么有两个依赖的项目文件夹？它们不应该属于同一个解决方案吗？
创建 2 个构建，为项目 1 构建 1，然后在项目 2 完成时触发构建 2？
@MrHinsh，如果这些项目在同一个团队项目或同一个解决方案下会有什么变化？问题依然存在。我需要 TFS 忽略来自特定路径/项目的签入而不触发构建。但没有隐形。当他们（其他项目）签入时，我需要它与其他项目一起构建。
@JustTFS ，是否可以在 TFS 原生持续集成工具中使用？据我所知，TFS 构建定义之间没有任何依赖关系。每个构建定义都是独立的项目，有自己的工作流程。我知道该怎么做，例如在 Jenkins 或 Team City 中，但不在 TFS 中。但如果你知道这样的方法，我希望你与我分享。我将不胜感激。
如果在同一个解决方案中，那么它们都将根据需要以正确的顺序构建。那你就不用关心这个问题了。

标签： tfs build continuous-integration

【解决方案1】：

根据 cmets，这归结为 X-Y 问题。你不能做你想做的事，但你想做的原因是因为你试图解决错误的问题。

您在开发测试周期的错误位置运行 UI 测试。 UI 测试不应该在构建期间运行，它们应该在发布之后运行。对测试项目的更改绝对会导致构建。

有人正在针对尚未进行源代码控制的代码开发 UI 测试，这毫无意义。如果有人针对代码编写测试，代码应该是源代码控制的。

我猜有人正在手动将未提交的代码推送到开发服务器，其他人正在使用该服务器编写测试。不要这样做。使用真正的发布管理解决方案，以便在开发人员编写代码时，每次签入都会自动部署到开发/QA 环境中。然后编写 UI 测试的人将有一些东西要测试。针对处于不断变化的状态的代码编写测试有什么意义，以至于负责它的开发人员甚至不确定它是否值得进行源代码控制？随着代码的发展，这只会导致花费大量时间重写测试。

假设您正确设置了所有内容，应用程序代码的每次提交都会导致当前的测试集针对最新的提交运行。测试代码的每次提交都将导致针对现有应用程序代码运行新的测试集。这两件事（应用程序代码和测试代码）应该耦合，并且应该始终构建在一起。

最后一件事，主要是意见：UI 测试很糟糕，而且几乎没有用处。它们易碎、缓慢且难以维护。我从未见过一个全面的 UI 测试套件真正提供价值。 UI 测试最好作为一小组发布后的冒烟测试。业务逻辑应该主要进行单元测试，并使用较小的集成测试套件来支持它。

【讨论】：

对我来说听起来更糟@Daniel；听起来他们正在尝试解决检查工作代码的问题。做海事律师并不能提高质量...
@Daniel，我在正确的位置运行测试。我不仅开发了持续集成，还开发了持续部署和持续交付。当我签入更改时-简而言之，以下过程开始：执行静态代码审查->更改版本->编译->运行单元测试->部署/安装（应用程序、数据库等）->在新的上运行 UI 测试部署的应用程序等。所有这些过程都在 1 个构建定义中。
我们得到任务 - 例如“使用此功能添加此输入字段”。和子任务——“进行数据库开发”、“进行应用程序开发”、“进行 UI 测试开发”。我已经知道必须在哪里添加该输入字段，以及我必须如何使用它。所以我为它编写了测试用例并签入。但是我不想在没有签入该字段的实现之前触发CI流程。
关于单元测试和 UI 测试的比较，以及你的意见。经典单元测试永远不能用来替代 UI 测试，反之亦然，因为它们有不同的目的。单元测试可用于仅在代码级别测试程序 - 功能验收/集成测试 - 函数按预期工作 - 它获得特定类型的参数的预期/意外计数，并返回预期结果。并且程序中的功能也可以按预期相互交互，等等。
但是通过单元测试你不能测试客户端/前端。您无法确定 UI 元素是否与后端明确集成并执行正确的功能并执行所需的操作，尤其是考虑到浏览器特定的功能/问题等。关于可维护性。您只是还没有看到我创建的 UI 测试项目，可能正因为如此，您认为 UI 测试很糟糕且难以维护 ;))) 无论如何 - 自动化 UI 测试的重要性不是我讨论的主题，因为我清楚地看到了它的优势。