svn - Subversion 'stack'是否可以替代Team Foundation Server？

Question

我正在为我的客户评估Microsoft Team Foundation Server，该客户当前使用Visual SourceSafe，而没有其他使用。他们明确表示希望在他们的应用程序投入生产时实现一个更严格且由流程驱动的环境，并考虑将来的发行版。

我要涵盖的特定 Realm 是:

配置管理(例如，
源代码控制)

变更管理(工作流程和文档
用于变更请求，任务)

发布管理(内部版本和
部署)

事件和问题管理
(问题和错误)

文件管理(类似于
源代码控制，但可以通过
网路)

签到代码分析约束

一个测试框架

报告

Visual Studio 2008集成

TFS可以很好地完成所有这些工作，但是维护起来既昂贵又复杂，而且廉价的Workgroup版本无法扩展。我们没有将TFS作为MSDN订阅的一部分。

这些问题可以克服，但是在我告诉我的客户走TFS路线之前，这本身并不是一件糟糕的事，我想评估一下替代方案。我知道Subversion通常被建议用于其配置管理/源代码控制，但是其他方面呢？ Subversion / NUnit / Wiki / CruiseControl / NAnt /其他组合是否可以满足所有这些要求？我需要在评估中包括哪些工具？

还是因为我们已经在Microsoft堆栈上进行了投资，我应该只是硬着头皮选择TFS吗？

Answer 1

好问题。我从未使用过TFS，但是使用许多工具肯定可以实现所有这些功能。最大的障碍是公司和开发人员的文化和思维方式。

我是SVN专业人士。 (但是我相信TFS可以工作)

我建议对日常工作轻描淡写。

在SVN中从一个分支到另一个分支具有沙盒或升级规则是一种进行代码分析而又不影响提交过程的方法。

因此，要解决您的每个问题:
SVN处理源代码管理，并辅助/包含在变更管理和发布管理中

变更管理/工作流程基本上由项目团队定义，可以通过简单的工具获得帮助，也可以仅通过策略来实现。

发布管理也是基于策略的，并使用现有的框架/工具(SVN)

几乎所有流行的缺陷/问题跟踪系统都可以处理事件和文档管理-考虑使用trac或fogbugz的Wiki(以及SVN和doc mgmt)

FXCop和所有其他工具可以作为代码分析构建的一部分

测试框架比工具驱动更基于策略-如果需要，则必须将其作为优先事项。

您的报告概念含糊不清，但我认为您在任何情况下都拥有足够的工具来满足此要求

对于与2008集成，我不确定您真正需要什么。无论如何，这与TFS的结合程度不高，但是我认为这不是问题。

(我认为您回答了自己的问题。)这最终可能是MS与反MS双方之间的一场宗教 war 。

在我负责推荐和实现解决方案的三个地方，我们投了赞成票-反对MS。我确信TFS能够胜任，但是竞争完全取决于任务，我认为这些工具可以很好地胜任其他工作。

至于要考虑的工具-我认为搜索Stack溢出以查找nant，msbuild，cruisecontrol等将为您提供的内容比您动摇的要多...