Тигель по сравнению с Герритом?
Мы сейчас используем Crucible от Atlassian для анализа кода (на самом деле мы не используем часть FishEye), и он начинает выходить из строя, в основном из-за проблем с производительностью при индексировании большого репо и нескольких репо.
Наш код размещен на Github, и разработчикам рекомендуется раскошелиться на репо и выполнять всю свою работу на собственных форках. Чтобы это работало с Crucible, нам нужно проиндексировать все ветки разработчиков. Мы начали это делать, но это занимает невероятно много времени (часов на коммит). Смотрите ссылку выше.
Как Геррит сравнивается? Индексирует ли он репо?
Я знаю, что люди будут комментировать, как, например, у Github есть запросы на получение проверок кода (мы их используем), но запрос на получение действительно выполняется в конце рабочего процесса после его рассмотрения. У нас работает команда из около 20 человек, и в Github нет системы, которая бы управляла тем, какие запросы и запросы на выполнение должны выполнять разработчик. Кроме того, интеграция Crucible с JIRA хороша, и мы этим пользуемся.
Я открыт для других инструментов проверки кода, а не только для Геррита.
4 ответа
Я начал использовать Gerrit на работе (небольшая команда из 6 человек, нет Github). Ему не нужно ничего "индексировать", но Геррит предпочитает держаться за "главный" репозиторий. Таким образом, новый разработчик будет клонировать прямо из Gerrit.
Изменения, сделанные разработчиками, помещаются в специальную ссылку на Gerrit, которая создает объект обзора. Другие разработчики могут специально получать коммиты для этого обзора, если это необходимо, но по умолчанию коммиты не доступны в обычной ветке, пока обзор не пройдет.
Существует множество вариантов разрешений, которые можно настроить с помощью Gerrit, к чему нужно привыкнуть. При необходимости вы можете настроить, какие пользователи могут выполнять какие действия для каждой ветви.
У нас есть большой репозиторий (кодовая база старше 20 лет), но история коммитов составляет всего около 2 лет (перенесено из предыдущей версии VCS). Нет проблем с производительностью, и из-за того, как работает Геррит, я не ожидаю каких-либо проблем по мере роста хранилища.
[Я не использовал Crucible.]
Альтернативой может быть ReviewBoard, который в основном хорошо работает с git. На предыдущей работе я написал скрипт, который использует перехваты после получения для автоматического создания обзоров каждый раз, когда что-то отправляется в центральный репозиторий. ReviewBoard не так хорош, как Crucible или Gerrit, но мы перешли на него с Crucible именно по тем причинам, которые вы описываете.
Небольшие проблемы с ReviewBoard и git в основном связаны с некоторыми странными ситуациями, такими как попытка просмотреть каждый коммит с начала репо - я обнаружил, что в большинстве случаев мне приходилось самому форматировать diff и загружать его, а не позволять ReviewBoard postreview.py скрипт справится с этим.
Обратите внимание, что очень немногие инструменты для просмотра кода индексируют репозиторий так, как это делает Crucible. Большинство из них полагаются на патчи, независимо от того, были ли они автоматически сгенерированы каким-либо инструментом, таким как postreview.py, или путем просмотра коммита и генерации разницы внутри.
Как сказал Грег, Gerrit предполагает, что ему принадлежат репозитории, и в настоящее время нет хорошего способа использовать его вместе с github. Возможно, вы могли бы подключить его так, чтобы после проверки / проверки / слияния кода в gerrit он был отправлен в github, и разработчики все равно могли получить его оттуда.
Я не верю, что у вас возникнут какие-либо проблемы с производительностью - Gerrit используется в большинстве магазинов Android и других местах в Google и других крупных компаниях. Сотни разработчиков, загружающие тысячи репозиториев, не редкость.
Если вы сейчас используете хостинг на github, вам необходимо предоставить собственное оборудование, которое должно быть несколько сложным. Геррит с радостью использует всю память, которую вы можете ей дать... Я полагаю, что в некоторых местах используется 64 ГБ или больше ОЗУ, но $DAYJOB обходится примерно с 16 ГБ для пары сотен разработчиков.
Тематические ветки довольно хорошо работают на Gerrit и постоянно улучшаются.
Геррит на самом деле не решит вашу проблему с назначением разработчиков для проверки / проверки / слияния. Разработчики могут добавлять других разработчиков в качестве рецензентов для изменения / фиксации, но нет официальной концепции рабочего процесса / владельца. Моя команда использует для этого Jira - после того, как задача будет выполнена, назначьте проблему Jira кому-нибудь для проверки, затем назначьте ее кому-нибудь для проверки и т. Д. Здесь также есть много других опций.
Я подозреваю, что Геррит удовлетворит ваши нужды. Я бы порекомендовал вам попробовать!
На самом деле вам не нужно иметь отдельные форки для выдачи запросов на извлечение, вы можете сделать так, чтобы каждый принимал участие в одном репо и передавал ветки функций в GitHub, а затем нажимал на запрос на извлечение "От" feature-1- "до" master "".