Тигель по сравнению с Герритом?

Мы используем Atlasian's Crucible прямо сейчас для проверки кода (мы не используем часть FishEye), и она начинает становиться непригодной, главным образом из-за проблем с производительностью при индексировании большого репо и нескольких репозиториев.

Наш код размещен в Github, и разработчикам рекомендуется разветвлять репо и выполнять всю свою работу в своих собственных вилках. Чтобы это работало с Crucible, нам нужно индексировать все вилки разработчиков. Мы начали это делать, но это занимает очень много времени (часы на фиксацию). См. Ссылку выше.

Как Геррит сравнивается? Он индексирует репозиции?

Я знаю, что люди будут комментировать, так как говорят, что Github запрашивает запросы на проверку кода (мы их используем), но запрос на pull действительно выполняется в конце рабочего процесса после его проверки. У нас есть команда из примерно 20 человек, и в Github нет системы для управления тем, какие обзоры / запросы на вытягивание должны быть заполнены разработчиком. Кроме того, интеграция Crucible с JIRA хороша, и мы этим пользуемся.

Я открыт для других инструментов проверки кода, а не только для Gerrit.

Я начал использовать Геррит на работе (небольшая команда из 6 человек, в доме, без Github). Ему не нужно «индексировать» что-либо, но Геррит предпочитает держаться за «главный» репозиторий. Так что новый разработчик будет клонировать прямо из Gerrit.

Изменения, внесенные разработчиками, подталкиваются к специальному refspec на Gerrit, который создает объект обзора. Другие разработчики могут, в случае необходимости, специально перехватывать коммиты для этого обзора, но по умолчанию коммиты недоступны в обычной ветке до тех пор, пока обзор не пройдет.

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

У нас есть большое хранилище (20-летняя кодовая база), но всего около 2 лет история фиксации (перенесена из предыдущего VCS). Нет проблем с производительностью, и из-за того, как работает Gerrit, я не ожидаю, что когда репозиторий будет расти.

[Я не использовал Crucible.]

Альтернативой может быть ReviewBoard, которая в основном работает с git. На предыдущей работе я написал сценарий, который использует post-receive hooks для автоматического создания отзывов каждый раз, когда что-то помещается в центральный репозиторий. ReviewBoard не так красиво, как Crucible или Gerrit, но мы переключились на него с Crucible именно по причинам, которые вы описываете.

Небольшие проблемы с ReviewBoard и git в основном связаны с некоторыми нечеткими ситуациями, такими как попытка просмотреть каждую фиксацию с начала репо. Я обнаружил, что обычно в таких случаях мне приходилось форматировать diff и загружать его, а не оставлять postreview.py ReviewBoard скрипт обрабатывает его.

Обратите внимание, что очень немногие инструменты проверки кода фактически индексируют репозиторий так, как это делает Crucible. Большинство из них полагаются на патчи, независимо от того, были ли они созданы с помощью какого-либо инструмента, такого как postreview.py, или просматривая фиксацию и генерируя diff внутри.

Как сказал Грег, Геррит предполагает, что он владеет репозиториями, и нет хорошего метода (в настоящее время) использовать его совместно с github. Возможно, вы могли бы подключить его так, чтобы как только код был проверен / проверен / объединен в gerrit, он попадает в github, и разработчики все еще могут получить оттуда.

Я не верю, что у вас будут проблемы с производительностью. Gerrit используется большинством магазинов Android и других мест внутри компании Google и других крупных компаний. Сотни разработчиков, которые нажимают на тысячи репозиториев, не редкость.

Если вы размещаете на github в настоящее время, вам нужно будет предоставить свое собственное оборудование, которое должно быть несколько мудрым. Геррит с радостью будет использовать всю память, которую вы можете дать … Я считаю, что в некоторых местах используется 64 ГБ или более ОЗУ, но $ DAYJOB получает около 16 ГБ для пары сотен разработчиков.

Области тегов довольно хорошо работают на Gerrit и все время улучшаются.

Gerrit на самом деле не решит вашу проблему назначения разработчиков для самостоятельной проверки / проверки / слияния. Разработчики могут добавлять других разработчиков в качестве рецензентов к изменению / фиксации, но нет официальной концепции рабочего процесса / владельца. Моя команда использует Jira для этого – как только задача будет выполнена, задайте вопрос Jira кому-то, чтобы просмотреть, затем назначьте его кому-нибудь, чтобы проверить и т. Д. Здесь также много других вариантов.

Я подозреваю, что Геррит удовлетворит ваши потребности. Я бы порекомендовал вам попробовать!

Вам фактически не нужно иметь отдельные вилки для выдачи запросов на тягу, вы можете заставить всех совершать одно репо и перетаскивать ветки функций в GitHub, а затем щелкнуть Pull Request «From» feature-1- 'to' master '"