What can FishEye do that we cannot get from other tools for a git repository?
We have decided on Jira and Confluence and are now looking at other Atlassian tools that may make our lives easier.
I understand that FishEye allows all kinds of visualization of a source code repository that the native tooling for CVS does not. We have, however, migrated to git, which has a large ecosystem of very useful tools.
Question is: Can FishEye tell us something useful we cannot get from the native tools? (Or commercial tools at a competitive price)?
Answer
Personally I like Fisheye, but that's given a medium-sized dev environment and a semi-complex branching/development strategy where monitoring the current state of the repo was pretty important.
At my last job our major product was a line of server-side Java, white-boxed SaaS products where all of the billing and system integration was handled in house. Although most people were Emacs/command-line hackers, we still used Fisheye on top of all of our major product lines.
Caveats
- This was with SVN, not git/hg, so take this with a grain of salt.
- There were other SVN hooks that were built in involving Bugzilla that I'm not 100% sure on how they worked
Reshuffled engineers working on products that did not have Fisheye were typically unhappy for the following reasons:
Refactoring Typically you're moving files around, renaming, merging related changes and the like. Fisheye's search by base name will return files that have been long since deleted with their history maintained, so even if you mess up the history in the repo, you have a sense of what the previous changes were. For a code base that was experiencing some very real growing pains from a sudden expansion to the company, this was a huge help
Code Ownership/Review Even without a robust code-ownership/review process, you can opt-in to particular project/repo changes with Fisheye. For team leads and the like, it's a very simple way to stay on top of what other people are doing when they are changing things and why, whether you want to receive email spam or set up an RSS feed for the repo. If you're managing multiple projects at once, that could be a big deal. I had an RSS feed set up for my first major project so I could see how it was changing, but the real benefit is to monitor API-related projects as they change
Usable Not all of our engineers are command-line hackers. This is particularly true for some of the frontend engineers that handled HTML/CSS. As much as some people tend to fall-back on command line tools when possible, performing the run-of-the-mill file diffs and 'Who reverted my change and when?' it is easier to handle in-browser diff tools than doing 'svn blame' and the like.
All that said, I will say that if I were doing a dev shop from the ground up, I wouldn't touch it at all unless I needed visualization of the full project rather than a specific file or two every now and again, which probably means the following things are true:
- The size of my group hit roughly around 10+ engineers of potentially non-technical backgrounds and is in need or reorganization from an ad hoc strategy
- Branching/tagging serves a number particular needs as much as it does general versioning
- Code ownership and review gaining traction as a loosely enforced idea at a minimum rather than a hardline stance against it because of resource contraints
- Communication among the engineers is an increasing issue (whether it is sheer noise, or lack of it). This includes casual conversation to straight documentation
I'm ignoring any analytics/tools integration as well. Partly because I assume that if you're comparing Fisheye to anything else, you should also be looking at how much extra work it would be to maintain Fisheye vs. another solution vs. winging it, but also because I have never worked with more than one Atlassian product at a time.
In your situation, I would also look at the Jira/Fisheye integration parts and see if that a feature set you need at the moment (or at all) when looking at other commercial options.