Хабрахабр

Codeisok, или История code review в Badoo

Меня зовут Илья Агеев, я работаю в Badoo уже почти семь лет. Привет, читатель! Одна из сфер, которая входит в зону моей ответственности, — ревью кода. Текущая моя должность называется Engineering Director Quality Assurance (директор по контролю качества), и по факту я занимаюсь много чем в компании: контроль качества, релиз-инжиниринг, процессы и методология разработки и даже немного информационная безопасность. Об истории этого процесса в нашей компании я сегодня и расскажу.

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

Давным-давно в Badoo не было code review. Практически. Первой попыткой обмена информацией об изменённом коде была простая рассылка изменений на почту. К слову, и Git тогда не использовалась.

Бывалые рассказывали, что до этого все работали в CVS и что была одна попытка перейти на Mercurial, но она провалилась. Летом 2011 года, когда я только пришёл в компанию, для хранения версий кода использовалась SVN. Я подозреваю, что дело в том, что, когда решили попробовать Mercurial, особой надобности в переходе на другую VCS не было. Почему — никто не помнит. А модный инструмент ради моды никому не нужен.
Всё и так всех устраивало: работает, и ладно.

В любом случае я те времена не застал, и моё знакомство с проектом тесно связано с SVN. Разработка велась в одной ветке — trunk. Иногда сторонние экспериментальные вещи делались в отдельных ветках SVN с последующими мучительными попытками смёржить то, что получилось, в общую ветку. Оно и неудивительно: SVN — не самая идеальная вещь для работы в ветках.

Запоминаем номер ревизии, полученный от SVN, и прописываем его в тикет, чтобы в выкладке было понятно, какие задачи в неё попали. Флоу работы выглядел примерно так: берём голову trunk, делаем изменения в коде, коммитим (SVN принимает коммиты сразу на сервер, в общий код) и надеемся, что всё будет хорошо. Очевидно, что, если номер ревизии в тикете меньше номера выложенной на продакшн ревизии, значит, код этой задачи есть в истории коммитов.

Благодаря этому те, кто хотел ознакомиться с изменениями кода, могли это сделать. После коммита дифф с изменениями отправлялся на почту, в общую рассылку. Естественно, никакого упорядоченного процесса code review не было.

Git

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

Соответственно, первое, что следует сделать, — отделить мух от котлет. Результатом стал переход на Git и идеологию фичебранчей со всеми вытекающими преимуществами такого подхода. Подробно об этом переходе я рассказывал на РИТ++ в 2012 году в парном докладе с Юрием Насретдиновым.

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

  1. Оставили «старый» механизм оповещения об изменениях в виде письма на почту. К слову, этот подход используется до сих пор, многие наши инженеры находят это удобным: можно в любой момент времени в почте найти изменения, сделанные конкретным человеком в конкретных участках кода и в конкретной задаче. Сегодня в Badoo этот механизм работает параллельно с обычным процессом code review.
  2. Я установил просмотрщик кода в центральном Git-хранилище, где можно было видеть ветки в репозитории, коммиты, файлы и т. д. Когда код задачи попадал в общий репозиторий, Git-хуком прописывалась ссылка на изменения в этот веб-интерфейс, чтобы каждый интересующийся мог пройти по ссылке и увидеть изменения.

В тот момент наиболее подходящим для этой цели инструментом мне показался GitPHP, практически полный клон cgit. Инструмент мне понравился потому что его минималистичный интерфейс давал возможность делать всё, что нам требовалось, а открытый исходный код на PHP позволял нам менять/ добавлять что-то по мере необходимости.

Репозиторий на GitHub также удалён — видимо, автор больше не хочет развивать и поддерживать инструмент. Домен инструмента http://gitphp.org/, к сожалению, на сегодняшний день мёртв. Но мы помним https://github.com/xiphux/gitphp и очень благодарны автору — Chris Han.

Вот в этой статье от ноября 2013 года, к примеру, мы рассказывали, как оптимизировали скорость работы инструмента и как Chris Han принял их в основной код. Мы любим и уважаем open-source, и в GitPHP, как и во многих других инструментах, с которыми мы работаем, сделали несколько улучшений.

Code review

На Git перешли, процесс настроили. Что дальше? Ещё одним моментом, стратегически влияющим на многие вещи в разработке, является ревью кода. Процесс, имеющий массу плюсов (минусы тоже есть, как-нибудь я опишу их в отдельной статье), в нашей компании построен не был.

Мы стали тестировать разные инструменты для организации code review, делали пробные инсталляции и изучали вопрос. В первую очередь мы хотели всё организовать для основного репозитория Badoo с PHP-кодом, а уже потом, если всё будет хорошо, распространить на всю компанию.

Важнейшими требованиями, которые мы предъявляли к процессу и инструменту, на тот момент были:

  1. Возможность хостить инструмент внутри компании. У нас есть несколько разработок, которые являются интеллектуальными ноу-хау, да и с точки зрения здравого смысла не очень хочется, чтобы исходники могли утечь в Сеть.
  2. Чтобы код можно было смотреть/ ревьюить/ проверять сразу. И сразу давать фидбек. Не ждать, пока разработчик формально укажет, что всё готово, как это делается с пулл-реквестами в GitHub, например. Тем более очень много базовых проверок мы делаем автоматически на момент пуша кода в общий репозиторий.
  3. Процесс внедрения должен быть прозрачным, плавным и не должен мешать текущим задачам, которые уже на конвейере — чтобы никто не заметил особых изменений, а, напротив, люди получили новые возможности в случае необходимости.
  4. Интеграция с Jira, которая на тот момент уже широко использовалась в компании.

На данном этапе необходимо пояснить два новых термина, которые мы используем и которые отличаются от идеологии пулл-реквестов. Это бранчдифф и бранчлог. По сути, это просто разница в коде между базовой веткой (у нас это master в большинстве случаев) и веткой задачи. Бранчдифф — полный дифф между двумя головами веток. Бранчлог — полный лог коммитов, показывающих разницу между головами двух веток. По мере роста ствола коммитов ветки задачи бранчдиффа и бранчлога могут расти.

Gerrit

Примерно в то же самое время, когда я разбирался с основным репозиторием кода и PHP’шниками, наши сишники озаботились проведением code review в своих репозиториях (их у них много) и самостоятельно решили опробовать Gerrit. Антон Довгаль вот в этой статье подробно рассказывал о том, как это было, какие инструменты ещё рассматривались и какие проблемы хотелось и удалось решить.

А на тот момент для других отделов не подходил, так как умел делать ревью только на покоммитные изменения. Забегая вперёд, скажу, что сегодня Gerrit в Badoo не используется. Честно говоря, я не уверен, что умеет и сейчас. Ревью кода всей ветки (бранчдиффа) инструмент делать не умел. Поэтому от Gerrit как инструмента для ревью кода во всей компании мы отказались.

GitLab / GitHub

Изучать инструменты для ревью кода нам тогда помогал руководитель бэк-офиса Борис Чернецов. Боря ставил разные тулзы, показывал, как они работают, предлагал процесс ревью, поддерживаемый этими инструментами, и т. д.

Насколько я помню, основными проблемами были: Но ни один из рассматриваемых на тот момент инструментов нам не подошёл (стандартная фраза — оправдание изобретения собственного велосипеда).

  1. Многие инструменты не предлагали self-hosted-решений. А для нас это было одним из базовых требований.
  2. Отсутствие pre-receive-хуков, что отдаляло проверки и удлиняло цикл разработки. Все автоматические проверки можно было делать только постфактум, после создания пулл-реквеста. Так работает GitHub, например, который к тому же ещё и является платным сервисом.
  3. GitLab был тогда очень сырым и содержал кучу багов, хотя поначалу нам очень понравился. Очень многое из заявленного функционала просто не работало. Сегодня, насколько я знаю, ребята ушли далеко вперёд и хорошо развили проект.

Мы рассматривали ещё несколько инструментов вроде Gitorious и других, но они сильно уступали в функциональности даже GitLab и не предоставляли многих необходимых нам функций.

GitPHP для code review

Разочаровавшись в тех инструментах, что мы сумели найти, мы решили пойти совершенно другим путём. Раз нет инструментов, которые нам подходят на 100%, а правка кода GitPHP не является такой уж сложной задачей, то почему бы не попробовать сделать простейший механизм комментирования кода в GitPHP? Тем более что все остальные необходимые нам вещи  хранение кода на сервере, управление доступом Gitosis, привязка к тикетам, просмотр изменений веток и т. д. — уже есть.

На том и порешили.

Николай Крапивный помог нам сделать авторизацию через Atlassian Crowd и простейшую форму комментирования строк кода за пару выходных. На создание первой версии у нас ушло совсем немного времени. И мы поняли, насколько это хорошо и удобно: тыкаешь на ссылку в тикете (ту, что уже там была до этого, к которой все привыкли) — и можешь писать комментарии к коду.

А ещё добавляются в тикет в Jira. Комментарии отправляются разработчику на имейл и могут помещаться в публичные рассылки. Заморачиваться с созданием отдельных «тикетов для ревью» (как делает Crucible, например), назначением ревьюверов внутри GitPHP (ревьювер — тот, на кого перевели тикет после разработки в Jira), отдельным статусом ревью и т. Очень удобно. не нужно. д. Если всё хорошо, просто переводим тикет дальше. Есть комментарии, переоткрыли тикет — значит, код надо исправлять.

Эта простая схема настолько органично вписалась в проект и так понравилась разработчикам, что её легко и быстро подхватили и стали использовать.

Crucible и FishEye

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

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

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

К сожалению, идеального инструмента среди них так и не нашлось. Так, в наших исследованиях участвовали следующие инструменты для ревью: Upsource, Crucible, GitLab, Phabricator, Review Board, Kallithea и несколько других.

Crucible использовали многие мобильные разработчики в своих предыдущих проектах и давали положительные отзывы. Несмотря на это, мы всё-таки поставили Crucible параллельно с GitPHP и целый год сравнивали работу этих двух инструментов. Интеграция с Jira у него была одной из лучших, что неудивительно — его тоже делает Atlassian.

Нам даже пришлось сильно урезать его функционал отключением нескольких фич. Основная же проблема Crucible, как оказалось, производительность.

Самое быстрое, что нам удалось выжать из этого инструмента, — десять минут до появления кода в инструменте после пуша. Мы пробовали разное железо, разные оптимизации, рекомендуемые разработчиками, но так ничего и не добились. После увеличения количества репозиториев и коммитов скорость падала нелинейно. А в случае с некоторыми задачами, зависимость которых была непонятна, и по паре часов приходилось ждать. Для нашей динамики разработки и поставки фич это не подходило.

Мы даже разные движки баз данных пробовали. Индекс, который Crucible строит и хранит внутри и который служит базой для показа диффов, логов и блеймов, строится невообразимо медленно. Лечилось это рестартом обеих систем. Иногда по непонятным причинам Crucible начинал «подвешивать» и Jira.  

Соответственно, поигравшись год с Crucible, мы приняли волевое решение внедрить GitPHP и у мобильных разработчиков тоже. Ну и в итоге получилось так, что GitPHP и работает в разы быстрее, и многие хотелки по запросам мобильных разработчиков мы успели добавить, и у Crucible масса своих проблем.

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

Codeisok

Конечно, с тех пор как мы начали работать с GitPHP, много воды утекло, и мы практически до неузнаваемости изменили оригинальный инструмент. Он получил новый функционал, новый дизайн, кучу дополнительных возможностей, оптимизаций и улучшений.

Мы добавили несколько методов авторизации: не только через Jira и Crowd, но ещё и через Redmine, к примеру. Мы изменили подсветку синтаксиса и полностью переписали режим side-by-side. Мы избавились от Gitosis и реализовали управление репозиториями, пользователями и их доступом через веб-интерфейс — легко и удобно (Саша и Женя, спасибо). Мы добавили фильтры по файлам (Саша, спасибо), расширениям, изменениям в диффах и ревью. Мы сделали установку инструмента лёгкой, обернув всё в докер. Мы полностью поменяли дизайн. Ну и про саму возможность делать code review не забываем — она тоже эволюционировала и стала гораздо удобнее.

Читается «код из ок» и означает, что с кодом всё хорошо. В общем, инструмент стал совсем другим, поэтому мы дали ему новое имя: Codeisok.

Выражение является внутрикорпоративным мемом и используется в диалогах:

— Сделай ревью моей задачи, пожалуйста.
— Посмотрел, codeisok’нул!

Инструмент уже работает в нескольких проектах вне Badoo и имеет положительные отзывы (например, wetrend.com и turbocontract.ru). И сегодня мы рады сообщить, что Codeisok доступен для open-source-сообщества. Улучшения и пулл-реквесты мы будем с радостью принимать — всегда рады тем, кто помогает развивать open-source-инструменты. Мы надеемся, что вам он тоже понравится и будет полезен.

Ребята, спасибо! Также, пользуясь случаем, хочу выразить огромную благодарность всем, кто помогал развивать и улучшать проект. Вы невероятно крутые!

Никиль Верма
Стас Игнатенков
Александр Измайлов
Антон Довгаль
Юрий Насретдинов
Николай Крапивный
Константин Дзюин
Милош Попович
Александр Трегер
Евгений Махров
Денис Кореневский
Павел Матолыгин
Александр Гришин
Роман Лазарев
Александр Овсянкин

In code we trust!
Илья Агеев, Badoo

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»