连续集成工具

Question

我在做关于持续集成工具和好处的研究。对于我的研究，我看了以下工具：

1. GitLab CI
2. 詹金斯
3. 竹子
4. GoCD
5. TeamCity

现在我不会用所有的要求和好处来打扰你了。但到目前为止，除了这些工具之外，我还没有发现这些工具之间有那么多不同之处：

1. 扇入式扇出支持GoCD
2. 社区规模、Jenkins和GitLab似乎拥有最多的贡献者
3. 成本
4. 开源与否
5. 可用插件数量

我想知道是否有一些人选择了一个持续的集成工具，也可以分享他们的经验，他们为什么选择这个工具，以及是否有某些差异值得考虑，然后再选择，我没有涵盖。

现在，我倾向于GoCD，因为风扇扇出支持和可视化的持续交付管道，有谁有经验支持的问题，为这一工具？

谢谢你，

Answer 1

免责声明:在去年秋天之前，我是GoCD的积极贡献者。我没有使用GitLab CI，所以不会谈论这个:)此外，在过去的一年里，我没有使用过任何这些工具。

我认为TeamCity是一个很好的CI工具。如果您想调试一些故障，它与IDE集成得很好。测试报告很精彩。但我不认为它们在CD空间有那么先进，在我看来，两者都需要。但是如果你只对CI感兴趣，你可能会想看看它。但是，您将忽略我在下面提到的GoCD的一些好特性。

Jenkins有一个庞大的社区，但Jenkins也有自己的缺点。很多时候，一个插件由于另一个插件的兼容性问题而不能工作。

GoCD有扇入/扇出支持，这避免了许多不必要的构建，节省了大量的构建时间和资源。价值流图是直观的，有助于从开发人员、QA或甚至交付Manager的角度更好地了解构建阶段。在GoCD中的流水线建模也是很好的。如果您阅读Jez和David关于持续交付的书，您将看到这种构建设计背后的力量。

现在，关于第二个问题：

现在，我倾向于GoCD，因为风扇扇出支持和可视化的持续交付管道，有谁有经验支持的问题，为这一工具？

很高兴听到这个消息:P我爱GoCD。支持是好的。如果您选择采用开放源码的方式，邮件列表是非常活跃的。您可以期待GoCD团队在一两天内收到答复。当然，你的问题必须是真实和具体的。)在发布问题之前浏览论坛有助于:)

您还可以选择从GoCD购买对ThoughtWorks的支持。他们过去常常提供多个支持层，不确定当前的支持模型。只有当您的DB增长过大(~5-7GB)时，您才可能面临问题，而您可能需要从ThoughtWorks获得专用的Postgres支持。我见过很少有这样的DB大小的GoCD用户。

Answer 2

我在Teamcity和Gocd有很多经验。如果您对扇入/扇出感兴趣，也可以在Teamcity中这样做--这称为构建链。在官方博客上也有关于这个话题的好的帖子。如果我可以选择的话，我会更喜欢Teamcity。它更成熟，功能更丰富，适合在企业环境中使用。