Благодаря TeamCity команда IntelliJ Infrastructure сумела сократить время выполнения сборки на 30 %

Задача: масштабирование CI/CD-пайплайна для сотен разработчиков

Создать и поддерживать быстрые, надежные и масштабируемые CI/CD-пайплайны для большой команды разработчиков, которая постоянно вносит изменения в код, — непростая задача. Команде IntelliJ Infrastructure необходимо решение, которое обеспечивало бы значительное масштабирование, позволяя выполнять ежедневно тысячи сборок без перегрузки доступных ресурсов. Кроме того, необходима умная автоматизация, которая свела бы к минимуму вмешательство людей в процесс и гарантировала бы высокое качество итогового кода.

Кроме того, совершенно необходима поддержка различных окружений инфраструктуры, включая локальные агенты и агенты в облаке AWS для macOS, Linux и Windows. Наконец, чтобы поддерживать стабильно высокое качество кода, команде нужна возможность управлять тысячами автоматизированных тестов с минимизацией ошибок на неустойчивых тестах.

TeamCity — эффективное CI/CD-решение, разработанное JetBrains. Именно этот продукт блестяще справился со всеми этими сложностями.

«В TeamCity мы собираем не только IDE, но и все, что с ними связано: внутренние сервисы, системы статистики и многое другое. Я настолько привык к TeamCity, что для меня это как молоток в руке — с его помощью можно делать все что угодно».

— Дмитрий Панов, техлид IntelliJ Infrastructure

Чем TeamCity полезен команде IntelliJ Infrastructure

Механизм Safe Push

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

Чтобы обеспечить эффективность этого процесса, команда IntelliJ Infrastructure реализовала механизм Safe Push. Он представляет собой набор конфигураций композитных сборок в TeamCity. Для пользователей процесс выглядит очень просто: они отправляют изменения из своих IDE, и все.

За кадром же остается вот что: специальная внутренняя служба анализирует набор изменений Safe Push и с помощью TeamCity REST API запускает необходимую сборку для тестирования изменений. Кроме того, в случае ошибки эта же служба перезапускает сборку для повторного прохождения неустойчивых тестов.

TeamCity позволяет повторно использовать успешные сборки, и это заметно ускорило работу механизма Safe Push и снизило затраты, при том, что сборка для тестирования Safe Push может содержать до 700 000 тестов. При этом повторно используются артефакты, зависимости и результаты тестов, вместо того чтобы выполнять весь процесс с нуля. Тем самым повышается эффективность сборки, ускоряется прохождение CI/CD-пайплайна и сокращается использование ресурсов.

Экономия ресурсов благодаря повторному использованию сборок

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

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

Давайте рассмотрим типичный пример отправленного кода, чтобы понять, как повторное использование сборок помогает оптимизировать следующие попытки прохождения тестов. При первом проходе выполняются все 329 сборок в цепочке. 319 проходят успешно, 10 завершаются ошибкой, цепочка выполняется заново, но на этот раз только для 10 сборок, в которых возникла ошибка, остальные просто используются повторно. Еще 6 проходят успешно, а 4 завершаются ошибкой. Таким образом, при третьей попытке нужно выполнить только 4 оставшихся сборки, а 325 других используются повторно.

Это резко снижает нагрузку на билд-агенты и существенно ускоряет время, затраченное на повторные попытки тестирования. Вместо троекратного выполнения всего цикла, которое занимает около трех часов, повторное использование успешных сборок сокращает время выполнения примерно на 30 %.

Поддержка крупного масштабирования без перебоев в работе

Каждый день команда IntelliJ выполняет больше 158 000 сборок для более чем 180 уникальных пользователей. В таких условиях эффективность работы имеет критически важное значение. Благодаря повторному использованию сборок в TeamCity:

• 75 % сборок не приходится выполнять заново целиком, если тест завершился ошибкой;
• время, затрачиваемое на повторные попытки, сократилось в среднем на 30 %, в результате заметно реже возникают проблемы с производительностью;
• разработчики могут регулярно выполнять слияния, не мешая друг другу, поскольку одновременно можно выполнить более 90 тестов Safe Push.

Kotlin DSL

Команда IntelliJ Infrastructure управляет TeamCity с помощью Kotlin DSL. Он дает все преимущества полноценного языка программирования в сочетании с достоинствами предметно-ориентированного языка, предназначенного специально для конфигурирования пайплайнов.

В настоящее время экземпляр TeamCity содержит более 2000 проектов, 15 000 конфигураций сборки и почти 300 корней VCS. Команда не представляет себе, как можно управлять всем этим без Kotlin DSL.

«Кроме того, у нас почти 350 юнит-тестов только для самих настроек Kotlin. Не хотел бы я иметь со всем этим дело в YAML».

— Дмитрий Панов, техлид IntelliJ Infrastructure

Управление агентами

TeamCity предлагает эффективные возможности управления агентами, поэтому масштабировать CI/CD-пайплайны можно легко и без проблем. В отличие от CI/CD-систем на основе YAML, где требуются сложные обходные маневры — якоря, операторы go-to, ручная настройка логики повторных попыток, — TeamCity упрощает процесс благодаря встроенным возможностям настройки агентов.

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

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

Благодаря масштабированию TeamCity обрабатывает большие объемы данных, поддерживая очереди из более чем 10 000 сборок, при динамическом управлении более чем 5000 агентов. Одна из самых удобных функций TeamCity — возможность работы с прерываемыми экземплярами AWS. Если AWS отзывает экземпляр, TeamCity автоматически перезапускает сборку на другом агенте, предотвращая перебои в работе.

Метрики, отслеживаемые командой

При управлении CI/CD-платформой для сотен разработчиков, на которой ежедневно выполняются тысячи сборок, важно отслеживать самые существенные метрики. TeamCity «из коробки» предлагает ряд диагностических инструментов и индикаторов, а также может экспортировать метрики в формат Prometheus, позволяя создать пользовательские панели мониторинга для самых сложных вариантов использования решения.

«В TeamCity есть основные строительные блоки, скажем, статистика по сборкам или тестам. На основе эти данных мы можем получить информацию более высокого уровня».

— Алексей Смирнов, разработчик, сотрудник команды .NET Infrastructure

Вот основные метрики, которые команда IntelliJ Infrastructure постоянно отслеживает, стремясь оптимизировать CI/CD-пайплайн с помощью TeamCity.

Количество сборок в день

Команда ежедневно отслеживает около 158 000 сборок, чтобы лучше оценить нагрузку и производительность. Число сборок само по себе не слишком важно, но все равно это важная метрика для прогнозирования нагрузки на билд-агенты.

Одновременное выполнение Safe Push

В любой момент времени одновременно выполняется 80–90 проверок Safe Push. Команде важно отслеживать, сколько времени занимает каждая такая проверка: чем быстрее она выполняется, тем быстрее обрабатывается сборка.

Эффективность повторного использования сборок

Команда анализирует, сколько сборок используются повторно при новых прогонах тестов, сокращая лишнюю нагрузку и экономя ресурсы.

Выполнение тестов

Одна композитная сборка в проекте IntelliJ TeamCity содержит почти 700 000 тестов.

Команда отслеживает более 700 000 тестов в каждой цепочке Safe Push, чтобы выявить все ошибки. Кроме того, команда измеряет неустойчивость тестов, автоматически повторяя тесты, завершившиеся ошибкой, и отключая неустойчивые для дополнительного исследования.

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

Использование агентов

Команда отслеживает более 5000 агентов в облаке AWS и на физических машинах, оптимизируя распределение ресурсов с учетом таких функций, как повторное использование сборок. В результате удалось сократить время сборки примерно на 30 %.

Что можно улучшить в TeamCity

Команда IntelliJ Infrastructure использует TeamCity каждый день для решения огромного числа задач. Этот продукт помогает им справиться со многими проблемами, но тем не менее, есть вещи, которых им не хватает.

Возможности для отдельных команд

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

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

Управление отключенными тестами

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

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

Заключение

Команда IntelliJ Infrastructure смогла с помощью TeamCity выстроить эффективный масштабируемый CI/CD-пайплайн, упростив процесс сборки, оптимизировав использование ресурсов и значительно сократив время выполнения. Благодаря внедрению механизма Safe Push, повторному использованию сборок и автоматизации повторных проходов тестов они сократили время выполнения сборки на 30 %, обеспечив бесперебойную отправку изменений в коде для 700–800 разработчиков.

Пример команды IntelliJ Infrastructure доказывает, что TeamCity — не просто CI/CD-инструмент, а становой хребет крупных проектов по разработке ПО.