Всем привет! Меня зовут Юра, я – IOS-разработчик в hh.ru. В этой статье мы рассмотрим с одну из важнейших метрик для IOS-разработчика – скорость сборки. Я расскажу о том, как мы собираем эти метрики и что потом с ними делаем, и почему мы вообще решили всё это измерять.

Видеоверсию можно посмотреть тут.

В чем проблема долгой сборки?

Долгая сборка выбивает из контекста задачи, над которой мы работаем. Зная, что проект будет долго собираться, вы можете позволить себе отвлечься, пойти налить чашечку кофе, залипнуть в чаты и поскроллить соцсети. И вот уже минут через 30 вы вспоминаете, что должны были проверить как поживает тот баг, а не листать ленту «Twitter» или читать очередную статью в википедии про анемоны.

Поэтому для начала мы разберем, как измерять скорость сборки. Ведь если мы не знаем насколько всё плохо, как мы поймем, что стало лучше?

Сколько длится сборка?

Есть два очень простых способа, которые позволят засечь время потраченное на сборку прямо в интерфейсе Xcode. Это включение приватной настройки ShowBuildOperationDuration и запуск сборки через меню Product -> Perform Action -> Build With Timing Summary.

В первом случае финальное время сборки отобразится в статус баре Xcode, а во втором мы получим мини-отчет по разным этапам сборки, который можно будет посмотреть в Report Navigator. Он отображает самый интересный и полный отчет о сборке, который нам доступен, но можем ли мы достать его из Xcode?

Разбираем xcactivitylog

Самый подробный отчет о сборке у формата .xcactivitylog. Лежит он в DerivedData, в папке Logs. И он довольно сложный, но есть видео, где рассказывается, как его зареверсили и что нашли. Но не спешите закатывать рукава и парсить всё своими руками, ведь это уже сделали за нас.

Для парсинга этих отчетов существует XCLogParser. Эта утилитка парсит отчеты и предоставляет их нам в приемлемом для дальнейшей работы виде. Например, в виде json, который удобно парсить или в html, который удобно смотреть. Полный список форматов тут.

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

Например, на этой части отчета видно, что какое-то время у нас собирается всего лишь один таргет — UI, от которого зависят все наши продуктовые фичи. И в то же время  в параллели больше ничего не собирается. Короче говоря, мы просто теряем время.

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

И да, всё, что мы видим в таком отчете, будет доступно и в формате json, из которого можно своими руками достать всё необходимое.

Что мы собираем?

Сейчас мы собираем следующую информацию по сборкам на CI:

• Дата

• Длительность сборки

• Длительность отдельных фаз

• Схема приложения

• Конфигурация сборки (debug, release, adHoc)

• Чистая ли сборка

• Версия Xcode

• Модель устройства

• Имя пользователя

• Идентификатор CI агента

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

Где и как храним?

В нашем случае мы используем influxdb для хранения данных и Grafana для отображения графиков и отчетов.

Разберемся, что мы можем видеть в Grafana. У нас есть таблица с полной информацией обо всех последних сборках, где мы можем посмотреть все данные, что удалось собрать.

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

И еще у нас есть графики времени сборки наших проектов на разных CI-тачках. Например, на этом графике видно, сколько времени занимает сборка нашего приложения для работодателей на каждом из CI-агентов. И тут хорошо заметно, что сборки на M1 mac mini примерно на треть быстрее, чем на старых intel маках.

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

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

Подытожим

Измеряйте скорость сборки. Это стоит начинать делать как можно раньше, еще до того, как вы соберетесь что-то менять в проекте. Сегодня существует множество разных инструментов для измерения скорости, остается только выбрать подходящие именно вам. А если вы уже настроили сбор метрик, не забывайте следить за ними, чтобы ненароком не проспать серьезные изменения.

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

Маленький опрос для большого исследования

Мы проводим ежегодное исследование технобренда крупнейших IT-компаний России. Нам очень нужно знать, что вы думаете про популярных (и не очень) работодателей. Опрос займет всего 10 минут.

Пройти опрос можно здесь.