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

Question

您的工作环境使用 Harvest SCM 吗？我现在在两个不同的地方使用过它，发现它令人震惊。在一种情况下，我编写了一个转换脚本，这样我就可以在本地使用 CVS，然后每天在睡觉时将更改导入 Harvest 系统。该公司对使用 Harvest 非常热衷，尽管 80% 的程序员都渴望使用不同的东西。这是不必要的复杂、缓慢和沉重。现在对我来说，工作要求是在我工作的地方不使用 Harvest。

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

Answer 1

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

编辑： 我猜也是！

Answer 2

我在银行使用 Harvest 的好处是，你再也找不到比这更糟糕的败类和邪恶蜂巢了，向后三叉无证登记的挑战，需要 15 个步骤才能进行一个简单的更改。别介意他们甚至没有使用分支。这是一个邪恶的工具，不要让它让你落入它的魔爪。

Answer 3

好吧，我将在几集中回答这个问题，因为现在已经很晚了，而收获是一个大话题。

首先，CA Harvest（该产品的第 7 版被称为，第 5 版是 CCC，我不记得它的扩展，第 12 版被称为 CA SCM）不仅仅是一个 SCM 工具 - 同样，ClearCase 也是一个不仅仅是一个 SCM 工具。SVN、CVS、git、hg 都是基本标准的 SCM，仅此而已。

Harvest 为您带来的是 SCM + 策略。它为您提供了一个存储和版本化代码的地方，并将其全部包装在代码如何在您的组织中从开发到产品成熟的策略中。您的组织中是否有规定首席开发人员需要在代码发布给 QA 之前签署代码？Harvest 允许您将签核定义为一项策略，并强制执行它 - 您无法将代码从“开发”状态迁移到“QA”状态，直到项目中指定为首席开发人员之一完全执行此操作。您是否有规定任何 SQL 代码在执行之前都需要由 DBA 签署？Harvest 允许您定义该策略并强制执行 - 因此在代码迁移之前您可能需要首席开发人员和 DBA 签署。

Harvest 绝不是大多数软件组织的工具 - 它通常用于金融行业或商业领域，在这些行业中，有非常强大的监管框架来管理他们的行为。银行需要遵守萨班斯-奥克斯利法案，该法案具有非常严格的审计要求。Harvest 能够围绕银行资产在其生命周期中的变化方式定义各种控制和流程。我知道大型公共交通组织每天负责数百万人的安全和准时，需要像 Harvest 这样的工具提供的严格定义的控制机制。我还看到 Harvest 在有 1000 名开发人员每天使用它的环境中使用 - 是的，我没有夸张，实际上一个组织中有 1000 名开发人员，为一家全球零售商编写代码，每天向周围的商店推出 IT 解决方案世界。

收获并不完美，觉得12版好多了。它有太多“这太愚蠢了”的时刻，它像 CVS 一样对每个文件进行版本控制，以及类似 CVS 的分支和目录版本控制（或缺乏），以及我们所知道和恐惧的所有乐趣。一旦您了解并接受它，它本质上并不比我使用过的任何其他 SCM 慢。它有更重要的工作要做，而不仅仅是对代码进行版本控制。

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

如果您要向一家全球性企业提供软件，该企业拥有数千台台式机和服务器、知名/中端/中间件系统、铁定的变更控制流程、复杂性、法规、合同、审计员，只是一大堆复杂性，那么 Harvest 就是您的最佳选择。只是您需要的一整套工具中的一个工具。如果您只是想要一个简单的 SCM，供 10 名开发人员组成的团队支持几百个客户，那么这不是一个好方法。

下次我会尝试添加一些关于 Harvest 实际工作方式的内容 - 存储库、项目、视图、包、表单、流程等。这可能有助于解释为什么有些组织使用它，以及为什么它并不适合所有人。

Answer 4

几年前，我在银行业的一次短期工作中使用了 Harvest。我同意它实际上无法使用，但负责 QA 的人似乎很喜欢它。

Answer 5

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

Answer 6

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

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

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

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

Answer 7

过去 4 年我一直在使用 HARVEST，我很喜欢它。它为您提供控制代码移动的支持真是太棒了。我们使用 HARVEST 将应用程序部署到 Websphere 上。它还在将插件与应用程序一起部署到 Web 服务器方面做了出色的工作。当您想要在大型企业环境中移动代码的流程时，我认为没有任何其他工具可以更接近 Harvest。