Комментарии 17
Я не понял, зачем вам вообще какой то Upsource, если Gitlab был с самого начала?
Кстати, в том Gitlab, который я инсталлировал, почему то все уведомления присылаются без всякого бота. И это без того, чтобы я что-то специальное для этого делал.
Базовый функционал MR был действительно доступен в gitlab достаточно давно. В компании его пробовали, но он оказался неудобным в своих первых версиях. В тот момент и начали использовать Upsource. Посмотрите описание фичей MR в у gitlab, большинство из них было добавлено в 13 версии, до этого он совсем не дотягивал до Upsource.
По поводу бота - ответил ниже
Бот умеет тоже самое что и гитлаб из коробки, только настраивается оповещения на почту. Туда приходит инфа и когда тебя назначили ревью делать, и если твой пайп упал, и если треды по коду делают) пока зачем нужен бот не вкурил
Вкратце подсвечу основные моменты, по которым мы используем бота, а не оповещения от гитлаба:
в бота можно передавать любые параметры в зависимости от проекта (ссылки для тестировщика на разложенную версию сервиса или приложения). это достигается тем, что бота можно дергать из cicd пайплайна напрямую, а не только через вебхуки
можно рассылать оповещения не только автору, но и другим членам команды
множественные ревьюеры в бесплатной версии гитлаба
напоминалка о непросмотренных ревью
интеграция с Telegram (основной канал рабочей коммуникации, почтой не пользуемся)
неплохо)
можно рассылать оповещения не только автору, но и другим членам команды
через стандартную настройку оповещения любой член команды может настроить себе оповещение в гитлабе.
А какие планы на будущее? Взаимодействия какие-то? Запуск сборок из чата? Бот работает только с одним проектом или с несколькими может работать?
По планам на будущее: пока доработать нюансы процесса для моб команды, которые описаны в статье. Большинство полезных идей приходит в процессе пользования ботом.
Запуск сборок из чата - кажется лишним функционалом тк. у нас ручные сборки почти никогда не запускаются. Все происходит по пушу.
Бот работает со всеми проектами внутри гитлаба компании. Разработчику доступны оповещения о проектах в соответствии с правами гитлаба, настройки оповещений от проектов можно настраивать в интерфейсе бота, чтобы разработчик не получал информацию от ненужных в настоящий момент проектов.
В статье упоминается JetBrains Space, но в голосовании его почему-то нет. Поделюсь опытом.
Мы прошли примерно тот же путь, когда поняли, что и без того не идеальный Upsource окончательно умирает. Только выбор пал на Space, плюс мы держим код в GitHub. Тоже в "боевом режиме" на нескольких проектах опробовали его, нашли положительные и отрицательные моменты и приняли решение об окончательном переезде. Тоже понадобилось время на привыкание и перестраивание некоторых привычек. Вот уже 4 месяца пользуемся. Несмотря на некоторые недостатки, общее впечатление от проведения код ревью в Space весьма положительное, для нашей команды он точно суммарно удобнее, чем Upsource.
переход на Space всей компании невозможен — он требует значительного увеличения бюджетов, и многие процессы уже настроены на использование GitLab
Если от всего "комбайна" Space больше особо ничего не нужно и лимиты функционала устраивают, код ревью можно пользоваться бесплатно. Нам вполне хватает, кроме код ревью ничего пока не заинтересовало, код всё так же в GitHub (где настроены экшены для CI/CD).
К сожалению, фича-реквесты закрываются весьма не быстро, некоторые висят без реакции по несколько месяцев. Но даже текущий функционал вполне радует.
Спасибо за обратную связь о нашем продукте. Так как я являюсь частью команды, нам было бы очень полезно узнать подробнее, какие отрицательные моменты вы отметили в Space. Касаются ли они код ревью? Что останавливает от переезда с GitHub на Space Git хостинг?
Поскольку пользуемся только код ревью, все отрицательные моменты касаются только этого инструмента. Ниже привожу список всех недостатков и неудобств, по большей части связанных с привычками после Upsource.
Неудобства, требующие бОльших затрат времени на проведение ревью:
[Issue] Автор ревью не назначается автоматически, когда оно создается из PR в GitHub. PR в GH нам по-прежнему нужны, т.к. на них построен CI/CD. И создавать ревью вручную (не автоматически из PR) каждый раз будет неудобно
[Issue] Автоматически не выбираются комиты, сделанные после твоего последнего акцепта/запроса изменений
[Issue, duplicated] Нет дескрипшена код ревью, куда хотелось бы вставлять ссылку на таск-трекер (при автоматическом создании ревью из PR описание тоже не синхронизируется, как было в Upsource). Приходится кидать ссылку в Timeline, где ее выискивать глазами не удобно, особенно когда чат уже сильно разросся
[Issue] Нет возможности перейти из ревью в PR в GitHub (например, чтобы проверить экшены)
[Issue, duplicated] Скролл сквозь все файлы может привести к случайному пролистыванию файла. Плюс эта фича не позволяет удобно прыгать между файлами, т.к. обратно возвращаешься в начало, а не запомненную позицию. Поштучный просмотр файлов, как в Upsource, в виде настраиваемой опции был бы идеальным решением
Проблемы интеграции с другими инструментами:
При мерже ревью оригинальный PR в GH просто закрывается (причем, от имени юзера-владельца репозитория в Space). В JIRA затем такие PR отображаются как DECLINED. В качестве решения мержим PR в самом GH и не пользуемся кнопкой мержа в Space
Мержи напрямую в Space - в целом, не очень удобный подход при работе с GitHub. В частности, в списке коммитов в GH при деплое не будет ссылок на PR для всех комитов, смерженных через Space
Чтобы заработала интеграция с PhpStorm, приходится клонировать проект заново из
ssh://git@git.jetbrains.space/....git(существующий в PhpStorm проект, залинкованный на GitHub репозиторий - не распознается плагином)
Проблемы интерфейса (возможно, частично исправлены):
Если обсуждения скрыты, то после нажатия на иконку любого из них невозможно снова скрыть его
Усложняется восприятие диффа, если включить Split View и смотреть на код с длинными строками: перенос строк порождает новые (ненумерованные) строки в диффе
Стрелки для перехода к следующему найденному совпадению - перестают работать и снова начинают, если переключаться между Unified и Split View
Новые файлы попадают в область поиска при включенной опции Left, хотя ожидается, что Left/Right - это до/после
Если список изменений довольно большой, при сворачивании одной из папок в дереве файлов перестает корректно синхронизироваться позиция скролла в дереве файлов с панелью просмотра изменений
Не запоминаются свернутые папки в дереве файлов, если его скрыть/развернуть
Мелочи:
Нет возможности увидеть, когда ревьювер смотрел ревью в последний раз и сколько файлов ему еще осталось
Нет возможности в один/два клика скопировать путь к файлу в ревью
Спасибо большое за очень подробный и полезный фидбэк!
Не за что. Надеюсь, он поможет сделать продукт лучше.
Автоматическое добавление ссылки на PR GitHub и возможности оставлять произвольное описание к ревью (возможно, автоматически копируемое из описания PR) очень сильно упростят жизнь ревьюверам и мержерам. Думаю, после недавнего появления удобного сайдбара проблем с размещением этих новых элементов возникнуть не должно ;)
От переезда с GitHub останавливает отлаженная годами работа экшенов (CI/CD) и прочие фичи Enterprise-аккаунта, которыми активно пользуется несколько команд в компании. Убедить руководство потратить ресурсы на переезд - будет очень не просто. И весомых преимуществ никто не видит.
Так в чём суть "бота"? Это же всё (и даже больше) есть в простом оповещении на почту. По сути, это не бот, а просто костыль-оповещатель (ради чего? чтобы люди, которых нет в GitLab могли видеть работу, доступ к ссылкам получать вовремя)?
Про бота ответил тут.
Не все требуемые возможности есть в оповещении гитлаба. Плюс мы дорабатываем бота. Кейс со ссылками - это только пример использования. и это полезно: чтобы не спрашивать постоянно разработчиков, где проверять фичу, собралась ли сборка
Тоже перешли на gitlab, по сравнению с прошлыми продуктами не хватает тикетов. Если кто-то в одном проекте находит баг в другом, то в какое место gitlab и что он должен сделать, чтобы баг был исправлен? Как вы отслеживаете баги и их испраления в gitlab?
Для задач мы используем youtrack. Кажется, что issues решают вашу задачу
Upsource ужасно тормозил даже на небольшом проекте и в конце концов умер (проблемы с БД), YouTrack долгое время ни с чем нельзя было как следует подружить, он как пятое колесо, развивать его не хотели, Teamcity еще туда-сюда, но в свете политики компании я бы и с него слез, это не сложно. Выбирать Space чтобы получить тотальный вендор лок, зачем? Мы пользуемся гитлабом развернутым в своем облаке.
Почему спустя 5 лет код-ревью на Upsource мы перешли на GitLab