我正在为我的客户评估Microsoft Team Foundation Server,他目前使用Visual SourceSafe,而不是其他任何东西.他们明确表示希望实现更严格和流程驱动的环境,因为他们的应用程序正在生产中,并且他们有未来的版本需要考虑.
我想要涵盖的特定领域是:
配置管理(例如,源代码管理)
变更管理(变更请求,任务的工作流程和doco)
发布管理(构建和部署)
事件和问题管理(问题和错误)
文档管理(类似于源代码管理,但可通过Web获得)
签到时的代码分析限制
一个测试框架
报告
Visual Studio 2008集成
TFS完成所有这些工作,但维护成本高昂且复杂,而廉价的Workgroup版本无法扩展.我们不会将TFS作为MSDN订阅的一部分.
这些问题可以克服,但在我告诉我的客户去TFS路线之前,这本身并不是一件可怕的事情,我想评估替代方案.我知道Subversion经常被建议用于配置管理/源代码控制,但其他领域呢？Subversion/NUnit/Wiki/CruiseControl/NAnt/other的组合是否满足所有这些要求？我需要在评估中包含哪些工具？
或者我应该咬紧牙关并使用TFS,因为我们已经投资了Microsoft堆栈？
一些非常大的项目在SVN或GIT上成功运行.
我倾向于使用不同的最佳应用程序,这些应用程序彼此交谈,而不是像TFS这样的单一创建.许多免费和商业bug跟踪器与SVN集成,测试运行器也是如此.创建自己的SVN之类的界面通常比让MS服务器应用程序做一些新事情更容易.
最后,从像SVN这样的东西迁移到下一个伟大的新事物比从TFS这样的专有软件包中获取数据更容易.
好问题.我从来没有使用过TFS,但所有这一切都可以使用许多工具.最大的障碍是公司和开发人员的文化和思维方式.
我是专业SVN.(但我确信TFS会起作用)
我建议对日常任务进行非常轻微的干扰.
在SVN中从一个分支到另一个分支具有沙箱或促销规则是在不阻止提交过程的情况下进行代码分析的一种方式.
因此,要解决您的每一点:SVN处理源代码控制,并且是辅助/包含在变更管理和发布管理中
变更管理/工作流程基本上由项目团队定义,可以通过简单的工具或仅由策略强制执行.
发布管理也是基于策略的,并使用现有的框架/工具(SVN)
大多数流行的缺陷/问题跟踪系统都将处理事件和文档管理 - 想想使用trac或fogbugz的wiki(以及用于doc mgmt的SVN)
FXCop和所有其他工具可以成为代码分析构建的一部分
测试框架比工具驱动更基于策略 - 如果这是您想要的,您必须优先考虑它.
您的报告概念含糊不清,但我认为您在任何情况下都有足够的工具来满足这一要求
对于与2008年的集成,我不确定你真正需要什么.在任何情况下,这并不像TFS那样紧密耦合,但我不认为这是一个问题.
(我想你回答了自己的问题.)这可能最终成为MS和反MS之间的宗教战争.
在我负责推荐和实施解决方案的三个地方,我们投票支持我们的钱包 - 对抗MS.我相信TFS是有能力的,但是竞争完全可以完成任务,我认为这些工具可以很好地用于其他工作.
至于要考虑的工具 - 我认为搜索堆栈溢出nant,msbuild,cruisecontrol等会给你更多的内容,而不是你可以动摇...
我认为以下堆栈优于TFS:
VisualSVN服务器 - 源代码管理
Jenkins - 自动构建
Redmine - 问题跟踪
这些工具中的每一个都有特定的用途,并且有自己的优点.它们可以很好地协同工作,但是当出现更好的东西时可以单独更换.
京公网安备 11010802040832号 | 京ICP备19059560号-6 