Почему спустя 5 лет код-ревью на Upsource мы перешли на GitLab
Привет! Меня зовут Максим, я руковожу мобильной разработкой в KTS.
Сегодня расскажу о нашем опыте работы с системами код-ревью, и почему через 5 лет работы на Upsource мы переехали на GitLab.
Код-ревью позволяет разработчикам выявлять ошибки и уязвимости кода, поддерживать работу в команде, совершенствовать архитектурные решения проектирования систем. Главная цель процесса в совершенствовании кодовой базы разработчиков. Поэтому при проверке они в первую очередь думают о том, как написанный код повлияет на весь проект в перспективе.
Более подробно код-ревью рассматривать не будем, поскольку материалы уже есть:
Наша команда мобильной разработки использовала Upsource с 2017 года: на тот момент он был одним из самых удобных инструментов для просмотра кода, комментирования и изучения правок. Мы использовали selfhosted-вариант сервиса.
Однако по мере роста команды и изменения процессов мы столкнулись с проблемами, которые подтолкнули нас к поиску нового сервиса.
Содержание:
Ключевые проблемы с использованием Upsource
«Ручное» оповещение о ревью. Мы заметили, что на этапе код-ревью работа команды часто затягивается. По процессу каждый разработчик раз в день в удобное для себя время садится и просматривает назначенные на него ревью. И все равно всем периодически приходилось напоминать друг другу о просмотре, так как оповещения в браузере от Upsource работали с переменным успехом и не у всех. В итоге получался монотонный ручной процесс: сначала сотруднику нужно создать ревью в Upsource, указать ревьюеров и оповестить их в Telegram. Затем там же ревьюер отписывается об апруве или необходимости доработки. Если ревьюер забыл посмотреть, его нужно пнуть. Если доработок много, цепочка повторяется несколько раз.
Снижение скорости ревью. Upsource часто подвисал на ревью с большим количеством коммитов или изменений, хотя машина соответствовала требованиям. Особенно это заметно при просмотре правок: ревьюер проходит по каждому коммиту и смотрит изменения точечно. Открытие каждого следующего коммита с задержкой тратит время и нервы разработчиков.
Дублирование между GitLab и Upsource. В качестве системы для работы с кодом у нас используется GitLab.
Во всех проектах настроены CI/CD-пайплайны, которые должны быть успешно завершены перед тем, как мы вольем задачу в основную ветку. Для прогона пайплайнов разработчики создают Merge Request в GitLab. Дополнительно ревью нужно создавать и в Upsource — увеличивается количество ручной работы.
Казалось бы, что можно связать таск-трекер с системой код-ревью и исправить это. Для работы с задачами мы используем YouTrack, который, в отличие от Upsource, хостится не у нас, а в облаке, из-за чего связать их вместе для автоматического создания ревью в такой конфигурации невозможно. Интересно, что обе эти системы от JetBrains, а ограничения накладываются. Хотя, например, для интеграции Upsource с Jira таких ограничений нет.
Эту проблему можно решить с помощью ручного связывания Upsource и GitLab с помощью промежуточной написанной нами системы, которая будет работать с вебхуками и API.
Upsource переехал в JetBrains Space. 31 января 2022 года JetBrains в своем блоге объявил о прекращении продаж новых лицензий Upsource и переезде платформы в систему JetBrains Space. Хотя бесплатная версия продукта остается доступна, и нам она вполне подходит, потому что на Upsource сидела только мобильная команда. И все же есть несколько «но»: перестают выходить новые версии, а переход на Space всей компании невозможен — он требует значительного увеличения бюджетов, и многие процессы уже настроены на использование GitLab.
Так мы встали перед вопросом: менять ли сервис код-ревью или оставаться на Upsource и решать возникающие проблемы.
Мы решили посмотреть другие варианты: переезд Upsource в Space стал ключевым пунктом. Upsource использовала только небольшая команда мобильной разработки, поэтому потенциальный переезд не будет болезненным.
Первый взгляд на GitLab
Было решено попробовать GitLab — другие отделы разработки в нашей компании использовали его. Другие сервисы мы не рассматривали по нескольким причинам:
Крупные сервисы привязаны к общей инфраструктуре компании-разработчика: Atlassian, JetBrains, GitHub. Ради код-ревью мобильной команды мы были не готовы производить глобальные изменения во всей компании.
Другие команды в KTS, которые уже использовали GitLab, не замечали серьезных недостатков.
Мобильная команда использовала GitLab как git-систему и CI/CD.
Чтобы оценить эффективность работы с код-ревью и удовлетворение всех требований, GitLab нужно было испытать в «боевом» режиме. Переводить всю команду на тестирование было нецелесообразно, поэтому первыми его опробовали наши android-разработчики. Они поделились опытом за две недели использования, рассказали о плюсах и минусах сервиса.
По отзывам у GitLab не оказалось серьезных недочетов. Большинство минусов показались делом привычки. Преимущества, напротив, были сразу видны: они закрывали основные проблемы выше.
Основное различие систем в том, что Upsource предназначен исключительно для код-ревью, а GitLab объединяет множество функций: git-систему, CI/CD, и другие, менее важные для нас.
Следующим шагом стал переезд всей мобильной команды в GitLab на два месяца «пробного периода». После этого мы снова собрали фидбек и заметили, что многие работники уже привыкли к особенностям GitLab, изначально показавшиеся им неудобными.
Сравнение Upsource и Gitlab
Сравнение сервисов по нашим основным требованиям приведено в таблице. Преимущество системы в рамках пункта выделено медалью
