Сфера деятельности: Доставка продуктов
Используемые продукты JetBrains: TeamCity
Число сотрудников: 10,000
Страна: Нидерланды
«Нам было необходимо решение, которое покрывало бы все наши сценарии использования CI. Кроме того, нам нужны были автономные агенты, чтобы отслеживать, какое ПО у нас запущено и какие именно инструменты используются. Благодаря TeamCity Cloud с использованием автономных агентов мы получили индивидуальное решение. Его удобно использовать нашей команде, насчитывающей 300 разработчиков, и в результате наша производительность вышла на новый уровень».
— Иван Бабенков, ведущий разработчик, Picnic
Меня зовут Иван Бабенков, я ведущий разработчик в компании Picnic. Вхожу в команду Java Platform, участвовал в выборе нового решения для непрерывной интеграции и его внедрении.
Picnic предлагает совершенно новый подход к покупке продуктов. Все начиналось с одного голландского города, а сегодня приложение охватывает 200 городов в трех странах: Германии, Нидерландах и Франции. Picnic не привязан к магазинам в оффлайне: это именно мобильное приложение, позволяющее миллионам пользователей быстро и удобно приобретать продукты.
Помимо мобильного приложения для пользователей, мы разрабатываем большинство других необходимых для бизнеса систем, в том числе собственное решение для управления складом. Кроме того, мы делаем инструменты для водителей, которые повышают безопасность движения, помогают планировать маршруты и оптимизировать получение заказов на складе и т. д.
Сейчас в Picnic больше 300 штатных разработчиков. Мы используем GitHub, Java, Python, Swift, Kotlin, TypeScript, Angular, React, Android, iOS, MongoDB, Spring Boot, и это далеко не полный список.
Мы заинтересовались JetBrains TeamCity в конце 2021 года, когда стало ясно, что прежнее решение для непрерывной интеграции мы переросли. Главных проблем было две: низкая скорость сборки и длинные очереди сборок. В пиковые моменты между постановкой некоторых сборок в очередь и их запуском проходило около часа.
Прежнее решение позволяло сделать только одно: заметно увеличить количество и размер билд-агентов, чтобы сократить общее время сборки. Однако это не решало ключевую проблему: скорость сборки оставалась низкой. Мы решили найти новое решение, чтобы повысить качество и скорость.
Новое решение для непрерывной интеграции должно было поддерживать весь стек используемых технологий и помочь нам стандартизировать сборку и тестирование разрабатываемых приложений. Для разработки бэкенда мы используем Java и Python, в качестве системы контроля версий — GitHub, для мобильной разработки — Kotlin, Swift и React Native.
Сначала мы составили список из 10 решений разных поставщиков, потом сократили его до трех предпочтительных: CircleCI, TeamCity и GitHub Actions. Нашей главной задачей было сократить время ожидания в очереди и повысить производительность непрерывной интеграции за счет сокращения времени сборки.
Еще одно важное требование — наличие автономных агентов. Анализируя варианты, мы поняли, что прежнее решение довольно медленно обновляло инструментарий агентов. Для каждой сборки мы тратили от 2 до 5 минут просто на установку инструментов. Учитывая, что в среднем сборка занимает около 9 минут, довольно бессмысленно тратить на предварительную установку инструментов еще по 3 минуты. В итоге мы решили, что нам нужны автономные агенты, у которых будет самый новый инструментарий, соответствующая производительность и вообще все необходимое, чтобы сразу запускать сборку.
Кроме того, нам нужно было облачное решение для непрерывной интеграции. Picnic стремится минимизировать число используемых систем, поэтому мы хотели найти управляемое решение, которым нам не приходилось бы заниматься самостоятельно. При этом автономные агенты в облаке позволили бы нам контролировать запускаемое ПО и используемые инструменты. В результате мы можем гибко управлять средой сборки — и используемым оборудованием, и установленными инструментами, а вот сервером непрерывной интеграции нам заниматься не нужно.
У нас около 300 пользователей CI-решения, большинство из них довольно активно коммитят по почти 200 проектам. Эти проекты организованы в TeamCity в достаточно четкую иерархическую структуру и используют более 120 корней VCS.
Наряду с этим у нас 40 билд-агентов для одновременной работы по 40 сборкам. Каждый день мы запускаем почти 1100 сборок, общее время в день — почти 10 000 минут. Развертывание агентов занимает около 2 минут, и сборки почти не задерживаются в очереди дольше этого времени.
За месяц это дает нам дополнительно почти 300 000 минут на сборку.
Мы используем TeamCity для всей внутренней разработки. Как только я открываю пулреквест в GitHub, CI-инструмент запускает сборку, проводит юнит-тесты, интеграционное и компонентное тестирование и дает обратную связь. На этом сфера ответственности TeamCity заканчивается: мы получаем артефакт сборки, который отправляется в репозиторий для дальнейшего развертывания.
Все стандартные билд-агенты и билд-агенты Linux запускаются в облаке AWS. Для iOS-приложений в нашей офисной сети есть несколько устройств Mac mini, подключенных к TeamCity. Собственно, команда iOS-разработки использовала локальную версию TeamCity еще до того, как мы перешли на TeamCity Cloud.
Агенты запускаются в инстансах «по требованию». В дальнейшем мы, возможно, перейдем на спотовые инстансы — кажется, это перспективный вариант.
Образы мы делаем сами, а для запуска автономных агентов используем конфигурации TeamCity Cloud Profile. По сути это машины EC2 в AWS. Для создания образов агентов в AWS мы используем TeamCity и Packer.
Эти агенты мы используем вместе с шаблонами запуска и конфигурациями Cloud Profiles в TeamCity, чтобы запускать билд-агенты по требованию. Сейчас у этих агентов короткий жизненный цикл — только одна сборка.
Мы обратили внимание, что время в очереди составляет около двух минут, из которых полторы занимает ожидание развертывания агента в AWS. Эту проблему можно решить, используя агенты с длинным жизненным циклом, обрабатывающие несколько сборок, поэтому, возможно, нам стоит перейти на спотовые инстансы.
Наша политика — отключить редактирование в интерфейсе TeamCity. Одна из наших целей — стандартизация пайплайнов, поэтому мы используем конфигурацию как код.
Все конфигурации сборки хранятся в соответствующих репозиториях в виде кода Kotlin. Мы создали собственный DSL поверх TeamCity Kotlin DSL, и теперь для определения пайплайна нам хватает 20 строчек кода, а то и меньше.
Например, вы получаете основную сборку Java-приложения. На ней выполняются все тесты, в том числе компонентные. Если тестирование завершилось успешно, артефакты сборки загружаются в нужный репозиторий.
Кроме этого, есть отдельное задание для статического анализа кода и еще одно для статического анализа кода, используемого в SonarCloud — оно выполняется каждую ночь. Все они входят в стандартный пайплайн. Все это вы получаете для Java-приложений с самого начала, достаточно определить хотя бы основные параметры пайплайна.
Некоторые наши команды проводят много компонентных тестов (BDD). Их мы пишем на Python, а основное приложение пишется на Java и пакуется в образ Docker. После этого мы запускаем среду Docker Compose на билд-агенте с реальной инфраструктурой (БД и прочее), имитируя сторонние сервисы. Тесты поведения выполняются на приложении, запущенном в Docker Compose.
TeamCity предоставляет Kotlin DSL, где можно вносить любые изменения в пайплайн сборки: менять шаги, триггеры, что угодно.
По умолчанию мы предлагаем командам идеальный типовой пайплайн, созданный командой, которая разрабатывает платформу. Например, в пайплайн сборки входят компонентные тесты: они выполняются тем же агентом в рамках того же задания.
У некоторых команд сотни компонентных тестов, которые, к сожалению, еще нельзя выполнять параллельно. В таких случаях можно разбить компонентные тесты поведения на тестовые наборы и сконфигурировать их как цепочку сборок.
Таким образом основная сборка создает артефакт и выполняет юнит-тесты, а также простые быстрые тесты. Если все прошло успешно, можно запустить параллельно любое необходимое число тестовых наборов и выполнять тесты в нескольких инстансах на разных агентах.
Вот что нам больше всего нравится в TeamCity:
Настройка билд-агентов по умолчанию. Когда мы впервые познакомились с TeamCity, то обратили внимание, что решение использует агенты с оптимизацией вычислений и подключенным SSD. В результате его производительность выше, чем у других CI-инструментов. Предоставленные агенты мы не используем, но зато обеспечили для собственных агентов инстансы с оптимизацией вычислений, и производительность заметно выросла.
Кроме того, очень нравится функция мониторинга производительности. Одной из главных проблем для команд, использующих эти пайплайны, был выбор размера инстанса. Мониторинг производительности помогает принять правильное решение и упрощает отладку.
Что касается проблем — было бы здорово получать общие метрики по всем проектам, сборки которых делаются в TeamCity. Сейчас решение предоставляет метрики только для отдельных проектов, а посмотреть общие метрики, допустим, для всех проектов на Java невозможно.
Кроме того, изучение Kotlin DSL требует больших усилий, особенно если вы не очень знакомы с Java.
Сейчас мы перевели все проекты на TeamCity и хотим поэкспериментировать с билд-агентам, спотовыми инстансами и т. п.
Чтобы все сделать правильно, нужно регулярно получать метрики сборок. Все они есть в TeamCity, но нам мешает то, что мы не можем получить общие метрики по всем проектам и посмотреть, как они меняются.
Если бы у нас была такая информация, мы могли понять, как оптимизировать процесс: что нужно улучшить, на чем сосредоточиться в первую очередь, как изменения, которые мы делаем, влияют на производительность. Пока что мы планируем разработать внешний сервис, который будет собирать нужную информацию. Если бы у решения была готовая функция, было бы намного удобнее!
Кроме того, мы планируем заняться оптимизацией, чтобы не тратить лишнее время на запуск агентов. Либо будем использовать агенты с длинным жизненным циклом, либо организуем пул агентов, которые будут готовиться заранее.
Еще мы планируем расширить сквозное тестирование. Это будет еще один проект в TeamCity. После этого надо будет еще раз оценить, стоит ли полностью переносить в TeamCity наш CI/CD-пайплайн.
Тадеас Криш, сооснователь и технический директор Brightify
Мы смогли значительно улучшить процесс код-ревью и настроить вебхуки Space для сборки каждой ветки, прошедшей ревью, в TeamCity и развертывания ее в тестовой среде для проверки перед объединением с целевой веткой. А еще с помощью Space легче следить за рабочим графиком коллег.
Петр Полус, технический руководитель фронтенд-разработки, Miquido
Мы выбрали продукты JetBrains по трем причинам: удобство использования, широкие возможности настройки и множество плагинов.
Усонг Ким, руководитель азиатско-тихоокеанского направления и менеджер по партнерству, Tangunsoft
JetBrains помогает писать код профессионально и чисто, обеспечивая высокое качество и легкость в поддержке.