如果习惯使用Jenkins，Jenkins和TeamCity之间的主要区别是什么？

#1 楼

TeamCity：

看起来确实更好，如果这对您的团队很重要，那么它应该确定地加重。也就是说，如果这非常重要，那么最终您可能会创建工具或某种仪表板覆盖以支持您的团队，此时您真正想要的是具有最佳API的API。还没有尝试过Jenkins API，所以我无法比较，TC API可以满足您的需求。但是，这并不意味着您会得到想要的东西。如果您以非常规的方式使用该系统，那么您很容易将您的错误发布在货架上……发生在我们身上。在这一点上，使用它变得非常令人沮丧，您将面临一个黑匣子，除了解决它以外，别无选择。在这一点上，事情可能会变得笨拙和难看。

通常，完成所需的操作通常很快，并且如果您在自己的程序中进行了大量自定义脚本，则日志交互类API是一个非常好的功能管道。

詹金斯：

经过战斗和广泛的测试。

但是它看起来不太漂亮，不会说丑陋。但是，可以说功能先于外观。

如果您四处看看，我很确定您可以找到第三方公司提供的私人付费支持计划。如果这对您的商店很重要，请不要仅仅阻碍交易的“ OpenSource”部分，社区就非常广阔。同样，不仅限于官方渠道，在github和其他地方可以找到更多的插件。

我发现两者的入门速度都差不多，尽管有了Jenkins，与TeamCity相比，插件可能需要更加动态。因此，如果您的IT部门很紧张，并且无法获得对服务器的管理员访问权限，则可能会出现问题。与TeamCity相比，它们的发布周期要快得多（每周一次）。

我发现Jenkins比TeamCity支持更多的发布周期范例。开箱即用的流程模板可能更容易找到与您所想的更匹配的模板。我之所以这么说是因为我已经两年没有与TeamCity打交道了。和配置机制与我更一致。

YMMV

#2 楼

总体而言，用户体验非常相似。 TeamCity具有更漂亮的UI，但并不是特别易于使用。就功能而言，两者实际上是等效的。大多数术语也相同。

插件生态系统却大不相同；您肯定会想了解TeamCity可以使用哪些插件来实现您要完成的任务，因为这可能是过渡过程中最大的痛点。如果您习惯于运行某些Jenkins插件，则需要学习a）TeamCity提供了哪些功能而无需任何插件，以及b）哪些插件可用于添加任何剩余功能，以及它们与您的插件有何不同在詹金斯已经习惯了。

#3 楼

我在大多数方面都同意阿德里安的观点。 TeamCity的UI绝对漂亮，并且与Jenkins相比，TeamCity提供了更多内置功能。但是Jenkins是开源的，尽管质量（和文档）因插件而异，但生态系统却很广泛。

我已经使用Jenkins多年了，最近才开始使用TeamCity。例如，与在TeamCity中相比，在Jenkins中设置依赖工作要简单得多，也更加直观。