为什么要收购Harvest呢？ [关闭]

Question

您的工作环境是否使用Harvest SCM？ 我现在已经在两个不同的地方使用它，发现它令人震惊。 在一种情况下，我编写了一个转换脚本，因此我可以在本地使用CVS，然后在我睡觉时每天将更改导入Harvest系统。 尽管有80％的程序员在为不同的东西而哭泣，但该公司仍对使用Harvest感到狂热。 这是不必要的复杂，缓慢和沉重。 现在，我的工作要求就是在我工作的地方没有使用Harvest。

还有其他人之前使用过Harvest吗？ 你有什么经历？ 和我一样糟糕？ 您是否采用了其他不同的解决方法？ 为什么今天仍然购买此产品？

Answer 1

我有幸在银行使用Harvest，你永远不会找到一个更加可怜的浮渣和恶意蜂巢，向后三重分叉的无证登记手套，需要15个步骤才能做出一个简单的改变。 没关系，他们甚至没有使用分支。 这是一个邪恶的工具，不要让它让你陷入其中。

Answer 2

您的公司可能与CA签订了某种合同 - 您是否在内部使用了许多其他CA软件？

编辑：猜猜看！

Answer 3

好吧，我将在几集中回答这个问题，因为它在这里已经很晚了，而Harvest正是一个很大的话题。

首先是CA Harvest（该产品的第7版称为版本5，版本5是CCC，我不记得扩展，版本12称为CA SCM）不仅仅是一个SCM工具 - 就像ClearCase是一样的不仅仅是一个SCM工具。 SVN，CVS，git，hg都是基本标准的SCM，而且更多。

您从Harvest获得的是SCM +政策。 它为您提供了一个存储和编写代码的地方，并将其全部包含在一个策略中，该策略说明了您的组织从开发到生产时该代码的成熟程度。 您的组织中是否有一项政策要求首席开发人员在将代码发布到QA之前需要签署代码？ Harvest允许您将签收定义为策略，并强制执行 - 您无法将代码从“Dev”状态迁移到“QA”状态，直到项目中指定为Lead Dev的人员完全执行此操作。 你有一个策略，任何SQL代码需要在DBA进展之前签署吗？ Harvest允许您定义该策略并强制执行 - 因此在代码迁移之前您可能需要Lead Dev和DBA签收。

对于大多数软件组织来说，收获绝不是一种工具 - 它通常用于金融行业，或者用于商业领域，在这种行业中，一个非常强大的监管框架决定了他们能做些什么。 银行需要遵守Sarbannes-Oxley，它具有非常强大的审计要求。 Harvest提供了定义各种控制的能力，并处理银行资产变化在其生命周期中的变化。 我知道大型公共交通组织每天都要负责数百万人的安全和准时，这需要像Harvest这样的工具提供严格定义的控制机制。 我也看到Harvest在1000个开发人员每天都使用它的环境中使用 - 是的，我并不夸张，一个组织中的1000个开发人员，为全球零售商编写代码，每天都将IT解决方案推到他们的门外世界。

收获并不完美，认为第12版要好得多。 它有太多“那只是愚蠢的” - 时刻，它对CVS进行逐文件版本控制，以及类似CVS的分支和目录版本控制（或缺少它），以及我们已经了解和担心的所有乐趣。 一旦你知道它并接受它，它本身并不比我使用的任何其他SCM慢。 它只是比你的代码版本更大的工作。

另一个重大胜利，即版本12更大，是它与其他CA工具的集成（以及与非CA工具集成的能力，但目前并不多） - 使用Quality Center进行缺陷跟踪，使用Unicentre Service Desk进行故障排序，使用SDM将软件部署到桌面。 您可以在这些应用程序之间定义桥梁，从而更加紧密地整合这些问题，通常会对准确性和及时性产生积极影响。

如果您要将软件交给全球企业，包括数千个台式机和服务器，主要/中端/中间件系统，铁板式变更控制流程，复杂性，法规，合同，审计员，只需要一大堆复杂性，Harvest就是只是您需要的一整套工具中的一个工具。 如果你只想为一个支持几百个客户的10个开发团队提供一个简单的SCM，那么这不是一个好方法。

我将尝试添加一些关于Harvest实际上如何工作的东西 - 存储库，项目，视图，包，表单，流程等。这可能有助于解释为什么有些组织使用它，以及为什么它不适合所有人。

Answer 4

几年前，我在银行业的一次短暂演出中使用了Harvest。 我同意它实际上无法使用，但负责质量保证的人似乎喜欢它。

Answer 5

我曾在一家有两种选择的公司工作过; ClearCase或Harvest。 Subversion从未被考虑过，原因是ClearCase（IBM）和Harvest（CA）已经拥有长期的大型机合同。

Answer 6

我们已经使用Harvest大约十年（2000-2010），尽管我们现在正在考虑更换它，但我相信它对我们有很好的帮助。 收获（让我们坚持使用这个名称，即使它不再是它的官方名称），是我们为研发提供支持的第一个主要工具，当时我们都不了解应用程序生命周期的许多方面（代码的版本控制，分支，自动化测试，回归测试，质量保证，部署到众多运行时环境和生产，回滚，维护修复，维护更新等）; 今天我们知道的更多，我们的开发过程非常好（不是没有很多改进的余地）。 我们没有一个非常分层的组织（我们没有很多需要批准变更的检查员）但是对“检查点”的支持非常有帮助 - 在开发过程中需要发生某些事情的点（例如功能测试）或集成测试）。

Harvest在可用性方面的缺点（对我们而言）是“程序员需要做的改变x行代码的事情”。 今天（那里）有很多比Harvest更简单，更有效的方法来获取源代码文件的写入权限，进行更新，然后再次返回文件/将它们移动到开发过程的另一个方面（测试，部署等） ）。 另一个缺点是价格标签; 它的价格昂贵。

我们收获了Harvest：它支持工作流程，因此我们能够拥有一个系统来管理代码版本控制，工作流程和流程自动化。 如果可能的话，维护和改进单个系统比许多系统更容易。 除了提供对内部流程的cmd行访问（使您可以在流程需要时编写特殊解决方案的脚本）还可以通过图形界面轻松配置Harvest。 它具有“包”的概念，这使得很容易将大量元数据附加到代码更改并独立于其他更改处理更改（在文件级别上进行版本控制而不是包含完整代码质量的更改集）。 这有助于处理相关的紧急和维护变更。

如果一个开发人员只是一个程序员，只考虑软件开发的编码方面，那么我想他/她可能会对Harvest感到非常沮丧。 如果开发人员是开发人员并且了解软件开发不仅仅是编码，而且编码只是软件生命周期的开始，那么我相信他会看到Harvest带来很多好处。

Answer 7

过去4年我一直在使用HARVEST，我喜欢它。 它让你控制代码运动的支持非常棒。 我们使用HARVEST将应用程序部署到Websphere。 在将插件与应用程序一起部署到Web服务器中时，它也做了惊人的工作。 如果您希望有一个流程来在大型企业环境中移动代码，我认为任何其他工具都不能接近HARVEST。