使用Rational Team Concert有哪些风险？

Question

在软件开发中使用Rational Team Concert会带来什么风险？

Answer 1

Rational Team Concert？风险是，供应商锁定，不适合你的目的，不符合你的工作流程，缺乏理解或培训

实时时钟？您的应用缺乏准确性

实时控制？保证延迟。特别是在没有提供任何特定功能的操作系统上。此外，RTC应用程序往往是高度线程化的，并且要求程序员采取非常具有策略性的方法来管理并发性以实现实时控制

Answer 2

Team Concert供应商锁定？疑。您可以随时将整个SCM存储库导出到Subversion。所有工作项目都可以通过CSV文件导出... 或者您可以使用提供的Java SDK导出所有内容...我认为他们尽可能少地锁定了内容。

Answer 3

我是一个小团队的成员，他们每天都在使用Rational Team Concert（RTC;第一版本2，现在是第三版本），现在每天使用大约9个月。

我同意本杰明对供应商锁定的评论。 “缺乏理解或培训”的风险已经为我们多次表现出来。

我强烈建议RTC不要在Visual Studio内使用RTC进行源代码管理，任何有*选择源代码控制工具的Visual Studio用户都应该能够在不费力的情况下找到合适的替代方案。工作项目跟踪/等（非源代码控制功能集）很好，但是这里有一些关于它的源代码控制集成w/VS2010的想法。我们必须不断（手动）“刷新”窗格，以了解在我们的工作站和存储库之间存在什么差异真的我们已经了解到RTC的“待定更改”窗格在其表面上不可信。我们与团队共享我们的工作的情况并不少见，尽管“Pending Changes”窗格告诉我们没有发送到存储库的一些文件是而不是（导致团队成员损坏）。在我们向团队“交付”（RTC的“签入”期限）后，更改仍在进行中。

更糟糕的是，这种“待定变更”的混淆让我们的团队多次失去完整的代码。无论在什么程度上我们的无知或忽视都会导致这些损失，我们还没有经历过替代的源代码管理产品。它认为RTC客户端认为当我们接受他人的工作时，我们没有任何“待定变更”（如果RTC没有意识到您接受另一个开发者对您修改的文件的更改可以覆盖您的更改已经改变了文件）。

客户端的“显示历史记录”和“与来自存储库的以前比较”产品会在我们的上下文菜单中间歇性地禁用它们自己。在这些时刻，查看（或注释）文件修订历史记录所需的手动解决方法至多是费力的。

如果我们在任何时候在我们的工作站上修改了太多文件，“Pending Changes”窗格会停止向我们显示文件列表 - 它会显示计数。实现此目的所需的同时修改文件的数量在数百个（这确实是一个很大的数目），所以我们很少看到这一点，但在大型代码库中进行大型重构来影响这些许多文件并不是闻所未闻。

这些只是一个窗格周围的缺陷。围绕客户端的源代码管理产品的其他行为也是错误/不直观的。

一般来说，RTC2 VS2010客户端（我的大部分使用时间）提供的质量水平我用β产品相关联。 RTC3的VS2010客户端（我从这些客户端获得了上述所有观察结果）更好，并且带来了新功能（例如设置当前工作项目的功能），但我不会将它推荐给任何具有正在选择的选项的Visual Studio用户源代码管理产品。它仍然越来越多，一直怀疑。

Answer 4

我就是开发RTC客户端的Visual Studio开发团队的一员，我很失望地得知，与RTC VS客户端的体验并不令人满意。 我回过头来看看你在jazz.net上登录的缺陷 - 我们似乎已经解决了大部分缺陷，而那些仍然没有谈论Pending Changes视图的可靠性或禁用莫名其妙的菜单项。

我们还没有来自其他用户的类似投诉，所以我想请您登录缺陷对你已经在这个岗位描述，与跟踪文件的问题。我相信你所说的一些缺陷是不能复制的 - 如果你还在经历它们，请重新开启这些缺陷。

干杯 --Rupa

Answer 5

要回复到原来的问题，我和我的团队一直在使用VS客户端的RTC，因为我们的第一个里程碑，年约3个半前，我们有一个庞大的用户群现在，我建议在https://jazz.net/forums/viewforum.php?f=17上发布这个问题。

回答您的问题：

1. 没有厂商锁定插件。我想说，与变更和配置管理域中的其他许多工具相比，我们有一个非常开放的故事。
2. RTC与Visual Studio有良好的整合性。它完全是原生的，围绕VS包构建，并与VS的解决方案资源管理器，属性，工具，错误视图，编辑器框架等很好地集成在一起，为VS用户提供本地外观和感觉。
3. 在jazz.net上有大量的博客，文章，视频和论坛帖子 - 你可以看看那些以获得融合的感觉。
4. 您也可以在jazz.net上创建一个沙盒，并使用RTC VS Client连接到沙盒，为自己找出体验。

干杯

--Rupa

Answer 6

使用Rational Team Concert在不的风险是

1. 使用不彼此很好地集成工具。 RTC集成了计划，缺陷跟踪，源代码控制，构建和报告。所以你可以很容易地看到什么修补程序进入了一个特定的版本，代码被改变了，为什么。如果您不喜欢代码中的修复，则可以对该工作项目发表评论，并通过截图来说明一个观点。
2. 使用不随项目增长的工具。您可以使用预定义的流程模板快速开始使用RTC。随着您添加更多成员，更多团队和更多代码，您可以调整流程规则，以决定谁应验证错误，在发布结束时收紧规则，自动构建，设置分阶段流。 RTC由小型团队和庞大的团队使用。
3. 使用仅适用于开发人员或管理人员的工具，但不能同时工作。借助RTC，管理人员可以构建花哨的仪表板来跟踪Web UI中项目的健康状况。开发人员可以在Windows，Linux，Mac（Eclipse，Windows上的VS）中的IDE中工作。还有一个命令行工具。而且更多的是，他们的4.0 Beta版以新的Windows资源管理器客户端为特色。因为IDE对于开发人员来说很酷，但对于测试人员或图形设计人员来说并不那么酷。
4. 使用将您锁定到特定操作系统的工具。如3所述，也许今天你的项目主要是Windows，但明天呢？ RTC拥有Windows，Linux和Mac的客户端。

但就像我去苹果商店试试最新的小工具，你可以去www.jazz.net并下载RTC的试用版来亲自看看。将少量数据导入到数据中，并查看它对您和您的团队的感受。

Answer 7

报告很薄弱。你所需要的数据在那里，但是把它拿出来并转换成客户接受的格式是很难做到的。我需要一个ProPath兼容的需求追踪矩阵和它的近亲，一个验证交叉参考矩阵（VCRM）。祝你好运。

它不是开源的。您没有一个查看源代码的用户社区来识别和修复漏洞。后者是五角大楼（美国军方）越来越接受开源的原因;很难将特洛伊木马变成每个人都在看的代码。

什么不是风险是你最终能够完成你的工作。没有人因挑选IBM而被解雇。 :-)

Answer 8

我们在办公室使用RTC，它工作得相当好。虽然你需要知道两件事：

• 它并不是真正的分布式版本控制系统，比如Git或Mercurial。它更像CVS。它确实支持更改集。
• 请勿将其与derby数据库一起使用。它在我们的情况下无数次地坠毁。我们现在在DB/2上运行它，现在它运行稳定。
• 它也支持完整的应用程序生命周期，但对我来说，这是一个臃肿系统的负担，而不是一件好事。
• 如果你来自CVS或Subversion，这是一个很棒的系统。
• 如果你来自Git或Mercurial，这没什么特别的。

Answer 9

我知道这是一个古老的线程，但如果其他人来这里我分享我的个人经验。

我们在过去几年里一直在使用它，并且作为一个头条新闻RTC已经发展成为SCM，我根本不信任我的文件。

工作流程如此不同以至于其他供应链管理系统如此以至于整体而言，这是一个过于复杂和复杂的系统，不时会导致您失去更改。

事实上，有一篇关于所谓功能的文章，称为“备份棚”，只能说明我没有错的故事，需要这样一个功能的事实告诉我们一个关于如何自我的故事变化可能突然消失。 - https://jazz.net/library/article/191/?errno=1

从其他供应链管理的我们非常习惯于只有“恢复”覆盖本地更改。在RTC中，这发生在许多其他场合。一个得问问，怎么努力也可能它是合并文件和/或在这些冲突的情况他们...

RTC将覆盖文件，当您：

• 重新同步您的工作，因为你无法从不同步的WS中检入，你无法避免这种情况，所以在上帝的帮助下，先做好备份！
• yup这是正确的，尽管所有其他SCM的做法是......它会让您在接受更改之前先检查本地更改，但是请记住点击“是”以致于PRAY它已经发现了所有本地更改。
• 随机？...我相当肯定已经经历过其他变化，其中变化消失了，但只有上述2已经是我已经能够把手指...
• 恢复...显然，只有一个子弹实际上应该在这个列表中。

这可能是“设计”......但后来我想投一个真的很糟糕的设计。

另外，除非另有说明，如果您使用的是Visual Studio，请始终在签入前单击刷新远程和本地更改。作为Subversion（尽可能老）的解决方案在发现更改时比RTC更好，因此GIT ...

此外，SVN和Git在许多IDE中都有很好的实现......我认为花费一些时间直到Git变得可以忍受在Visual Studio中使用，但现在肯定是！虽然还有一些功能需要。 SVN可以与许多工作项目/问题跟踪系统集成，但对于Jira集成，我实际上更喜欢在注释中编写问题编号，它更快更容易......并且它创建链接，因为FishEye拾取更改集，所以Jira将显示提交的问题。

我不能说如何Git/Stash组合或SVN与YouTrack/Mingle在这里工作。但是在RTC中，将工作项附加到提交的工作流成为了这个巨大的开销，所以我们停止使用它=不值钱的功能。

然后是系统的整体计划，工作项目，scrum等部分......我唯一会喜欢的部分是它不时给我的笑声。除此之外，它几乎是无用的...去Jira + GreenHopper，乐乐，YouTrack，而不是...

有趣的事情之一是，IBM试图出售这个“集成”，你有多少节省。 。由于这些解决方案如此广泛，有很多很好的解决方案，在那里你可以设置它并且不必碰手指，直到你决定升级到该软件的新版本。除了所谓的“管理员所节省的时间”之外，还有十倍的时间让他们跑来跑去，帮助理清RTC似乎带来的许多问题。

所以我会建议针对RTC。而Github，Codeplex，Bitbucket等已经证明Git，SVN等事实上确实在规模上......