Масштабная трансформация
Сбербанка в прямом эфире
LIVE

Опыт использования Circle CI

В этой статье я расскажу про личный опыт использования Circle CI — на мой взгляд, самого удобного сервиса непрерывной сборки и деплоя. Сейчас мы гоняем в CI больше 6000 тестов, а процесс от мерджа в мастер до появления на проде у нас занимает от трёх до четырёх минут.

В закладки

Это — сокращенная версия материалов о Circle CI, которые выходили в моём Telegram-канале. Обязательно подпишитесь, если интересуетесь управлением технически-сложными проектами в стартапах.

Параллельность и оплата за время

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

Для ребят с большим количеством тестов Circle CI даёт два инструмента: более быстрые контейнеры и разбиение тестов на несколько машин. Мы используем оба варианта.

Более быстрые контейнеры подразумевают разделение тестов на параллельные потоки средствами самого тестраннера — мы используем обычный pytest-xdist с двумя потоками на ядро. Добавляем два ядра — получаем в два раза больше потоков, а значит, примерно в два раза большую производительность. «Примерно» получается из-за затрат на шедулинг — тестраннеру нужно распланировать, какой тест на каком ядре гонять.

Сейчас чтобы вам включили возможность настраивать количество ядер, придётся связаться с поддержкой (подробнее тут, смотри «resource_class»), которая вам предложит специальный вариант оплаты — не за количество контейнеров, как на официальном сайте, а за машинное время, которое вы тратите на сборку. Я советую соглашаться — в mtrl.ai, перейдя на поминутную оплату, мы стали экономить около 50% стоимости услуг Circle CI.

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

В итоге параллельность позволяет нам минимальными затратами добиться показателей из картинки выше.

Ночные сборки

Каждую ночь мы собираем проект, тегаем текущей датой и раскладываем образы по вспомогательным серверам. Это популярная практика, которая даёт автоматически обновляемые песочницы и тестовые стенды в обмен всего на десяток строк в YAML-файле.

Кроме приложения, при помощи Circle CI мы каждую ночь собираем докер-образы с нашей базой данных, доступные всей команде. Такие образы гарантируют, что фронтендер всегда работает со свежими данными с прода — больше никаких рыбных текстов или таблиц, поехавших после публикации на проде. Всего одной командой можно забрать в локальную БД актуальный снимок данных компании.

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

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

Образ с базой нужно тегать текущей датой — так вы получите (почти) полный автоматический бэкап своей базы прямо в hub.docker.com.

Деплой

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

Воркфлоу публикации приложения на Django

Самый простой способ — опубликовать на железки. У нас так было первый год, когда инфраструктура была простой и маленькой. Читаем статью Deploying Django, берём какой-нибудь fabric и пишем скрипт, который публикует файлы и рестартует демона. Вот пример fabfile.py, который мы используем на простых проектах.

Опубликовать в кластере — у нас это swarm. Выстраиваем чуть более сложный воркфлоу, зато получаем масштабируемость. Делаем две задачи — собрать или отправить в реестр докер-образ и обновить сервисы в кластере. Вот пример конфиги для двух этих задач. В конфиге используется моя собственная утилита под названием d, в современных сетапах для уменьшения бойлерплейта вместо него лучше использовать Orbs.

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

{ "author_name": "Fedor Borshev", "author_type": "self", "tags": [], "comments": 13, "likes": 27, "favorites": 17, "is_advertisement": false, "subsite_label": "dev", "id": 56022, "is_wide": true, "is_ugc": true, "date": "Wed, 23 Jan 2019 10:41:23 +0300", "is_special": false }
Маркетинг
Как контент-маркетинг в строительной индустрии может поднять продажи на 80% — кейс концерна Wienerberger
С весны 2019 года мы в агентстве SALO занимаемся digital-маркетингом для международного концерна Wienerberger…
Объявление на vc.ru
0
13 комментариев
Популярные
По порядку
Написать комментарий...
0

Почему Circle CI, а не мегапопулярный Jenkins?

Ответить
0

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

Ответить
0

Ну, как я понимаю, у вас просто есть бюджет на SaaS, многие берут дженкинс ввиду бесплатности и разворачивают у себя где-нибудь в контейнере.
Я бы, честно говоря, пожалел бы 300$ в месяц на столь небольшую команду, но как говорится, если есть бюджет, то можно что угодно)

Ответить
2

Люди, которые бейбиситят Дженкинс, работают у вас бесплатно?

Ответить
2

ну вы преувеличиваете. в большинстве случаев достаточно один раз его настроить и он работает. да, на разворачивание уйдет больше времени, чем заюзать saas, но это делается один раз. и это не требует наличия в команде отдельно обученного человека. с большой долей вероятности, в команде имеется разработчик, который умеет не только в код и, скорее всего, даже не один. тем более порог входа в тот же дженкинс не такой большой. за те же 300 бачей в месяц можно купить почти десяток тачек в том же хетцнере и иметь ~70 ядер в распоряжении 24/7, на которых помимо сиая можно еще много чего полезного развернуть. но опять же, все это актуально для тех, кто задумывается о бюджете и как сэкономить на инфраструктуре.

Ответить
0

А чому не Travis CI ? SaaS, бесплатно, деплой, все плюшки.

Ответить
0

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

Ответить
0

Сколько платите?

Ответить
0

~$300 за 8 человек и 15 активных проектов

Ответить
0

Интересно узнать поподробнее про поминутную оплату. Я так понимаю они округляют до следующей минуты (61 секунда будет считаться за 2 минуты)? Интересно сколько стоит одна минута одного такого ядра (на их сайте не написаны эти цены)?

Ответить
0

В доке написано «is calculated on a per second usage rounded up to the nearest whole second». Предположу, что 61 секунда это одна минута, а 91 — две, но это не точно.

Про детальные цены лучше спросить в самом Circle CI, не уверен, что эта информация публична.

Ответить
0

Мм, поясните, пожалуйста, не врубаюсь - как это так (первая картинка) - самый медленный тест работал 400+ млн секунд, а в целом тестран - меньше 3 минут

Ответить
0

Тесты работают параллельно, в нашем случае в 40 потоков.

Ответить

Комментарии