我们已经决定使用 Jira 和 Confluence，现在正在寻找其他 Atlassian 工具，它们可能会让我们的生活更轻松。
我知道 FishEye 允许对源代码存储库进行各种可视化，而 CVS 的本机工具则不能。然而，我们已经迁移到 git，它拥有一个由非常有用的工具组成的庞大生态系统。
问题是：FishEye 能否告诉我们一些我们无法从原生工具中获得的有用信息？（或具有竞争力价格的商业工具）？
问问题
10819 次
7 回答
11
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.
于 2012-02-01T21:28:04.057 回答
5
我们从使用 FishEye 获得的主要好处之一是在 Crucible 上分层，便于远程代码审查。
于 2012-01-17T14:22:27.433 回答
4
I really like the integration between fisheye and Jira. Having your projects in jira linked to your repository in fisheye is awesome. You get the "source" tab in jira. Then when you commit with the bug/task id in the commit comment, the files from the commit show up in the source tab in jira and you can just click through to see exactly what changed in the commit for that bug/task. Admittedly I've only done that on SVN, so I can't say for certain if it works with git, but it would be worth investigating.
Another cool feature is that you can create a jira defect from within the crucible review. I can highlight the offending line of code, create the defect, and then the creator gets a warning if there are unresolved bugs related to the review when they try to summarize/close the review.
Working on a 100% remote team, I find Crucible on fisheye to be invaluable for code reviews.
于 2012-02-04T21:21:38.697 回答
4
我们不再使用 FishEye，因为它在我们有限的服务器上运行缓慢且体积庞大。在 GitHub 上使用 JIRA 和 Git 会更快乐。FishEye 吹捧的一些可视化功能在 Git 中也不受支持。我是 Atlassian 的忠实粉丝，我只是认为 FishEye 不是他们用于 Git 工作的最佳工具之一。
于 2012-02-01T20:37:58.277 回答
3
2018 年更新：Stash 现在称为BitBucket 服务器...
2013 年 1 月更新：现在称为Stash。
（见sendmoreinfo的评论）
2012 年 2 月的原始答案：
从 FishEye2.7 开始，您不仅可以访问远程仓库，还可以在 FishEye 服务器中创建新的 Git 仓库。
请参阅“ FishEye 手册页”、“创建 Git 存储库”和“在 FishEye 中启用存储库管理”。
博客文章“实践中的 FishEye：设置您自己的 Git 存储库”也介绍了该功能，并列出了该功能的目标：
- 允许企业获取或迁移到防火墙后面的 Git 存储库
- 轻松为团队配置存储库权限
这意味着 FishEye 将利用访问层（例如运行 FishEye 的 Apache 服务器）进行内部 Git 存储库访问。
它还将提供基本的授权机制，这意味着您不必像另一个 Apache+Gitolite 那样设置单独的基础设施来管理内部存储库：您可以直接使用 FishEye 服务器。
于 2012-01-17T15:18:56.027 回答
1
Fisheye+Crucible 为我的团队提供了其他专业代码审查工具似乎缺乏的两件事：
- 将来自多个存储库的变更集组合到一个代码审查中的能力。由于我们的项目跨越多个存储库，完整的更改可能包括跨存储库的更改。在一次代码审查中可以审查跨存储库的所有更改确实有助于全面了解对产品的影响。
- 上传和附加文件的能力。尤其是对 UI 元素的更改，将更改的屏幕截图附在代码审查中是很棒的。将参考文档附加到代码审查中对审查人员也很有帮助。
于 2022-01-21T14:29:10.227 回答
0
对我来说，有趣的部分是我可以快速找出与问题相关的提交。它将成为 JIRA 本身的一部分。
因此，如果我报告了我不直接从事的项目的错误，我可以检查修复的情况，而无需克隆项目，然后搜索提交历史日志。
它还迫使开发人员将问题标签放在他们的提交消息中。
代码审查也很不错，但到目前为止我们并没有经常使用它。
于 2012-02-06T20:10:49.360 回答