为什么要收购 Harvest？
您的工作环境使用 Harvest SCM 吗？ 我现在在两个不同的地方使用过它，发现它令人震惊。 在一种情况下，我编写了一个转换脚本，这样我就可以在本地使用 CVS，然后每天在睡觉时将更改导入 Harvest 系统。 该公司对使用 Harvest 非常热衷，尽管 80% 的程序员都渴望使用不同的东西。 这是不必要的复杂、缓慢和沉重。 现在对我来说，工作要求是我工作的地方不使用 Harvest。
有其他人使用过 Harvest 吗？ 你的经验是什么？ 和我一样糟糕吗？ 您是否采用了其他不同的解决方法？ 为什么今天仍然购买该产品？
Does your work environment use Harvest SCM? I've used this now at two different locations and find it appalling. In one situation I wrote a conversion script so I could use CVS locally and then daily import changes to the Harvest system while I was sleeping. The corp was fanatic about using Harvest, despite 80% of the programmers crying for something different. It was needlessly complicated, slow and heavy. It is now a job requirement for me that Harvest is not in use where I work.
Has anyone else used Harvest before? What's your experience? As bad as mine? Did you employ other, different workarounds? Why is this product still purchased today?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您的公司很可能与 CA 签订了某种合同 - 您是否在内部使用许多其他 CA 软件？
编辑：你猜是这样！
Chances are, your company has some sort of contract with CA - are you using a lot of other CA software in-house?
Edit: Guess so!
好吧，我将在几集中回答这个问题，因为现在已经很晚了，而收获是一个大话题。
首先，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 实际工作方式的内容 - 存储库、项目、视图、包、表单、流程等。这可能有助于解释为什么有些组织使用它，以及为什么它不适合所有人。
OK I'm going to answer this in a couple of episodes because its late here and Harvest is a big topic.
Firstly CA Harvest (which is what version 7 of the product is called, version 5 is CCC which I cant recall the expansion, version 12 is called CA SCM) is a lot more than just a SCM tool - in the same way ClearCase is a lot more than an SCM tool. SVN, CVS, git, hg are all base-standard SCM and little more.
What you get with Harvest is SCM + Policy. It gives you a place to store and version your code and wrap it all in a policy of how that code matures though your organization from dev to prod. Do you have a policy in your organization that a Lead Developer needs to sign off on the code before its released to QA ? Harvest allows you define the signoff as a policy, and enforces it - you cant migrate the code from the "Dev" state to the "QA" state until one of the people in the project designated as a Lead Dev does exactly that. Do you have a policy that any SQL code needs signoff by a DBA before it progresses ? Harvest allows you to define that policy, and enforces it - so you might need both Lead Dev and DBA signoff before code migrates.
Harvest is by no means a tool for most software organizations - it is typically used in the finance industry, or in business' where a very strong regulatory framework governs what they can do. Banks need to comply with Sarbannes-Oxley, which has very strong auditing requirements. Harvest provides the ability to define all kinds of controls and process around how changes to the Banks assets move through their lifecycle. I know large public transport organizations that are responsible for the safety and punctuality of millions of people every day, that need the tightly defined control mechanisms that a tool like Harvest provides. I also have seen Harvest used in environments where 1000's of developers use it everyday - yes, I'm not exaggerating, literally 1000's of devs in one organization, writing code for a worldwide retailer, pushing IT solutions out their door everyday to the stores around the world.
Harvest is not perfect, thought version 12 is much better. It has too many "that's just stupid"-moments, it does per-file versioning ala CVS, and CVS-like branching and directory versioning (or lack thereof), with all the fun we've come to know and fear. Once you know it and accept it though, its isn't inherently slower than any other SCM I've used. It just has a bigger job to do than just version your code.
Another big win, and its even bigger with version 12, is its integration with other CA tool (and ability to integrate with non-CA tools, but not many at the moment) - defect tracking with Quality Centre, trouble ticketing with Unicentre Service Desk, software deployment to the desktop with SDM. You can define bridges between these apps that result in a lot tighter integration of these concerns, with the usually positive effects on accuracy and timeliness.
If your dealing with getting software out to a worldwide enterprise, with thousands of desktops and servers, mainfame/midrange/middleware systems, iron-clad change control processes, complexity, regulations, contracts, auditors, just a whole bunch of complexity, Harvest is just one tool in a whole suite of tools your going to need. If you just want a simple SCM for a team of 10 devs supporting a few hundred customers, its not a great way to go.
I'll try to add something about how Harvest actually works next time - repositories, projects, views, packages, forms, processes etc. That might help explain why some organizations use it, and why its not for everyone.
几年前，我在银行业的一次短期工作中使用了 Harvest。 我同意它实际上无法使用，但负责 QA 的人似乎很喜欢它。
I used Harvest during a short gig in the banking industry a few years ago. I agree that it was practically unusable, but the people in charge of QA seemed to love it.
我在一家有两种选择的公司工作： ClearCase 或 Harves。 Subversion 从未被考虑过，原因是 ClearCase (IBM) 和 Harvest (CA) 都已经拥有长期的大型机合同。
I worked for a company that had two choices; ClearCase or Harvest. Subversion hadn't ever been considered, and the reason was that ClearCase (IBM) and Harvest (CA) both had longstanding mainframe contracts already.
我们已经使用 Harvest 大约十年了（2000-2010），尽管我们现在正在考虑更换它，但我相信它对我们来说非常有用。
Harvest（让我们继续使用这个名称，尽管它不再是它的正式名称）是我们实现的第一个支持我们研发的主要工具，当时我们对应用程序生命周期的许多方面都不太了解（版本控制）代码、分支、自动化测试、回归测试、质量保证、部署到众多运行时环境和生产、回滚、紧急修复、维护更新等）； 今天，我们知道了更多，我们的开发流程为我们提供了很好的服务（并不是说没有很多改进的空间）。
我们没有一个非常等级化的组织（我们没有很多需要批准变更的检查员），但是支持“检查点”非常有帮助 - 开发过程中需要发生某些事情的点（例如功能测试）或集成测试）。
Harvest 在可用性方面的缺点（对我们来说）是“程序员需要做什么来更改 x 行代码”。 今天（那里）有很多比 Harvest 更简单、更有效的方法来获得对源代码文件的写访问权限，进行更新，然后再次返回文件/将它们移至开发过程的另一个方面（测试、部署等） .)。 另一个缺点是价格标签； 它的价格昂贵。
Harvest 的收获：
它支持工作流程，因此我们能够拥有一个系统来管理代码版本控制、工作流程和流程自动化。 如果可能的话，维护和改进单个系统比许多系统更容易。
除了提供对内部进程的命令行访问（使得可以在进程需要时编写特殊解决方案的脚本）之外，Harvest 还可以通过图形界面轻松配置。
它具有“包”的概念，可以轻松地将大量元数据附加到代码更改并独立于其他更改处理更改（文件级别的版本控制而不是包含完整代码量的更改集）。 这有助于处理独立的紧急情况和维护变更。
如果开发人员只是一名程序员并且只考虑软件开发的编码方面，那么我想他/她可能会对 Harvest 感到非常沮丧。
如果开发人员就是开发人员，并且了解软件开发不仅仅是编码，并且编码只是软件生命周期的开始，那么我相信他会从 Harvest 中看到很多好处。
We've used Harvest for about ten years (2000-2010) and even though we are now looking at replacing it I believe it has served us very well.
Harvest (let's stick with that name even though it's no longer it's official name), was the first major tool we implemented to support us in R&D and at the time none uf us knew much about the many aspects of application lifecycle (versioning of code, branching, automated testing, regression testing, quality assurance, deployment to numerous runtime environments and production, rollback, ememrgency fixes, maintenance updates etc.); today we know a lot more and our development processes serve us very well (not that there is not room for many improvements).
We do not have a very hierarchical organisation (we don't have a lot of inspectors that need to approve changes) but it's very helpful to have support for "checkpoints" - points in the development process where something need to happen (e.g. functional testing or integration testing).
The drawback (for us) with Harvest in regards to usability has been "what a programmer need to do to change x lines of code". Today (out there) there are a lot of easier and more efficient ways than Harvest to get write access to source code files, make your updates and then return the files again / move them to another aspect of the development process (testing,deployment etc.). Another drawback is the price tag; it's expensive.
Gain we've had with Harvest:
It support workflow and therefore we've been able to have a single system to manage code versioning, workflow and process automation. If possible it's easier to maintain and improve a single system than many.
In addition to providing cmd line access to internal processes (making it possible to script special solutions when so required by your processes) Harvest also is easily configured by graphic interface.
It has the concept of "Package" which makes it easy to attach plenty of meta data to code changes and to handle the changes independently of other changes (versioning on file level rather than change sets containing the complete code mass). This is helpful to handle indpendent emergency and maintenance changes.
If a developer is only a programmer and only think on the coding aspect of software development then I imagen he/she would might get very frustrated with Harvest.
If a developer is a developer and understand that software development is a lot more than coding and that the coding is only the very begining of a the lifecycle of software then I belive he would see a lot of benefits with Harvest.
过去 4 年我一直在使用 HARVEST，我很喜欢它。 它为您提供控制代码移动的支持真是太棒了。 我们使用 HARVEST 将应用程序部署到 Websphere 上。 它还在将插件与应用程序一起部署到 Web 服务器方面做了出色的工作。 当您想要在大型企业环境中移动代码的流程时，我认为没有任何其他工具可以更接近 HARVEST。
I have been using HARVEST for the last 4 years and i love it. The kind of support it gives you to control the code movement is really fantastic. We use HARVEST to deploy applications on to Websphere. It also do an amazing work in deploying the plugins into the web server along with the application. When you want to have a process in place for moving the code in a big enterprise environment, i don't think any other tool can even come closer to HARVEST.
我在银行使用 Harvest 的好处是，你再也找不到比这更糟糕的败类和邪恶蜂巢了，向后三叉无证登记的挑战，需要 15 个步骤才能进行一个简单的更改。 别介意他们甚至没有使用分支。 这是一个邪恶的工具，不要让它让你落入它的魔爪。
I had the benefit of using Harvest at a bank and you'll never find a more wretched hive of scum and villainy, backwards triple-forking undocumented check-in gauntlets that require 15 steps to make one simple change. Nevermind that they weren't even using branching. This is an evil tool don't let it get you in its clutches.