25

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?

Dean J
  • 39,360
  • 16
  • 67
  • 93
Mike Caron
  • 5,674
  • 4
  • 48
  • 71
  • 9
    Amusingly, the only answers I can see spinning Harvest in a positive light come from accounts with 0 activity elsewhere. – Kirschstein Jul 04 '12 at 08:22

7 Answers7

26

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.

24

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!

Greg Hurlman
  • 17,666
  • 6
  • 54
  • 86
  • I agree. In both places where Harvest was forced down my throat, they had existing contracts with CA for mainframe software. Maybe they created a price point and support contract that was too good financially. That being the case, there must not have been any analysis into the cost of keeping Harvest because there is considerable overhead using the product. – Mike Caron Jun 17 '09 at 16:50
15

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.

user229044
  • 232,980
  • 40
  • 330
  • 338
leriksen
  • 151
  • 1
  • 2
  • 3
    It strikes me that the reason SVN/CVS/git don't enforce policy is that it isn't the job of the SCM to enforce policy. Their developers follow the "do one thing and do it well" paradigm, preferring to be a link in a chain of tools rather than attempting to be an end-to-end solution. – user229044 May 19 '10 at 13:30
  • 6
    Welcome, even late. The problem is that Harvest (7, 12, and others) all focus on the deployment policy, not on SCM. It's *not* a competent SCM for medium or large projects; you'd be saving tons of developer hours by using subversion, and copying ready-to-push labels out of subversion to Harvest to be deployed. Harvest is a Deployment tool, not a source control tool. The direct parallel might be comparing Harvest to Clearquest, which is the deployment control sibling to Clearcase. – Dean J May 19 '10 at 14:15
  • Sounds like Harvest's main functionality is easy authoring of commit-hooks to enforce business workflow logic. Like you could write a small commit hook script to only accept commits to specific branches if those commits have a signed tag from specific people. However in git that is all "edit a python file with vi" as opposed to "run some GUI and modify example 12 from the book a but..."? (I'm not knocking it, making specific important-to-someone use cases easy is significant ...at least to anyone that lives and dies by those use cases at least) – Stripes Nov 24 '11 at 02:01
  • @leriksen - a Harvest/CA-SCM HOWTO would be quite a useful document. Want to write one up? – ConcernedOfTunbridgeWells May 23 '12 at 11:52
  • Yeah I'm calling BS on this excuse. I worked for the biggest bank in America and we used TFS, IN the group that enforces those policies you're talking about. As we all know, it also supports lifecycle tools, build servers, compliance rules, and all that jazz, WAY better than Harvest ever could, even if it worked right. – Jasmine Sep 26 '17 at 23:33
6

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.

Kristopher Johnson
  • 81,409
  • 55
  • 245
  • 302
5

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.

Dean J
  • 39,360
  • 16
  • 67
  • 93
3

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.

-12

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.