Неделя GitLab CI на Хабре! В 2015 году мы уже писали о встроенной в GitLab системе Continuous Integration. GitLab часто ругают за предательство идеалов UNIX way и интеграцию слишком большого количества функций в одно приложение. Зато насколько удобно пользоваться этими функциями! За те полтора года, что прошли с момента нашей публикации, ребята сделали «Environments», добавили возможность сделать кнопку «раскатать на прод» и множество других улучшений. Под катом я расскажу о накопленном опыте, как небольшим командам автоматически собирать и выкладывать на прод/стейдж не только скрипты Voximplant для телефонии, но и другие проекты — сайты и сервисы.
Ветки или окружения?
Когда мы делаем автоматическую сборку и выкладку наших проектов, то на входе получаем вопрос: как определять, что и куда выкладывать? Есть несколько подходов. И в прошлой статье я описал самый простой: система CI собирает и выкладывает в зависимости от ветки. Пушим в «master» (или в «dev», если у нас «master stable»), и наша сборка выкладывается на стейджинг. Мерджим в «prod» (или в «master», если у нас «master stable»), и сборка выкладывается на прод. У подхода есть плюсы и минусы. Лично мне в таком подходе не очень нравится двойное назначение веток, для многих микросервисов за глаза хватает одного «master», а «prod» превращается в кнопку «выложить на прод». Плюс, тестирование веток превращается в интересную историю.
Второй вариант, который авторы GitLab предложили в версии 8.9, это отдельная абстракция для «как собирать и куда выкладывать». Абстракция называется «environments» и позволяет раскатывать сборку по нажатию кнопки в пользовательском интерфейсе GitLab. Выглядит это следующим образом: в YAML-файле конфигурации Continuous Integration мы задаем произвольное имя Environment и пишем код для сборки и выкладки:
Все, что делает абстракция, это добавляет кнопку «раскатать сюда» в интерфейс GitLab. Очень удобно на стейджинг раскатывать автоматически, а на прод — по нажатию на кнопку. На стейджинг из «master» можно раскатывать автоматически (отсутствует when: manual и указано only: master), а в остальные окружения и из веток — по нажатия на кнопку:
Боремся с копипастой
Сценарий Continuous Integration пишется на YAML. Это такой Python-образный JSON с несколькими бонусами. Один из таких бонусов, поддержка которого появилась в последних версиях, это anchors – чтобы пометить часть конфига идентификатором, а затем повторно использовать его в другом месте. Это позволяет написать обобщенный скрипт сборки и раскатывания, а затем «скопипастить» его для разных окружений, модифицируя только переменные окружения. Например, на платформе Voximplant NDFLka.ru собрали сервис, автоматически распределяющий входящие звонки по сложной бизнес-логике. Для такого сервиса можно сделать dev и prod приложения с разными номерами телефонов (для dev можно использовать номер телефона в «Готем Сити», аренда которого стоит один цент в месяц), а затем раскатывать dev автоматически, а prod — уже вручную, ответственным человеком, по результатам тестирования:
Используем Docker для сборки
Как и все современные CI, GitLab просит вас запустить «runner» на каком-нибудь компьютере, и скрипты, которые вы прописываете в «script», запускаются на этой машине. Если у вас много разных проектов, то для их сборки и деплоя могут понадобится разные, зачастую несовместимые с собой версии тулчейнов. GitLab предлагает решение этого вопроса, бесшовно интегрируясь с docker. Достаточно задать образ нужного контейнера в поле «image», и GitLab выполнит команды «script» в указанном контейнере. Более того, для разных шагов сборки можно использовать разные контейнеры, передавая между ними результаты сборки как «artifact». На практике удобно написать собственный Docker-контейнер для сборки проекта, держать его в том же Git-репозитории, что и сам проект, и указывать через git url:
Чего стоит ожидать?
Gitlab очень быстро развивается. В течении последних нескольких месяцев мы получили отображение CI в реальном времени, первые тестовые имплементации автоматического деплоя в kubernetes и множество других небольших улучшений. Огромный комбайн – это не всегда хорошо. Но в случае с GitLab я в ребят верю, если они будут продолжать развитие продукта, то мы можем получить лучшее CI-решение, бесшовно интегрированное с управлением исходниками и системой работы с задачами. Ваше мнение?
Автор: Voximplant
