Привет! Меня зовут Максим, я руковожу мобильной разработкой в KTS.

Сегодня расскажу о нашем опыте работы с системами код-ревью, и почему через 5 лет работы на Upsource мы переехали на GitLab.

Код-ревью позволяет разработчикам выявлять ошибки и уязвимости кода, поддерживать работу в команде, совершенствовать архитектурные решения проектирования систем. Главная цель процесса в совершенствовании кодовой базы разработчиков. Поэтому при проверке они в первую очередь думают о том, как написанный код повлияет на весь проект в перспективе.

Более подробно код-ревью рассматривать не будем, поскольку материалы уже есть:

• история код-ревью и инструменты на примере Badoo

• как проводить код-ревью и почему это важно

Наша команда мобильной разработки использовала Upsource с 2017 года: на тот момент он был одним из самых удобных инструментов для просмотра кода, комментирования и изучения правок. Мы использовали selfhosted-вариант сервиса.

Однако по мере роста команды и изменения процессов мы столкнулись с проблемами, которые подтолкнули нас к поиску нового сервиса.

Содержание:

• Ключевые проблемы использования Upsource

• Первый взгляд на GitLab

• Сравнение Upsource и GitLab

• Интеграция с GitLab Bot
  

  • Создание ревью

  • Комментарии к ревью

  • Апрув ревью

• Резюме: почему GitLab?

Ключевые проблемы с использованием 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

Сравнение сервисов по нашим основным требованиям приведено в таблице. Преимущество системы в рамках пункта выделено медалью ????.  

Не все эти требования для нас равнозначны, поэтому нельзя посчитать преимущества и сказать, что GitLab победил Upsource со счетом 6:4. Но надеюсь, для вас эта таблица будет полезна. 

Выше я сказал, что одна из главных проблем — «ручное» оповещение о ревью, которая не решалась из коробки в обеих системах. Поэтому мы рассмотрели возможность интеграции GitLab с нашим корпоративным ботом: его возможности постепенно будут расти для закрытия всех потребностей.

Интеграция с GitLab Bot

Изначально GitLab Bot — внутренняя разработка KTS, который оповещает в Telegram об изменениях статусов CICD pipeline. Чем это помогает:

• разработчику не приходится постоянно входить в GitLab, чтобы удостовериться, что его pipeline успешно завершился

• тестировщики сразу получают ссылки для тестирования функционала по успешной раскладке сервиса или распространения сборки 

Выглядит это так:

В новой версии бота наши бэкенд-разработчики добавили интеграцию с MR GitLab по части работы с код-ревью. Это решает главную проблему ручных оповещений о ревью в Upsource и минимизирует человеческий фактор, когда разработчик может забыть отписаться ревьюеру, а сам ревьюер — просмотреть код. Все взаимодействие по проектам компании ведется в Telegram, поэтому это решение эффективно и удобно для нас.

Создание ревью

Теперь, когда кто-то создаст новый Merge Request и назначит там главного, бот автоматически уведомит человека об этом: в сообщении указываются проект, название ветки, автор и ссылка на MR:

Комментарий по ревью

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

Апрув ревью

Когда статус MR меняется — например, ревьюер его заапрувил — бот также присылает об этом сообщение:

Бот удобен, но некоторых возможностей все же не хватает. Поэтому мы планируем кое-что доработать: 

1. Множественные ревьюеры. В GitLab уже есть возможность выбора нескольких ревьюеров, но только в платной версии. Функция необходима ограниченному количеству команд, поэтому ради нее нерационально всей компанией переходить на платный тариф. Мы думаем о реализации такого варианта через бота.   

2. Разделить оповещения сборок от оповещений MR. GitLab Bot шлет оповещения в один чат. В разгар рабочего дня сообщения о комментариях и новых ревью теряются в основной массе уведомлений от сборок. Чтобы не терять нужные оповещения, мы хотим разделить их по типам.

3. Напоминание о просмотре. Бот отправит сообщение о новом ревью, но специалист может отвлечься на другую важную задачу и забыть. Поэтому мы собираемся научить бота отправлять напоминание о непросмотренном ревью: например, если в течение дня ревьюер не оставил каких-либо комментариев или не апрувнул код. 

Резюме: почему Gitlab?

1. Переход на GitLab позволил нам отказаться от использования отдельного сервиса для код-ревью: теперь все находится в рамках одного рабочего инструмента.

2. Сервис продолжает постоянно развиваться. Upsource же недоступен внутри Space, у него нет поддержки и выхода новых версий.

3. Сама система показывает более стабильную работу с ревью с большим количеством правок и комментариев.

4. GitLab помогает получать более полную и подробную информацию о процессе разработки прямо внутри MR: статусы сборок, CI/CD pipeline, отчеты по задачам. 

5. Интеграция GitLab с нашим корпоративным ботом помогла решить проблему с замедлением работы при «ручном» общении: сотрудники автоматически получают оповещения о назначении ревью и появлении в нем новых комментариев. Теперь процесс разработки будет проходить без «застойного» периода. 

GitLab стал эффективным инструментом для код-ревью мобильной команды KTS: он полностью отвечает требованиям и специфике работы. Разумеется, для других компаний или команд разработки выбор может отличаться в зависимости от задач. 

Поделитесь в комментариях, какие требования предъявляете к подобным сервисам? С какими проблемами сталкивались и как решали?