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

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

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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