我们正在评估CI环境，其中有一些：
TeamCity，Go，CCnet，BuildForge，TeamBuild，FinalBuilder Pro，Visual Studio Team System。
我在评估CCnet与Go
时遇到的困难最大每个人彼此之间的利弊是什么？
答案 0 :(得分：2)
卢卡斯
首先，警告 - 我为这个领域的供应商工作（Urbancode - AnthillPro人员）。 [/放弃]
我认为这取决于你真正试图摆脱这个工具的东西，并且根据你选择的工具很难猜测。您的列表中有免费工具，廉价工具，中等工具和昂贵的工具。如果你想为一个大企业创建一个构建基础架构，那么昂贵的人更合适，而如果你只是建立一个团队级别的系统，开源可能没问题。
除了可扩展性之外，Go（和AnthillPro）之类的工具与CC.Net之间的最大区别可能就是你在构建完成时要对它们做些什么。如果在构建之后，您所做的只是发送电子邮件，基本的团队级CI系统可能非常合适。相反，如果要将其部署到一个测试环境，则任一系统都可以满足要求。如果您想通过六个测试环境部署构建，获得一些批准，然后在整个过程中使用完整的审计跟踪部署到生产，CC.Net之类的东西就不会削减它。你正在看世界的Go，BuildForges和Anthill。
集成之类的东西也很重要 - 该工具必须与您使用的其他工具协同工作。
答案 1 :(得分：1)
Eric的答案非常有趣。
在我们公司，我们使用CC.net进行CI和部署。但是，cc.net只是一个管理我们构建中使用的所有其他工具的工具（主要是msbuild，但也包括sql部署，nunit，iis管理......）。因此，我们不能说cc.net负责部署任务，它只是启动一个msbuild脚本来完成工作并将日志聚合到用户友好的仪表板。
我想补充一点，如果您寻找全局CI工具（CI +构建脚本+部署），您可以忘记cc.net。但是如果你对msbuild，NAnt或任何构建/脚本语言有所了解，你可以使用它。后者的优点是您的构建是可重用的，如果您更改CI工具仍然可以使用它们，如果您执行TFS构建脚本，我不确定您是否可以将其与其他工具一起使用...
我们使用CC.net + MsBuild做的事情：
至于Go，我从未尝试过，抱歉。您也可以考虑Hudson（即使是.Net）。