Как стать автором
Обновить

Комментарии 23

жаль. геррит был одним из первых code-review, но он как-то забивает на интерфейс. Нечто похожее происходит с дженкинс, но дженкинс за счет своей гибкости и огромного комьюнити легко находит себя в новых нишах, типа интеграции в контерных средах.
А вот gitlab хорошо развился за последние 3-5 лет, надо брать пример
Мне как бы пофиг, но так как сам был вынужден был недавно пользоваться GitLab после многих лет использованя Gerrit, то полностью согласен с
рабочий процесс Gerrit во многих отношениях является лучшим

И сочувствую всем «пострадавшим».
И еще возинкает вопрос. Товарищам пилящим GitLab совсем пофиг, что можно сделать лучше или просто когда привык «гланды через анус вырезать» то переучиваться на нормальный вариант уже не тянет?

Все так, минусуют безголовые фанаты гитлаба, которые ничего кроме него не видели

Думаю минусуют за грубость, а не за смысл
НЛО прилетело и опубликовало эту надпись здесь

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

Стекированные друг на друге патчи (Related changes)? Работа с бранчами? А что не так, и что улучшилось с переходом на Gitlab?

Собственно отсутствие работы с бранчами это и есть основная проблема gerit. Через related changes можно найти остальные коммиты из сливаемой ветки, но нельзя посмотреть сумму всех изменений, нельзя посмотреть diff между разными версиями ветки при force push. Нет общего CI статуса для merge head. Нужно прыгать в интерфейсе между коммитами чтобы получить текущий статус всех обсуждений.


Gitlab по сравнению с этим экономит время, потому что там вся история — в одной линейной ленте, а ключевая информация (статус CI и количество unresolved discussions) для всей ветки на самом виду.

Нет общего CI статуса для merge head.
С этим не соглашусь. Есть же checks плагин, с помощью которого у каждого, и у последнего patch set в ветке красиво виден CI статус. В общем списке patch set'ов или в списке patch set'ов ветки тоже отлично видны "✓" при пройденном CI.

С остальным соглашусь.

В нашем gerrit этого плагина не было. Кстати, ещё одно преимущество gitlab в корпоративной среде — стандартизированный набор функциональности, не нужно воевать годами с IT-поддержкой, чтобы установить один нужный плагин.

Gerrit так и задумывался, чтоб работать над коммитами, а не над ветками.
Каждый коммит — логически законченное изменение.
Видеть в истории 50 коммитов «хождения по граблям» и потом «кусок говна, который ноканец-то заработал merged to master» — не очень приятное зрелище.
Увидеть 3 patchset-а в стиле «Add feature 1», «Add test for feature 1», «Update docs» — намного приятнее и проще ревьюить. У вас есть пачт или серия патчей. Всё.

Чего не хватает в gitlab ce:
1. Approves — плати
2. Auto Reviewers — если и есть — скорее всего плати
3. Проверка каждого коммита, а не ветки. На вопрос «зачем?» оставлю время подумать
4. Скорость ui — gitlab тормозит. Ну вот реально тормозит. Просто мы отвыкли уже от по-настоящему быстрых вещей
5. Сделал ревью, оставил комментарии. Пришёл новый пуш и все комменты outdated. Как было и как стало — иди ищи, открывай старое, вспоминай где оставил коммент, открывай новое, смотри как стало. Может доработают
6. Review имён файлов как?
7. Review commit message как?
8. Хуки и валидация commit-ов — плати/получи админские права на инстанс.

Но тут как сравнивать. Gitlab как code review system пока никакой.
Gerrit как project management system — тоже никакой.

Ради справедливости. Гитлаб как project management system — тоже никакой. Либо плати. Чтобы нормально пользоваться встроенными ишьюс

Ну это я ради объективности. Есть в гитлабе и хорошие стороны. Вон, дебиан же поднял себе salsa. Наверняка они много думали перед таким поворотом.

Меня от геррита останавливает только одно — кроме дженкинса не могу прикрутить никакого вменяемого ci (наподобии gitlab-ci или github actions). Кто бы подсказал как это сделать — уже бы ушёл на него.

Я в сальса заходил. Попробовал походить по логам сборок. Пользоваться этим невозможно. К сожалению. Очень многие опенсурс продукты переводят свои сборки на гитлаб. Потому что гитлаб спонсирует опенсурс разработку бесплатными премиумами. Но вот сами раннеры… железо под них не бесплатное. Вы представляете себе сложность поддержки сборок того же дебиан? Там реально жесткач. И мне кажется, что эти старые добрые системы сборки превратить во что-то нормальное получится ещё не скоро и гитлаб особо в этом не поможет…


Меня от геррита останавливает только одно — кроме дженкинса не могу прикрутить никакого вменяемого ci (наподобии gitlab-ci или github actions). Кто бы подсказал как это сделать — уже бы ушёл на него.

concourse? gocd? Я никогда их с герритом не сшивал, но сами системы неплохие

Zuul CI?

я бы предложил на него дать ссылочку, потому что загуглить его достаточно сложно
https://zuul-ci.org/
Сайт выглядит красиво, но сам продукт на уровне развития как Gerrit — "от программистов для программистов", а не "для пользователей".
Интересно было бы услышать про успешные внедрения...

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Знаете, в чем проблема? Многие натягивают TBD или аналогичный подход на гитлаб. Полностью убивая изначальную концепцию работы с ним. А раз так, то геррит не выглядит чем-то ужасным

особенно высок уровень недовольства в волонтерских сообществах
То есть новички, привыкшие только к GitHub flow не хотят учить что-то другое.

однако документация по пути обновления часто отсутствует
Да ладно? И документация есть, и в блоге статьи, и можно связаться и спросить совета.

Например, для перехода с Gerrit 2 на Gerrit 3 потребовалось несколько наборов обновлений, чтобы избежать простоя в течение нескольких дней.
Надо было у ребят из GerritForge спросить совета, они без downtime'а (во всяком случае без несколькодневного downtime'а) всё мигрировали, а они держат крупнейший репозиторий.

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

А с Phabricator ни на что переехать не хотят? Проголосуйте, кстати, в этом комментарии: «+1» — нравится Phabricator, «-1» — не нравится.

Не пользовался, но фабрикатор выглядит очень интересным и правильным продуктом. В остальном — весь рунет сидит на гитлабе… почему-то

Зря они это, IMHO. Мы на нашем проекте, после 3 лет работы с GitLab, были вынуждены от него отказаться из-за серьезных проблем с его производительностью.
В самом начале проекта все выглядело неплохо, но, по мере накопления истории изменений, и увеличения количества коммитов (вместе с увеличением количества разработчиков), GitLab превратился в общую головную боль — страницы с code review открывались в течении нескольких минут, комментарии начали дублироваться или пропадать, иногда нельзя было добавить новый комментарий, но последей каплей стал сбой, при котором код ревью перестали открываться вообще и разработчик был вынужден загружать новый коммит с новым review-id. Постоянный апгрейд серверного железа не помогал улучшить ситуацию — (даже после установки самых современных на тот момент серверов). Тем временем, «соседние» проекты, с еще большим количеством разработчиков и такой же долгой историей коммитов, успешно развивались на старом (в три раза худшем) железе.
После миграции на Gerrit проблемы с производительностью исчезли и вот уже 3 года «полет нормальный».
Хотя пользовтельский интерфейс и фичи GitLab очень удобны и выглядят очень привлекательно, тут спора нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости

Истории