Опыт использования 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.

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

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

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