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

这些工具似乎具有非常相似的特征。

习惯了Jenkins之后开始使用TeamCity会有多复杂？是否需要注意一些具体概念？

TeamCity：

它看起来确实更好，如果这对您的团队来说很重要，那么它应该绝对地发挥作用。也就是说，如果这非常重要，那么您最终可能会创建工具或某种仪表板覆盖以支持您的团队，此时您将真正想要的是拥有最好的API的API。还没有尝试过Jenkins API，所以我无法比较，尽管TC API应该可以为您提供所需的东西。

他们的支持非常好，伙计们反应比较快，很有礼貌。但是，这并不意味着您会得到想要的东西。如果您以非常规的方式使用该系统，那么您很容易将您的错误发布在货架上……发生在我们身上。在这一点上，使用它变得非常令人沮丧，您将面临一个黑匣子，除了解决它之外别无选择。在这一点上，事情可能会变得有些丑陋。

通常您可以很快完成所需的工作，并且如果您在管道中执行许多自定义脚本，则日志交互类API是一个非常好的功能。

詹金斯：

经过战斗考验且内容广泛。

但是它有点不那么漂亮，尽管说起来很难看，但可以说功能先于外观。

如果您四处看看，我很确定您可以找到第三方公司提供的私人付费支持计划。如果这对您的商店很重要，请不要仅仅阻碍交易的“ OpenSource”部分，社区就非常广阔。

很多，我是说很多插件。同样，不仅限于官方渠道，在github和其他地方可以找到更多插件。

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

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

我个人更喜欢Jenkins，主要是因为我偏向于Open Source来使用此类工具，而在较低程度上，因为我发现它的结构和配置机制与我更一致。

青年汽车

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

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

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

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