Что может сделать FishEye, чего мы не можем получить от других инструментов для git-репозитория?
Мы выбрали Jira и Confluence и теперь рассматриваем другие инструменты Atlassian, которые могут сделать нашу жизнь проще.
Я понимаю, что FishEye допускает все виды визуализации хранилища исходного кода, чего нет у нативного инструментария для CVS. Мы, однако, перешли на git, который имеет обширную экосистему очень полезных инструментов.
Вопрос: может ли FishEye рассказать нам что-то полезное, чего мы не можем получить от нативных инструментов? (Или коммерческие инструменты по конкурентной цене)?
8 ответов
Лично мне нравится Fisheye, но в нем есть среда разработки среднего размера и полусложная стратегия ветвления / развития, где мониторинг текущего состояния репо был довольно важным.
На моей последней работе нашим основным продуктом была линейка серверных Java-продуктов SaaS на стороне сервера, где все биллинги и системная интеграция обрабатывались на месте. Хотя большинство людей были хакерами Emacs / командной строки, мы по-прежнему использовали Fisheye поверх всех наших основных продуктов.
Предостережения
- Это было с SVN, а не с мерзавцем / ртутью, так что возьми это с крошкой соли.
- Были и другие хуки SVN, которые были встроены в Bugzilla, и я не уверен на 100%, как они работают.
Перетасованные инженеры, работавшие над продуктами, у которых не было Fisheye, обычно были недовольны по следующим причинам:
Рефакторинг Обычно вы перемещаете файлы, переименовываете, объединяете связанные изменения и тому подобное. Поиск Fisheye по базовому имени вернет файлы, которые были давно удалены с сохранением их истории, поэтому даже если вы испортили историю в репо, у вас есть представление о предыдущих изменениях. Для кодовой базы, которая переживала очень реальные проблемы роста из-за внезапного расширения компании, это было огромной помощью
Владение кодом / проверка кода Даже без активного процесса владения кодом / проверки кода вы можете подписаться на определенные изменения проекта / репо с помощью Fisheye. Для руководителей групп и т. Д. Это очень простой способ оставаться в курсе того, что делают другие люди, когда они меняют вещи и почему, хотите ли вы получать спам по электронной почте или настроить RSS-канал для репо. Если вы управляете несколькими проектами одновременно, это может иметь большое значение. У меня был настроен канал RSS для моего первого крупного проекта, чтобы я мог видеть, как он меняется, но реальное преимущество заключается в том, чтобы отслеживать связанные с API проекты по мере их изменения
Можно использовать Не все наши инженеры являются хакерами командной строки. Это особенно актуально для некоторых разработчиков внешнего интерфейса, которые занимались HTML/CSS. Столько, сколько кто-то склонен прибегать к инструментам командной строки, когда это возможно, выполняя разовые тестовые файлы и "Кто отменил мои изменения и когда?" проще работать с инструментами сравнения в браузере, чем делать svn blame и тому подобное.
Все это говорит, я скажу, что если бы я занимался разработкой с нуля, я бы вообще не трогал его, если бы мне не требовалась визуализация всего проекта, а не конкретного файла или двух, время от времени, что, вероятно, означает следующее:
- Размер моей группы составляет около 10+ инженеров потенциально нетехнического происхождения и нуждается в реорганизации в соответствии со специальной стратегией.
- Ветвление / тегирование удовлетворяет ряду конкретных потребностей так же, как и общее управление версиями.
- Право собственности на код и его пересмотр получают как минимум слабо навязанную идею, а не жесткую позицию против нее из-за ограниченности ресурсов
- Общение между инженерами является растущей проблемой (будь то явный шум или его отсутствие). Это включает в себя случайный разговор с прямой документацией
Я также игнорирую любую интеграцию аналитики / инструментов. Частично потому, что я полагаю, что если вы сравниваете Fisheye с чем-то еще, вам также следует посмотреть, сколько дополнительной работы потребуется, чтобы сохранить Fisheye по сравнению с другим решением или использовать его, но также потому, что я никогда не работал с более чем один продукт Atlassian за один раз.
В вашей ситуации я бы также посмотрел на интеграционные части Jira/Fisheye и посмотрел, нужен ли вам этот набор функций в данный момент (или вообще необходим) при рассмотрении других коммерческих вариантов.
Одним из основных преимуществ, которые мы получаем от использования FishEye, является наложение на Crucible поверх него, облегчающее удаленный анализ кода.
Мы отказались от использования FishEye, потому что это было медленно и громоздко на наших ограниченных серверах. Намного счастливее использовать JIRA вместе с Git на GitHub. Некоторые из функций визуализации, которые рекламирует FishEye, также не поддерживаются в Git. Я большой поклонник Atlassian, я просто думаю, что FishEye не один из их лучших инструментов для работы с Git.
Мне очень нравится интеграция между рыбьим глазом и Джирой. Связать ваши проекты в jira с вашим хранилищем в fisheye - это здорово. Вы получаете вкладку "источник" в jira. Затем, когда вы фиксируете с идентификатором ошибки / задачи в комментарии к коммиту, файлы из коммита появляются на вкладке источника в jira, и вы можете просто просмотреть, что именно изменилось в коммите для этой ошибки / задачи. По общему признанию, я только сделал это на SVN, таким образом я не могу сказать наверняка, работает ли это с git, но это стоило бы исследовать.
Еще одна интересная особенность заключается в том, что вы можете создать дефект jira из обзора тигля. Я могу выделить ошибочную строку кода, создать дефект, и тогда создатель получит предупреждение, если будут обнаружены нерешенные ошибки, связанные с обзором, когда они пытаются подвести итог / закрыть обзор.
Работая в 100% удаленной команде, я считаю, что Crucible на рыбьем глазу неоценим для анализа кода.
Обновление 2018: Stash теперь называется сервером BitBucket...
Обновление январь 2013: теперь он называется Stash.
(см. комментарий sendmoreinfo)
Оригинальный ответ февраль 2012:
С FishEye2.7 вы можете не только получить доступ к удаленному репо, но и создать на сервере FishEye новое Git репо.
См. " Страницу руководства FishEye", " Создание Git-репозитория" и " Включение управления репозиторием в FishEye".
В блоге " FishEye на практике: настройка собственных репозиториев Git" также представлена эта функция, в которой перечислены цели этой функции:
- Разрешить предприятиям получать или мигрировать в репозитории Git за своим брандмауэром
- Упростите настройку разрешений для репозиториев для команд
Это означает, что FishEye будет использовать уровень доступа (например, сервер Apache, на котором запущен FishEye) для внутреннего доступа к репозиторию Git.
Он также обеспечит базовый механизм авторизации, что означает, что вам не нужно настраивать отдельную инфраструктуру, такую как Apache+Gitolite, для управления внутренними репозиториями: вы можете напрямую использовать сервер FishEye.
FishEye предоставляет удобный язык запросов EyeQL https://confluence.atlassian.com/fisheye041/eyeql-reference-guide-847745659.html .
FishEye может выполнять текстовый поиск в нескольких репозиториях и возвращать результаты с учетом контекста.
Есть две вещи, которые Fisheye+Crucible дает моей команде, которых, похоже, не хватает в других профессиональных инструментах для проверки кода:
- Возможность объединять наборы изменений из более чем одного репозитория в один обзор кода. Поскольку наши проекты охватывают несколько репозиториев, полное изменение может включать изменения в репозиториях. Наличие всех изменений в репозиториях, доступных для просмотра в одном обзоре кода, действительно помогает получить полную картину влияния на продукт.
- Возможность загружать и прикреплять файлы. Особенно в случае изменений в элементах пользовательского интерфейса, было бы здорово иметь скриншоты изменений, прикрепленные к обзорам кода. Рецензентам также было полезно иметь справочные документы, прикрепленные к обзорам кода.
Для меня интересно то, что я могу быстро выяснить, какие коммиты связаны с проблемой. Это будет частью самой JIRA.
Поэтому, если я сообщу об ошибке в проекте, над которым я не работаю напрямую, я могу проверить, насколько исправление, как и следовало ожидать, без клонирования проекта, а затем выполнить поиск в журнале истории коммитов.
Это также вынуждает разработчиков размещать теги проблем в их сообщении о коммите.
Обзор кода тоже приятно иметь, но до сих пор мы редко его используем.