在 TeamCity 中仅发布构建的 .sln 文件工件答案

【问题标题】：Publishing only the built .sln files artifacts in TeamCity在 TeamCity 中仅发布构建的 .sln 文件工件
【发布时间】：2012-12-10 16:17:54
【问题描述】：

我们有一个 git 存储库，其中包含大约 6 个 .sln 文件。每个解决方案都有大约 15 个项目。

我们还使用 TeamCity 轮询我们的 git 存储库并构建以防发现任何更改。

我想通过以下方式增强我们的构建：

例如，如果开发人员更改了 2 个不同项目中的文件，则只有这些项目会被重新构建，并且只有它们的输出会被复制到某个位置作为当前构建的输出。

使用“Build”目标可以实现第一点，但是我找不到仅将已构建项目的输出复制到某处的方法。

【问题讨论】：

【解决方案1】：

我认为没有开箱即用的方法，我也不知道相关的插件。但是，您可以通过将构建生成的新二进制文件与以前的二进制文件进行比较并仅发布不同的二进制文件来获得所需的结果。

您应该使用能够识别 EXE 和 DLL 文件结构的 diff 工具，并且可以忽略每次构建时发生的变化——时间戳、PDB guid、签名等。这个问题已经在 SO 上多次讨论过。例如，Deterministic builds under Windows。

【讨论】：

构建生成大约 600 个文件。我认为针对旧版本（可能存储在某些网络驱动器上）测试每个版本会非常慢？
您可以考虑为构建生成的每个文件存储一个哈希值，并比较哈希值。同样，哈希函数必须了解 PE 文件结构并忽略每次编译时更改的字段。类似于 dumpbin > RemoveChangingStuff.bat > CalculateHash.

【解决方案2】：

TeamCity 提供了 VCS 触发规则，您可以使用这些规则仅在 repo 中某个路径下的文件发生更改时触发构建。您可以将这些规则与 Checkout Rules 结合使用，这些规则用于微调从 repo 中实际提取的内容。

VCS 触发/检出规则在构建配置级别定义。理论上，您可以监控单个项目中的更改，触发针对该项目的 .csproj 文件的构建。您的工件只是该单个项目的输出。但在实践中，您可能不希望每个项目都有一个构建配置。

单个 repo 中的 6 个解决方案听起来像是从 SVN 或 TFS 之类的东西迁移而来的。如果可能的话，我建议您将每个 sln 放在自己的 Git 存储库中。如果您使用 6 个 sln 来“管理”一个包含 90 个项目的单体应用程序，那么您还有其他一些挑战。

希望这会有所帮助，但有关您的 repo 和项目的更多信息会有所帮助！

【讨论】：