TFS 2008/2010与Jenkins的持续集成

是否有人有使用TFS 2008/2010和Jenkins进行持续集成（CI）的具体经验？我们正在尝试决定使用哪个CI服务器。我们的团队专门在Microsoft.NET/Visual Studio 2010/C#中工作。我们有以下要求：

在每次签入时自动构建我们的web项目

对每个构建运行单元测试

自动将绿色构建部署到开发和/或测试环境

提供漂亮的报告

通过电子邮件提供生成/部署通知

我意识到，安装一个工具并不一定能提供这种现成的功能，我们必须与其他工具（如MSBuild）集成才能实现这一点

---

我正在寻找Jenkins拥有的TFS 2008/2010没有的特定功能，反之亦然。另外，它更易于维护、使用等。

我强烈建议使用Jenkins-它可以满足您的所有需求，除了可能的#3之外，但如果您可以编写部署脚本，那么它也可以做到这一点

以下是一些帮助您建立和运行构建的链接：

---

免责声明：我没有TFS方面的经验，但我认为开放式解决方案几乎总是比专有产品更灵活、更可扩展（而且更便宜！）。

如果您使用的是Team 2010-2012，那么没有任何理由引入Jenkins。团队拥有您列出的所有特性，并且构建过程灵活得出奇

---

请注意，如果你被困在2008年或更早的团队中，你应该认真看看詹金斯——2008年或更早的团队与2010年或更高的团队相比是非常原始和不灵活的。

本游戏后期，但我已经使用了TFS 2010和詹金斯的CI。TFS 2010中至少有一组CI工具。但是，当您想要创建CI管道时，情况完全不同，而Jenkins可以轻松创建管道

如果您只查看一个构建的CI，那么其中任何一个都可以工作。然而，就整个管道而言，詹金斯还有很长的路要走。有了TFS，这是可以做到的，但詹金斯是更好的选择

以下是要点：

TFS：

• 使用构建定义，您可以编译、执行测试、返回变更集/工作项、在构建被破坏时发送电子邮件

• 与VisualStudio的自然集成

• 创建CI管道非常困难。需要自定义处理程序和大量的工作流工作。不像创建构建定义那样直观

• 由于第三个项目符号，维护/自定义/缩放CI管道并不容易

詹金斯：

• 需要为CI创建一个msbuild配置文件，这与使用TFS创建CI管道相比并没有多大困难。然而，TFS提供了更好/更容易的工具来创建构建定义。但是，为项目的msbuild创建配置文件并不坏

• 创建CI管道非常容易。只需使用上游/下游jenkins作业触发器链接它们，并传递上一个作业的工件

• 由于Jenkins非常灵活，因此很容易创建一个Jenkins插件来满足您自己的需要，并将其提供给开源社区：）

---

总之，如果您需要完整的自动化构建、测试和部署系统，请使用Jenkins。如果您只需要构建和测试，TFS可能会让您比Jenkins更具优势

Jenkins可以立即完成所有这些工作（TFS SCM插件、MSBuild插件、deploy-to-X插件），尽管“漂亮的报告”部分可能需要您付出一些努力。但对于这一点，有一个相当全面的API来检索构建信息和其他可能有用的东西。而且Jenkins真的很容易维护和使用。你可以使用浏览器做任何事情，所有选项都有可理解的上下文帮助，社区非常活跃和有帮助。此外，Jenkins有Chuck Norris插件，这对于破坏构建的开发人员来说是绝对必须的。TFS不提供这种特殊的功能插件。我完全同意并更喜欢开源解决方案，但我需要事实来说服我们的企业架构师Jenkins是一条可行之路。我过去曾广泛使用TFS，目前正在为一个客户机实现Jenkins，坦率地说，这是六分之一。TFS有惊人的VS IDE集成，在CODULTEX上有大量开源扩展，并且使用Windows工作流基础以便于扩展，而詹金斯有一个很好的开源插件集，一个庞大的用户社区，如果你是一个.NET商店，并且想为它编写一个插件，你需要用Java来完成。你能提供什么样的证据来支持这个说法？在将TFS和Jenkins用于.NET CI之后，我可以看到双方都有争议，但你提出了一个非常非同寻常的主张，甚至没有提到让TFS完全按照你想要的方式进行CI是多么具有挑战性，OOTB，而不会头痛。使用TFS配置主线分支、特性分支等可能非常繁琐，Jenkins似乎在简单配置方面击败了TFS。MSBuild非常简单。值得思考。我最近一直在努力解决这个问题，试图让一个完整的TFS自动构建并部署到Azure，而且它需要比它应该需要的时间更长的时间才能开始工作。问题是，持续集成模板只是自动选择解决方案中要部署的第一个web项目。。。但我有两个，按字母顺序它总是选错一个。没有其他选择，所以现在我正在努力定制部署模板，以避免开箱即用设计中的这一重大疏忽。您考虑过两个版本吗？