Что может сделать FishEye, что мы не можем получить из других инструментов для репозитория git?

Ответ 1

Лично мне нравится Fisheye, но для среды среднего размера и полукомплексной стратегии ветвления/развития, где мониторинг текущего состояния репо был очень важен.

На моей последней работе нашим основным продуктом была линейка серверных Java-приложений с белым ящиком SaaS, где все биллинг и системная интеграция обрабатывались в доме. Хотя большинство людей были хакерами Emacs/командной строки, мы по-прежнему использовали Fisheye поверх всех наших основных продуктов.

Предостережения

• Это было с SVN, а не git/hg, поэтому возьмите это с солью.
• Были и другие SVN-крючки, которые были созданы с участием Bugzilla, что я не уверен на 100%, как они работали.

Перетасованные инженеры, работающие над продуктами, которые не имели Fisheye, обычно были недовольны по следующим причинам:

• Рефакторинг. Обычно вы перемещаете файлы, переименование, слияние связанных изменений и т.п. Поиск рыбий глаз по базовому имени будет возвращать файлы, которые были давно удалены с сохраненной историей, поэтому, даже если вы испортили историю в репо, у вас есть представление о том, что было в предыдущих изменениях. Для базы кодов, которая испытывала некоторые очень сильные боли от внезапного расширения компании, это было огромной помощью

• Собственность/обзор кода Даже без надежного процесса владения/просмотра кода вы можете отказаться от конкретных изменений проекта/репо с помощью Fisheye. Для лидеров команды и т.п. Это очень простой способ остаться на вершине того, что делают другие люди, когда они меняют вещи и почему, хотите ли вы получать спам по электронной почте или настроить канал RSS для репо. Если вы управляете несколькими проектами одновременно, это может быть большой проблемой. У меня была RSS-лента, настроенная для моего первого крупного проекта, поэтому я мог видеть, как он меняется, но реальная выгода заключается в мониторинге проектов, связанных с API, поскольку они меняют

• Полезно Не все наши инженеры являются хакерами из командной строки. Это особенно верно для некоторых инженеров-фронтэндов, которые обрабатывают HTML/CSS. Насколько возможно, некоторые люди склонны отказываться от инструментов командной строки, когда это возможно, выполняя разворачиваемый файл, и "Кто изменил мои изменения и когда?" проще работать с инструментами разметки в браузере, чем делать "svn blame" и т.п.

Все, что сказал, я скажу, что если бы я делал Dev-магазин с нуля, я бы не стал касаться его вообще, если мне не понадобилось визуализировать полный проект, а не конкретный файл или два каждый раз и снова, что, вероятно, означает, что верно следующее:

• Размер моей группы приблизился примерно к 10 инженерам потенциально нетехнического происхождения и нуждается в реорганизации из специальной стратегии
• Ветвление/тегирование выполняет ряд конкретных потребностей, а также общее управление версиями
• Соблюдение и обзор кода, приобретая тягу как слабозанятую идею как минимум, а не жесткую позицию против нее из-за ограничений ресурсов
• Коммуникация между инженерами - это растущая проблема (будь то чистый шум или ее отсутствие). Это включает случайный разговор с прямой документацией.

Я игнорирую интеграцию аналитики и инструментов. Отчасти потому, что я предполагаю, что если вы сравниваете Fisheye с чем-либо еще, вы также должны посмотреть, сколько дополнительной работы было бы поддерживать Fisheye против другого решения или против него, но также потому, что я никогда не работал с более чем один атласский продукт за раз.

В вашей ситуации я также посмотрел бы на части интеграции Jira/Fisheye и посмотрел бы, нужен ли вам набор функций в данный момент (или вообще) при просмотре других коммерческих опций.

Ответ 2

Одним из основных преимуществ, которые мы получаем от использования FishEye, является расслоение на Crucible поверх него, что облегчает просмотр удаленных кодов.

Ответ 3

Мы отошли от использования FishEye, потому что он был медленным и громоздким на наших ограниченных серверах. Намного счастливее, используя JIRA вместе с Git на GitHub. Некоторые функции визуализации, которые рекламируют FishEye, также не поддерживаются в Git. Я большой поклонник Atlassian, я просто думаю, что FishEye не является одним из лучших инструментов для работы Git.

Ответ 4

Мне очень нравится интеграция между рыбой и Джирой. Наличие ваших проектов в джире, связанных с вашим хранилищем в рыбий глаз, является удивительным. Вы получаете вкладку "источник" в jira. Затем, когда вы фиксируете идентификатор ошибки/задачи в комментарии коммита, файлы из фиксации отображаются на вкладке источника в jira, и вы можете просто щелкнуть, чтобы точно увидеть, что было изменено в фиксации для этой ошибки/задачи. По общему признанию, я сделал это только на SVN, поэтому не могу точно сказать, работает ли он с git, но было бы интересно исследовать.

Еще одна интересная особенность заключается в том, что вы можете создать дефект jira из обзора тигля. Я могу выделить оскорбительную строку кода, создать дефект, а затем создатель получит предупреждение, если есть неразрешенные ошибки, связанные с обзором, когда они пытаются обобщить/закрыть обзор.

Работая над 100% удаленной командой, я нахожу Crucible в fisheye неоценимой для обзоров кода.

Ответ 5

Обновление Январь 2013: он называется Stash.
(см. sendmoreinfo comment)

Оригинальный ответ Февраль 2012:

Из FishEye2.7 вы можете не только получить доступ к удаленному репо, но и создать на сервере FishEye новый Git репо.
См. " страница руководства FishEye", " Создание Git репозиторий "и " Включение управления репозиториями в FishEye".
Сообщение в блоге " FishEye in Practice: настройка собственных репозиториев Git также представляет эту функцию, в которой перечислены цели для этой функции:

• Разрешить предприятиям получать или переносить репозитории Git за свой брандмауэр
• Сделать простую настройку разрешений репозиториев для команд

Это означает, что FishEye будет использовать уровень доступа (например, Apache Server, поверх которого работает FishEye) для внутреннего доступа Git репо.

Он также предоставит основной механизм авторизации, то есть вам не нужно настраивать отдельную инфраструктуру, например, другую Apache + Gitolite для управления внутренними репозиториями: вы можете напрямую использовать сервер FishEye.

Ответ 6

Для меня интересная часть состоит в том, что я могу быстро выяснить, какое сообщение связано с проблемой. Он будет частью самой JIRA.

Так что, если я репортирую ошибку в проекте, на который я непосредственно не работаю, я могу проверить, как это исправить, как я ожидал, без необходимости клонирования проекта, а затем искать журнал истории фиксации.

Это также заставляет разработчиков помещать теги проблем в сообщение фиксации.

Отзыв кода также хорош, но до сих пор мы не часто его используем.