TFS与JIRA/Bamboo/SVN的比较

Question

TFS与JIRA/Bamboo/SVN的比较

svntfsdevelopment-environmentjirabamboo

9

本周我参加了2008 TFS的演示。目前我们正在使用Jira和Svn（可能还有Bamboo）。你更喜欢哪种解决方案？

- crauscher

9个回答

14

我非常支持开源运动，并在使用微软的产品中谋生。当企业尝试实施 TFS 时，我一直面临最大的问题是成本。毕竟，免费、功能齐全，由一大群人推出连续更新，并有大量易于集成的产品是很难被打败的。因此，为了进行开发环境，我使用 CruiseControl.net、CCTray、NAnt、NUnit、NCover、NDepend、NDoc、SVN 和 Tortoise。它们可以直接将工作结合起来。对于我而言，NAnt 是如此灵活，以至于我可以轻松创建 C# 自定义 NAnt 任务并插入其中。这使我能够更好地执行构建过程中的数据库自动化部分。使用 NUnit、NCover、NDepend 和 NDoc，我可以对代码库进行深度分析和报告，每次提交都会进行构建。构建完成后，分析结果将与开发团队共享。通过成功的构建，我可以将我的更改迁移到中央化的开发环境，让经理们看到团队的表现。使用 CruiseControl 始终检测我的代码很棒。使用此方法，我可以自动化所有不同环境之间的交互，从而使我能够向上或向下推送代码。更重要的是，即使没有像我这样技术水平的人，也可以将代码向上或向下推送。

TFS 可以执行许多相同的任务。然而，它需要更多的配置，并且不适用于几乎所有第三方工具。对我来说，缺乏灵活性是无法接受的（尽管我相信它会变得更好）。

对于一些人来说，情况恰恰相反，因为我使用的所有工具都是第三方工具。每个工具都需要单独下载、安装和配置。虽然我认为这很容易且无痛（因为它可以正常工作），但这可能是一些人不想跨越的红灯，他们更愿意花钱购买 MS 支持的项目。

- Andrew Siemer

2

@eglasius，楼主甚至没有提到“ALM” ¬¬ - Diego Ponciano

2

@Diego，我认为你忽略了OP正在将TFS与其他东西进行比较的事实，忽略ALM就像将飞机与汽车进行比较并说你不能谈论飞机能飞的事实一样 ;) - eglasius

@eglasius 事情是：原帖中并没有提到他需要飞行;) 至于我，我不需要这些“过程指导、集成工件、度量”之类的东西……也许他像我一样处于（幸福的）位置 :) - Diego Ponciano

这是一个公平比较的问题/请注意，我曾经在两种需要的环境中工作过，有时候你并不需要它。但是像所有事情一样，它有它的位置，你需要知道完整的故事才能判断它是否适合环境。棘手的问题是，最需要这个“流程指导、集成工件、度量等”的公司很少有人理解这种需求。总之，在我目前的环境中，我们不使用它，即1周冲刺推向生产，像工匠一样的方法，并且团队中有经验丰富的人参与其中。 - eglasius

11

由于问题涉及到JIRA而被大多数答案忽略了，所以我只是另一个回答。我认为问题不仅限于SVN，还包括JIRA。

这个比较看起来非常公正和有趣。在过去的四年中，我一直是SVN和Atlassian工具的忠实粉丝，并且仍然如此。最近我加入了另一家公司，该公司仍在制度化过程中（正如他们在CMMI中所说的），因此我们正在就同样的问题展开激烈的辩论。团队中的大部分人已经确信SVN、CruiseControl、NANT和Atlassian（是的，Atlassian是必不可少的）的想法，只有我不同意。因此，正如这个帖子中的每个人都说的那样，真正的比较是针对应用程序生命周期管理而不只是源代码控制，因此，对于完整的应用程序生命周期管理（少项目管理），我们需要什么？

源代码控制 - 应该轻松地创建分支、标签、执行代码合并，有时还应该通过HTTP工作
Wiki文档 - 程序管理者的天堂和开发者的百科全书和笔记区
Bug数据库 - 应该在程序员、程序管理者、QA人员和客户之间（是的，范围很广），这意味着酷炫的用户界面、跟踪功能以及与源代码控制的集成
源代码审查工具 - 必不可少的工具，这就是Atlassian再次发挥作用的地方（使用Fisheye和Crucible）
自动化构建 - 警报越多越好

如果您要在企业内部使用Visual Studio工具集和生态系统，则TFS是一个可行的选择。它与IDE的集成更深，并且所有5个方面都表现出色。每个项目都有SharePoint站点。然而，如果您不打算使用Visual Studio工具集或者项目将是公开的，那么Atlassian工具在云中免费提供。它们应该是首选。

这真的取决于您的项目和企业。它们都是很好的选择。

- Faheem

1

这是一个很好的观点；Atlassian产品非常不错，但如果你打算购买他们的解决方案，以至于它们的综合功能接近TFS，你会发现价格标签也与TFS相当，特别是如果你没有MSDN订阅。 - David Keaveny

1

@Faheem，你说“任何好的WIKI都不仅仅是一个好的SharePoint网站”... 你在开玩笑吗！？ SharePoint肯定是最糟糕的产品之一。即使它的生命取决于此，它也无法搜索自己的内容。它比任何维基都不易用，甚至是那些糟糕的维基！ - Jeach

1

@Jeach，这是一个来自'09年的答案。当时Atlassian套件并不像现在这么强大。我已经撤回了关于SharePoint比WIKI更好的观点...我也不再相信这一点了。我认为我提到的五个要点是主要思想，它们不像工具那样短暂。 - Faheem

5

如果您使用MS Visual Studio进行Windows编码，则TFS将是最佳选择。如果您使用Java开发，则我不会选择任何MS产品，因为它们是平台相关的。 Atlassian ALM产品系列非常好，JIRA＆GreenHopper，Confluence，Fisheye＆Crucible，Bamboo…是不错的工具，易于使用，对于小团队（＜10），价格很实惠。您不需要接受8小时的MS洗脑课程才能理解Atlassian许可证系统;-)

我们刚刚在测试项目中安装了“工具堆栈”，我们可以立即看到优势，并且我对所看到的结果感到非常满意。与SONAR的良好集成，我更喜欢Confluence Wiki而不是Sharepoint Wiki，审查工具Crucible很昂贵，但确实有用。

我不知道TFS 2010将带来什么-在功能和成本方面-但是每当我不得不处理它时，MS许可政策都会让我感到沮丧。

- OneCent

4

这是一个例子，你得到你所付出的东西。如果你的开发人员使用Visual Studio，那么TFS的价值就值得花费$$，因为它的集成显然会胜过其他工具。

此外，您还可以获得Web访问功能，客户/用户可以使用该功能创建功能请求和记录错误，而无需使用Visual Studio。而且，您还可以获得与SharePoint 2007团队站点的连接。TFS远不止于开发人员的“源代码控制”。

- Marc

3

我已经尝试过微软的一个“源代码控制”系统，不太可能再尝试另一个。

SharePoint的维基让我失望了。

不过他们做的那个.NET东西还不错...

就个人而言，我会担心TFS带来的供应商锁定问题。我认为在这个领域还有很多创新要做，像Bamboo和TeamCity这样的产品正在引领潮流。无论他们与VS的集成多么紧密，TFS都不可避免地会追赶。

- Squirrel

2

如何让一支100人的开发团队使用TFS？预计需要多少费用？

作为比较，我认为完整的Atlassian工具套件（JIRA、Confluence、FishEye、Crucible、Crowd、Bamboo）大约需要2万美元，再加上几天的咨询和培训，总费用就接近了。

对于小团队来说，我同意Atlassian的10美元10个用户的价格几乎无法被击败。

披露：我的公司Consulting Toolsmiths是Atlassian的合作伙伴。

- mdoar

2

TFS的云版本对于最多5个用户是免费的。 - Orlando Colamatteo

几天的咨询和培训...让我微笑。那种肯定的纯真。 - Mircea Ion

我应该说明每天的小时数 ;) - mdoar

1

TFS 2010提供多平台支持，因此您可以从Unix / Linux / Mac或Windows使用它。您必须尝试一下才能看到使用TFS2010获得的优势。它是完整的ALM解决方案，因此无法与任何非ALM工具进行比较。关于Teamcity和Bamboo，它们仅提供构建相关功能，这些功能远不及TFS 2010。 TFS 2010使用Windows Workflow进行构建，并在多平台机器上进行构建，这真是太神奇了。我的意思是，您可以采用测试自动化，从编码UI到简单的实验室管理（虚拟和物理），以及您可以生成的有助于您做出关键业务决策并改善团队绩效和流程的报告类型，在TFS中就是太棒了。看见才会相信。此外，如果软件质量，流程，支持和节省的资金对您的公司很重要，我强烈建议使用TFS。换句话说，如果投资回报率（ROI）和业务价值是关键因素，请选择TFS 2010。

- Ank

3

我花了6个月时间参与一个项目，将TFS 2008迁移到TFS 2010，但构建过程让我开始厌恶整个项目。从理论上看，这是个好主意，由于我有CruiseControl.Net的背景，我很期待使用WF，因为它可以使构建流程更易于理解和遵循。 - David Keaveny

2

但是......该实现非常糟糕。微软一定匆忙完成了它，因为在可重用组件方面的功能非常有限。当您考虑到像MSCommunityTasks和MSBuildExtensions这样的社区项目所提供的内容时，微软显然看了一眼，然后完全忽视了它们。例如，甚至没有复制文件的任务！您可以调用COPY.EXE，但那太弱了。然后更令人恼火的是，如果您尝试编写自己的组件，该过程非常糟糕，涉及大量与GAC messing around. - David Keaveny

2

继续翻译关于编程的内容：我喜欢的一件事是他们使测试变得容易；但除此之外，开发WF控件就是徒劳无功。难怪至今没有为Team Build提供重要组件库。TFS的其他部分是合理的——在孤立状态下相当普通，但将它们放在一起，确实构建了比各自部分更伟大的东西。 - David Keaveny

1

还值得一看的是：

SVN vs. Team Foundation Server

- Dave Markle

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- SqlRyan · Accepted Answer

如果你只是使用TFS进行源代码控制而没有其他用途（顺便提一下，这种做法就像包机去买快餐一样浪费），那么你最好选择专门的源代码控制解决方案（SVN等）。TFS是一个“应用程序生命周期管理”（ALM）工具，集成了大量的附加功能：

缺陷跟踪
开发者任务
外部问题提交
自动化构建
代码报告
项目状态更新/时间预测
还有很多其他功能

将其与只做源代码控制的工具进行比较并不公平 - 如果这样做，TFS会显得笨重和昂贵。有一些工具可以用来完成所有这些事情，并且它们在大多数情况下都能很好地整合在一起，但特别是如果你的开发人员都在使用Visual Studio（如果有人没有，可以用http://www.teamprise.com/），并且你的公司内部有一些Sharepoint知识，尤其是如果你的开发人员拥有MSDN许可证（MSDN包含TFS的CAL，所以你只需要购买服务器许可证），那么TFS无法被打败。