我正在研究持续集成工具并从中受益。对于我的研究，我正在查看以下工具：
现在我不会用所有的要求和好处来打扰你。但到目前为止，除了这些之外，我还没有发现工具之间有太多差异：
我想知道是否一些不得不选择持续集成工具的人可以分享那里的经验以及他们选择该工具的原因，以及在选择我没有涵盖的之前是否有一些值得考虑的差异。
由于扇入扇出支持和持续交付管道的可视化，现在我倾向于 GoCD 是否有人对此工具的问题支持有经验？
在此表示感谢，
免责声明：在去年秋天之前，我是 GoCD 的积极贡献者。我没有使用 GitLab CI，所以不会谈论这个:) 另外，我在过去一年中没有使用过这些工具中的任何一个。
我认为 TeamCity 是一个很好的 CI 工具。如果您想调试一些故障，它与 IDE 集成得非常好。测试报告很精彩。但我认为它们在 CD 领域并没有那么先进，而且我认为两者都需要。但如果你只对 CI 感兴趣，你可能想看看它。但是，您会错过我在下面提到的 GoCD 的一些优秀功能。
Jenkins 有一个庞大的社区，但 Jenkins 也有自己的缺点。很多时候，一个插件由于某些兼容性问题而导致另一个插件无法工作。
GoCD 具有扇入/扇出支持，可避免许多不必要的构建，从而节省大量构建时间和资源。价值流图很直观，有助于从开发人员、QA 甚至交付经理的角度更好地了解构建阶段。GoCD 中的管道建模也非常好。如果您阅读 Jez Humble 和 David Farley 的关于持续交付的书，您将看到这种构建设计背后的力量。
现在，关于你的第二个问题：
由于扇入扇出支持和持续交付管道的可视化，现在我倾向于 GoCD 是否有人对此工具的问题支持有经验？
很高兴听到这个消息：PI 喜欢 GoCD。支持很好。如果您选择采用开源方式，邮件列表非常活跃。您可以在一两天内收到 GoCD 团队的回复。当然，您的问题必须真实而具体。在发布问题之前浏览论坛会有所帮助:)
您还可以选择从 ThoughtWorks 购买对 GoCD 的支持。他们曾经提供多个支持层，不确定当前的支持模式。只有当您的数据库变得太大（~5-7 GB）时，您可能会遇到问题，而您可能想要从 ThoughtWorks 获得专有的 Postgres DB 支持。我见过很少有使用这种数据库大小的 GoCD 用户。
我在 Teamcity 和 Gocd 方面有很多经验。如果您对扇入/扇出感兴趣，也可以在 Teamcity 中做同样的事情——它被称为Build Chains。官方博客上也有一篇关于这个主题的好帖子。如果可以选择，我会更喜欢 Teamcity。它是更成熟、功能更丰富的产品，适合在企业环境中使用。