Сфера деятельности: Доставка продуктов

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

Число сотрудников: 10,000

Страна: Нидерланды

Picnic

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

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

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

О компании

Пожалуйста, представьтесь: как вас зовут и кем вы работаете.

Меня зовут Иван Бабенков, я ведущий разработчик в компании Picnic. Вхожу в команду Java Platform, участвовал в выборе нового решения для непрерывной интеграции и его внедрении.

Чем занимается ваша компания?

Picnic предлагает совершенно новый подход к покупке продуктов. Все начиналось с одного голландского города, а сегодня приложение охватывает 200 городов в трех странах: Германии, Нидерландах и Франции. Picnic не привязан к магазинам в оффлайне: это именно мобильное приложение, позволяющее миллионам пользователей быстро и удобно приобретать продукты.

Знаменитый электромобиль Picnic
Доставку обеспечивают ставшие уже знаменитыми электромобили

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

Сейчас в Picnic больше 300 штатных разработчиков. Мы используем GitHub, Java, Python, Swift, Kotlin, TypeScript, Angular, React, Android, iOS, MongoDB, Spring Boot, и это далеко не полный список.


Сложности до перехода на TeamCity

Какие решения для CI/CD вы использовали раньше и почему решили искать другие варианты?

Мы заинтересовались JetBrains TeamCity в конце 2021 года, когда стало ясно, что прежнее решение для непрерывной интеграции мы переросли. Главных проблем было две: низкая скорость сборки и длинные очереди сборок. В пиковые моменты между постановкой некоторых сборок в очередь и их запуском проходило около часа.

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

Новое решение для непрерывной интеграции должно было поддерживать весь стек используемых технологий и помочь нам стандартизировать сборку и тестирование разрабатываемых приложений. Для разработки бэкенда мы используем Java и Python, в качестве системы контроля версий — GitHub, для мобильной разработки — Kotlin, Swift и React Native.

Какие варианты решений вы рассматривали? Какие критерии были ключевыми при выборе инструмента CI/CD?

Сначала мы составили список из 10 решений разных поставщиков, потом сократили его до трех предпочтительных: CircleCI, TeamCity и GitHub Actions. Нашей главной задачей было сократить время ожидания в очереди и повысить производительность непрерывной интеграции за счет сокращения времени сборки.

Еще одно важное требование — наличие автономных агентов. Анализируя варианты, мы поняли, что прежнее решение довольно медленно обновляло инструментарий агентов. Для каждой сборки мы тратили от 2 до 5 минут просто на установку инструментов. Учитывая, что в среднем сборка занимает около 9 минут, довольно бессмысленно тратить на предварительную установку инструментов еще по 3 минуты. В итоге мы решили, что нам нужны автономные агенты, у которых будет самый новый инструментарий, соответствующая производительность и вообще все необходимое, чтобы сразу запускать сборку.

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


Количественные и CI/CD-метрики

У нас около 300 пользователей CI-решения, большинство из них довольно активно коммитят по почти 200 проектам. Эти проекты организованы в TeamCity в достаточно четкую иерархическую структуру и используют более 120 корней VCS.

Наряду с этим у нас 40 билд-агентов для одновременной работы по 40 сборкам. Каждый день мы запускаем почти 1100 сборок, общее время в день — почти 10 000 минут. Развертывание агентов занимает около 2 минут, и сборки почти не задерживаются в очереди дольше этого времени.

За месяц это дает нам дополнительно почти 300 000 минут на сборку.


Какую часть процесса разработки в вашей компании поддерживает TeamCity?

Мы используем 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. Эту проблему можно решить, используя агенты с длинным жизненным циклом, обрабатывающие несколько сборок, поэтому, возможно, нам стоит перейти на спотовые инстансы.


Вы используете конфигурацию как код или Kotlin DSL? Какого подхода вы придерживаетесь?

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

Все конфигурации сборки хранятся в соответствующих репозиториях в виде кода Kotlin. Мы создали собственный DSL поверх TeamCity Kotlin DSL, и теперь для определения пайплайна нам хватает 20 строчек кода, а то и меньше.

Сниппет Picnic
Это простейшая конфигурация базового пайплайна: сюда входит стандартная сборка проекта, отдельная сборка для дополнительных проверок пулреквеста и сборка для запланированного статического анализа.

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

Кроме этого, есть отдельное задание для статического анализа кода и еще одно для статического анализа кода, используемого в SonarCloud — оно выполняется каждую ночь. Все они входят в стандартный пайплайн. Все это вы получаете для Java-приложений с самого начала, достаточно определить хотя бы основные параметры пайплайна.

Некоторые наши команды проводят много компонентных тестов (BDD). Их мы пишем на Python, а основное приложение пишется на Java и пакуется в образ Docker. После этого мы запускаем среду Docker Compose на билд-агенте с реальной инфраструктурой (БД и прочее), имитируя сторонние сервисы. Тесты поведения выполняются на приложении, запущенном в Docker Compose.

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

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

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

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

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

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

Какие преимущества дает вам использование TeamCity? С какими проблемами вы столкнулись?

Вот что нам больше всего нравится в TeamCity:

Настройка билд-агентов по умолчанию. Когда мы впервые познакомились с TeamCity, то обратили внимание, что решение использует агенты с оптимизацией вычислений и подключенным SSD. В результате его производительность выше, чем у других CI-инструментов. Предоставленные агенты мы не используем, но зато обеспечили для собственных агентов инстансы с оптимизацией вычислений, и производительность заметно выросла.

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

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

Что касается проблем — было бы здорово получать общие метрики по всем проектам, сборки которых делаются в TeamCity. Сейчас решение предоставляет метрики только для отдельных проектов, а посмотреть общие метрики, допустим, для всех проектов на Java невозможно.

Кроме того, изучение Kotlin DSL требует больших усилий, особенно если вы не очень знакомы с Java.


Планы на будущее

Сейчас мы перевели все проекты на TeamCity и хотим поэкспериментировать с билд-агентам, спотовыми инстансами и т. п.

Чтобы все сделать правильно, нужно регулярно получать метрики сборок. Все они есть в TeamCity, но нам мешает то, что мы не можем получить общие метрики по всем проектам и посмотреть, как они меняются.

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

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

Еще мы планируем расширить сквозное тестирование. Это будет еще один проект в TeamCity. После этого надо будет еще раз оценить, стоит ли полностью переносить в TeamCity наш CI/CD-пайплайн.

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

Brightify

Тадеас Криш, сооснователь и технический директор Brightify

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

Miquido

Петр Полус, технический руководитель фронтенд-разработки, Miquido

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

Tangunsoft

Усонг Ким, руководитель азиатско-тихоокеанского направления и менеджер по партнерству, Tangunsoft

JetBrains помогает писать код профессионально и чисто, обеспечивая высокое качество и легкость в поддержке.

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