Сфера деятельности: Разработка ПО

Используемые продукты JetBrains: TeamCity

Число сотрудников: 200

Страна: США

Gradle

Gradle Build Tool — популярный инструмент автоматизации сборки с открытым исходным кодом, который используется миллионами разработчиков для сборки, тестирования и развертывания программных проектов. Он лежит в основе пайплайна непрерывной доставки во многих известных SaaS-компаниях мира, включая Netflix и LinkedIn.

Как при помощи TeamCity в Gradle запускают 30 000 успешных сборок в день

Gradle Build Tool — популярный инструмент автоматизации сборки с открытым исходным кодом, который используется миллионами разработчиков для сборки, тестирования и развертывания ПО. TeamCity — это универсальное CI/CD-решение, обеспечивающее гибкость при использовании самых разных методов и процессов разработки.

Узнайте, как при помощи TeamCity в Gradle запускают десятки тысяч сборок в день и при этом контролируют уровень сбоев.

«Мы используем TeamCity в качестве CI-системы уже больше десяти лет. В ней есть все, что нам нужно, — из коробки. Мы ценим TeamCity за надежность, а Kotlin DSL за удобство настройки пайплайнов сборки».

— Петр Ягельский, технический директор Gradle Build Tool

О компании Gradle

Компания Gradle — создатели одного из самых популярных инструментов автоматизации сборки с открытым исходным кодом — Gradle Build Tool, а также платформы Gradle Enterprise, повышающей продуктивность разработчиков. Штаб-квартира Gradle находится в Сан-Франциско, в компании работают 200 сотрудников в 30 странах. Инструментами Gradle пользуются миллионы разработчиков по всему миру.

Более 100 инженеров Gradle работают над двумя основными кодовыми базами — Gradle Build Tool и Gradle Enterprise, — каждая из которых содержит миллионы строк кода. TeamCity используется для обеих кодовых баз, но мы хотим рассказать именно о Gradle Build Tool.


TeamCity в Gradle

Вот уже 10 лет команда Gradle Build Tool полагается на TeamCity в процессе CI/CD. За это время команда не пропустила ни одного обновления TeamCity — в распоряжении разработчиков Gradle всегда была самая свежая версия продукта с новейшими функциями.


Технологии, используемые в Gradle

В качестве системы контроля версий команда Gradle Build Tool использует Git и GitHub. Код пишут на Java, Kotlin и Groovy. Конечно же, используются собственные продукты: Gradle Build Tool для автоматизации сборки и Gradle Enterprise для ускорения сборки и анализа сбоев. TeamCity служит для запуска всего, что не нужно запускать локально: сборок, развертываний, заданий cron и многого другого.


CI-пайплайн Gradle

Gradle Build Tool проходит всестороннее тестирование, проверяющее корректность работы продукта в разных операционных системах, с разными версиями Java и другими компонентами. Полная сборка, готовая к выпуску, включает в себя более 150 тысяч тестов. Кроме того, прежде чем попасть в основную ветку, изменения должны успешно пройти тесты на производительность. Это требует сложной CI-конфигурации с сотнями агентов сборки.

Типы билд-агентов

Gradle использует агенты сборки для Windows, Linux и macOS. Примерно половина агентов — это физические машины. Команда также пользуется спотовыми агентами Amazon EC2. Это позволяет сохранять скорость сборки даже при высоком спросе.

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

Ключевые метрики

Конфигурация TeamCity для Gradle Build Tool есть в открытом доступе. Главная ветка (master) включает в себя около 500 конфигураций сборки, организованных в сложную цепочку. Петр отмечает: «В Gradle очень активно используются цепочки сборок: мы просто не можем без них обойтись».

Из-за сложности цепочек команда Gradle конфигурирует пайплайны при помощи Kotlin DSL.

Фрагмент цепочки сборок Gradle Build Tool. Чтобы посмотреть полную версию, можете войти в систему как гость.
Фрагмент цепочки сборок Gradle Build Tool. Чтобы посмотреть полную версию, можно войти в систему как гость.

У Gradle есть 200 постоянных агентов сборки и 200 дополнительных эластичных агентов EC2 для управления всплесками, подключенных через облачные профили. Общее время выполнения сборок в неделю составляет 283 дня (или 6792 часа).

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

В Gradle используются цепочки сборок, и TeamCity помогает команде сэкономить много времени за счет повторного использования сборок.

Число используемых агентов
Число используемых агентов

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

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

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

Контроль времени получения обратной связи

Быстрая обратная связь — важный аспект любого CI-решения. Отслеживание времени обратной связи помогает команде Gradle, отвечающей за продуктивность разработчиков, понять, сколько нужно ждать инженерам, прежде чем их пул-реквесты будут объединены с основной веткой.

Среднее время ожидания в очереди для сборок в Gradle
Среднее время ожидания в очереди для сборок в Gradle

Для этого команда Gradle следит за Trigger-сборкой. Это композитная сборка, которая объединяет результаты других сборок, связанных между собой зависимостями от снэпшотов, и показывает их в едином представлении.

Скорость обратной связи зависит от сложности пул-реквеста. Обратная связь по простым пул-реквестам приходит в течение 10 минут, а в более сложных случаях это может занять до часа. Поскольку Gradle — проект с открытым исходным кодом, все пул-реквесты, поступающие от пользователей GitHub, проходят через точно такой же процесс сборки.

Проекты в master-ветке Gradle Build Tool в TeamCity
Проекты в master-ветке Gradle Build Tool в TeamCity

Триггеры сборок

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

Некоторые ветки, например master и release, обрабатываются иначе. В них сборка запускается при любом изменении.

Kotlin DSL: кардинальное изменение

Kotlin DSL существенно изменил подход команды Gradle к управлению сложными зависимостями сборки. Когда настройки проекта хранятся в виде кода, можно использовать одну и ту же логику сборки для разных проектов, последовательно применять обновления к разным конфигурациям и управлять пайплайнами системно.

Kotlin DSL позволяет создавать и тестировать зависимости сборки с меньшими усилиями. Практически во всех проектах команда Gradle применяет Kotlin DSL, не используя возможности редактирования через интерфейс.


Gradle Build Tool + TeamCity: максимальная эффективность

TeamCity ускоряет весь процесс непрерывной интеграции и доставки для Gradle. С помощью TeamCity команда Gradle Build Tool успешно запускает 30 000 сборок в день, при этом контролируя уровень сбоев.

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

Kotlin DSL обеспечивает высочайший уровень гибкости, что позволяет команде Gradle Build Tool быстро создавать сложные цепочки сборки и тестировать их. Команда также запускает тесты на конфигурационных файлах Kotlin DSL. Конфигурация TeamCity, используемая в Gradle, доступна на GitHub.

И конечно, команда Gradle Build Tool ценит TeamCity за надежность. Они обновляют TeamCity, как только выходит новая версия, и редко сталкивается с какими-либо проблемами. TeamCity управляет более чем 400 агентами сборки, но команде практически никогда не приходится устранять проблемы с подключением или агентами сборки.


Масштабирование инфраструктуры с ростом команды

Команда Gradle Build Tool намерена масштабировать свою инфраструктуру по мере роста команды. Даже если в будущем численность команды удвоится, Gradle стремится сохранить текущее время обратной связи или даже сократить его.

Они планируют добиться этого за счет внедрения практик Developer Productivity Engineering, повышения уровня автоматизации и увеличения количества агентов сборки.

Контакты

Похожие истории клиентов

Picnic

Иван Бабенков, ведущий разработчик, Picnic

Нам было необходимо решение, которое покрывало бы все наши сценарии использования CI. Кроме того, нам нужны были автономные агенты, чтобы отслеживать, какое ПО у нас запущено и какие именно инструменты используются. Благодаря TeamCity Cloud с использованием автономных агентов мы получили индивидуальное решение. Его удобно использовать нашей команде, насчитывающей 300 разработчиков, и в результате наша производительность вышла на новый уровень.

Gearbox

Филлип Петерсон, старший релиз-инженер

Наша компания довольно долго пользовалась одним инструментом. Мы давно хотели его заменить, но не могли найти ничего подходящего. А потом коллеги, которые раньше работали в другой геймдев-компании, сказали: «А мы вот пользовались TeamCity». Мы стали разбираться и поняли, что TeamCity решает массу наших проблем.

Playrix

Юрий Труфанов, главный технический директор технологической платформы

Мы остановились на гибридном решении, включающем в себя TeamCity Cloud Profiles и AWS. Кроме того, у нас есть локальные компьютеры для билд-агентов. Такое сочетание позволяет нам проводить любое количество сборок в течение рабочего дня, а в остальное время гарантирует наличие минимально необходимого количества агентов. В результате мы можем выполнять любые операции в любом удобном месте.

Другие истории клиентов