Лично мне нравится Fisheye, но в нем есть среда разработки среднего размера и полусложная стратегия ветвления / развития, где мониторинг текущего состояния репо был довольно важным.
На моей последней работе нашим основным продуктом была линейка серверных Java-продуктов SaaS на стороне сервера, где все биллинги и системная интеграция обрабатывались на месте.Хотя большинство людей были хакерами Emacs / командной строки, мы по-прежнему использовали Fisheye поверх всех наших основных продуктов.
Предостережения
- Это было сSVN, а не git / hg, так что возьмите это с зерном соли.
- Были и другие крючки SVN, которые были встроены с участием Bugzilla, но я не уверен на 100% в том, как они работают
Перетасованные инженеры, работавшие над продуктами, у которых не было Fisheye, обычно былинедоволен по следующим причинам:
Рефакторинг Обычно вы перемещаете файлы, переименовываете, объединяете связанные изменения и тому подобное.Поиск Fisheye по базовому имени вернет файлы, которые были давно удалены с сохранением их истории, поэтому даже если вы испортили историю в репо, у вас есть представление о том, какие были предыдущие изменения.Для кодовой базы, которая испытывала некоторые очень реальные проблемы роста из-за внезапного расширения компании, это было огромной помощью
Владение кодом / обзор Даже безнадежный процесс владения кодом / проверки, вы можете подписаться на конкретные изменения проекта / репо с помощью Fisheye.Для руководителей групп и т. Д. Это очень простой способ оставаться в курсе того, что делают другие люди, когда они меняют вещи и почему, хотите ли вы получать спам по электронной почте или настроить RSS-канал для репо.Если вы управляете несколькими проектами одновременно, это может иметь большое значение.У меня был настроен канал RSS для моего первого крупного проекта, чтобы я мог видеть, как он меняется, но реальное преимущество заключается в том, чтобы отслеживать связанные с API проекты по мере их изменения
Можно использовать Не все наши инженеры являются хакерами командной строки.Это особенно актуально для некоторых разработчиков внешнего интерфейса, которые занимались HTML / CSS.Столько, сколько некоторые люди склонны прибегать к инструментам командной строки, когда это возможно, выполняя различий в файлах и «Кто отменил мои изменения и когда?»проще работать с инструментами сравнения в браузере, чем делать svn blame и т. п.
Все это говорит, я скажу, что если бы я занимался разработкой с нулявверх, я бы не стал его трогать, если бы мне не требовалась визуализация всего проекта, а не конкретного файла или двух, время от времени, что, вероятно, означает, что верно следующее:
- Размериз моей группы было задействовано около 10+ инженеров потенциально нетехнического профиля, и они нуждаются или реорганизуются из специальной стратегии
- Ветвление / тегирование удовлетворяет ряду конкретных потребностей так же, как и общее управление версиями
- Право собственности на код и его пересмотр, как минимум, слабовыраженная идея, а не жесткая позиция против нее из-за нехватки ресурсов
- Общение между инженерами становится все более серьезной проблемой (будь то явный шум илинедостаток этого).Это включает случайный разговор с простой документацией
Я также игнорирую любую интеграцию аналитики / инструментов.Отчасти потому, что я предполагаю, что если вы сравниваете Fisheye с чем-то еще, вам также следует подумать о том, сколько будет дополнительной работы, чтобы сохранить Fisheye по сравнению с другим решением или использовать его, но также потому что я никогда не работал с более чемодин продукт Atlassian за один раз.
В вашей ситуации я бы также посмотрел на компоненты интеграции Jira / Fisheye и посмотрел, нужен ли вам этот набор функций в данный момент (или вообще необходим) при рассмотрении других коммерческих вариантов.