使用 TeamCity 设置构建过程

Question

我开始在我的团队中实施 CI，我选择了 TeamCity，因为它对小型团队是免费的，而且它现在似乎也很流行，并且有很多不错的选择。

我尚未确定此服务器的“典型”或最佳用例是什么。

在我看来，绝大多数构建任务最好使用其他工具执行（让它在一些构建脚本中，如 MSBuild/NANT），而 TC 仅用于发出单元测试/构建触发器。

我发现很难设置完整的构建过程（复制文件/调用更复杂和基于逻辑的代码等）。

在构建过程中设置 TC 的最佳方案是什么？

我们的产品是基于 C# 的软件，带有各种“插件”。

我们正在构建 3 个大型 .sln 文件，当前使用 MSBuild 运行程序（只需将 .sln 文件指定为该运行程序的参数）。

这仅负责构建实际的二进制文件，但对于需要将各种项目的输出组合在一起的事情（例如创建安装程序）是不够的。

Answer 1

我能给出的最佳答案是描述我们的团队城市流程。我不能告诉你什么最适合你。我也不能告诉你什么是典型的，因为仅在我的公司中，我们就有大约 8 种使用 teamcity 的方法。

在我们的 .NET 项目中（这似乎是您关注的焦点，因为您提到了 MSBuild/NAnt），我们使用多个构建步骤进行构建。一个使用 teamcity 的解决方案运行器进行编译，下一个使用它的 nunit 测试运行器，最后一个使用 msbuild 来复制文件。

我们有另一个遵循类似模式的 .NET 构建，但添加了一些步骤来调用用 python 编写的自定义工具。

我们有一些只执行 NAnt 运行器的 java 构建。

做最适合您和您当前环境的事情。忍受一段时间，然后看看你想改变什么。

如果您已经有一个好的 msbuild 或 nant 脚本，只需将 teamcity 指向它并使用它来触发。

我喜欢使用 teamcity 的解决方案运行器，因为它可以正常工作。与他们的测试运行程序相同。但是 MSBuild/NAnt 非常适合文件模式工作。

希望对您有所帮助。

Answer 2

我们使用 TeamCity 如下： 1. 运行持续集成构建（一旦有人提交代码就触发） 2. 每晚构建 3. 每晚部署（使用批处理/shell 脚本） 4. 健全性测试（在夜间部署中触发）

Answer 3

从技术上讲，您可以通过脚本或工具完成 TeamCity 所做的一切。 TeamCity 的美妙之处在于它提供开箱即用的简单性来组织您的任务。 TeamCity 的核心是命令行以及与行业工具的开箱即用集成。它们减轻了配置负担，因此通过指定一些变量或参数，您可以自动执行繁琐的脚本可以完成的关键任务。 UI 以直观的方式巧妙地接收命令行参数。我最喜欢 TeamCity 的用例是它的历史意义，这源于其 UI 的强大功能。想象一下，如果您必须弄清楚您上次运行的脚本失败的时间或失败的原因？您必须保留历史日志、工件等，这些需要时间来整理以回答简单的问题。现在假设您必须报告自动化任务（构建）的历史趋势，您需要一个自定义实现来筛选您收集的所有数据，以便报告或回答简单的问题，例如“这个构建需要更长的时间吗？我们的单元测试数量增加了？”等等。所有这些数据点都是开箱即用的，并通过 teamcity 为您报告。如果你看不出来，我认为它是一个漂亮的工具。