我开始在我的团队中实施CI，并且我选择了TeamCity，因为它对于小型团队来说是免费的，而且它现在看起来也很受欢迎，并且有许多不错的选择。
我还没有确定此服务器的“典型”或最佳用例。
在我看来，绝大多数构建任务使用其他工具（让它在某些构建脚本，如MSBuild / NANT）中更好地执行，而TC仅用于发出单元测试/构建触发器。
我发现很难设置一个完整的构建过程（复制文件/调用更复杂和基于逻辑的代码等）。
将TC设置为构建过程的好方法是什么？
我们的产品是基于C＃的软件，带有各种“插件”。
我们正在构建3个大型.sln文件，目前正在使用MSBuild运行器（只需将.sln文件指定为此运行器的参数）。
这只需要构建实际的二进制文件，但对于需要将各种项目的输出组合在一起的东西是不够的，例如用于创建安装程序。
答案 0 :(得分：1)
我能给出的最佳答案是描述我们的团队城市过程。我不能告诉你哪种方法最适合你。我也不能告诉你什么是典型的，因为在我的公司中，我们有大约8种使用团队城市的方式。
在我们的.NET项目中（自从您提到MSBuild / NAnt以来，这似乎是您的重点）我们已经构建了多个构建步骤。一个使用teamcity的解决方案运行器来编译，下一个使用它的nunit测试运行器，最后一个使用msbuild来复制文件。
我们有另一个遵循类似模式的.NET构建，但添加了几个步骤调用用python编写的自定义工具。
我们有一些只能执行NAnt跑步的java版本。
做最适合您和当前环境的方法。与它一起生活一段时间，然后看看你想要改变什么。
如果你已经有一个好的msbuild或nant脚本，只需指向teamcity并将其用于触发。
我喜欢使用teamcity的解决方案跑步者，因为它才有用。与他们的测试运行员相同。但MSBuild / NAnt非常适合文件模式工作。
希望有所帮助。
答案 1 :(得分：0)
我们使用TeamCity如下： 1.运行持续集成构建（一旦有人提交代码就触发） 2.每晚构建 3.每夜部署（使用批处理/ shell脚本） 4.完整性测试（在夜间部署中解雇）
答案 2 :(得分：0)
从技术上讲，您可以通过脚本或工具完成TeamCity所做的一切。 TeamCity的优点在于它提供了开箱即用的简单性来组织您的任务。 TeamCity的核心是命令行和与行业范围工具的开箱即用集成。它们减轻了配置负担，因此通过指定一些变量或参数，您可以自动执行繁琐的脚本可能完成的关键任务。 UI以直观的方式智能地接收命令行参数。我最喜欢的TeamCity用例是其历史意义，源于其UI的强大功能。想象一下，如果你必须弄清楚你运行的脚本最后一次失败或失败的原因？你将不得不保留历史记录，工件等，这些都需要时间来回答简单的问题。现在想象一下，您必须报告自动化任务（构建）的历史趋势，您需要一个自定义实现来筛选您收集的所有数据，以报告或回答简单的问题，例如“这个构建需要更长时间吗？”我们的单元测试数量在增加？“所有这些数据点都是开箱即用的，并为teamcity报告。如果你不能说，我认为这是一个很好的工具。