Концепция CI/CD — это целая культура, важная часть DevOps-практик, благодаря которой разработчики получили возможность быстрее и эффективнее обкатывать и выводить в продакшен изменения программного обеспечения. Суть её становится понятна, если расшифровать аббревиатуру: непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD).
Терминология и определения CI/CD
Непрерывной интеграцией, CI, называют подход к разработке, при котором в код путём регулярных коммитов постоянно вносятся минорные изменения. А поскольку приложения даже внутри одной команды могут разрабатываться с помощью разных инструментов и платформ, сформировалась потребность в некоем механизме, который мог бы управлять интеграцией и тестированием этих изменений.
Получается, что задача CI заключается в том, чтобы наладить последовательный автоматизированный способ сборки, упаковки и тестирования продукта. Если наладить процесс непрерывной интеграции, разработчики будут делать частые коммиты, что улучшает коммуникацию в команде и повышает качество создаваемого продукта.
Непрерывная поставка, CD — это своего рода продолжение процесса непрерывной интеграции. Она отвечает за автоматизацию развёртывания приложений в разных окружениях: боевой системе, dev-среде и среде тестирования. Если возникает потребность настроить специфические параметры среды окружения, выполнить запросы к веб-серверу, БД и другим сервисам, необходимым для развёртывания приложения, это тоже осуществляется при помощи инструментов CI/CD.
CI/CD нуждается и в непрерывном тестировании, которое обычно реализуют в виде набора автотестов, которые выполняются в CI/CD-конвейере.
Базовые принципы CI/CD
Определение зон ответственности. Участник процесса разработки отвечает за конкретную часть кода, какую-то стадию жизненного цикла продукта. Например, разработчики и дизайнеры занимаются бизнес-логикой, отвечают за положительный UX использования приложения. Тестеры вводят сквозные функции, выполняют и приёмочные тесты. Девопсы занимаются логистикой кода. А конечные потребители дают обратную связь, когда попробуют поработать с приложением.
Уменьшение рисков. CI/CD-подход позволяет добиться более высокого уровня контроля целостности бизнес-логики, оптимизации хранения и обработки данных и в целом снижает риски, возникающие при разработке продукта силами распределённой или просто большой команды.
Быстрый фидбек. Автоматизация сборки и тестирования кода позволяет быстрее обогащать продукт новыми фичами. Сокращение количества информационных посредников обеспечивает получение быстрой обратной связи в случае, если на каком-то участке возникли проблемы.
Удобная среда. Команда разработки использует единое рабочее окружение для контроля версий и создания вспомогательных веток, отвечающих за качество, масштабируемость, отказоустойчивость программного продукта. По мере работы протестированный код поступает в основную ветку и тестируется уже там в составе единого решения.
Некоторые команды, использующие CI/CD-методологию и работающие в облаках, используют контейнеры вроде Docker, и системы оркестрации — как правило, Kubernetes. Технологии контейнеризации позволяют привести к какому-то общему виду процесс упаковки и поставки кода, упростить масштабирование и быстро удалять рабочие среды с непостоянной нагрузкой.
Этапы CI/CD
CI/CD-концепция подразумевает разделение процесса разработки на семь этапов:
- Написание кода. Разработчики пишут свою часть кода и вручную тестируют его. Затем написанный модуль отправляется в главную ветку с текущей версией продукта. Когда все отправленные модули опубликованы в главной ветке, начинается второй этап.
- Сборка. Используемая в команде система контроля версий выполняет автоматическую сборку и тестирование всего кода продукта. Стартовать сборка может как по команде, так и автоматически, ориентируясь на ранее заданный триггер.
- Ручное тестирование. После автотестов код изучается тестерами-людьми.
- Релиз. Когда тестирование завершено и в код внесены последние исправления, наступает момент релиза версии для клиентов.
- Развёртывание. Рабочая версия проекта размещается на боевом сервере разработчика. Пользователи могут взаимодействовать с продуктом и знакомиться с новыми функциями.
- Сопровождение и мониторинг. Приложение начинают использовать клиенты, а разработчики следят за пользовательским опытом и занимаются поддержкой продукта.
- Планирование. Исходя из анализа накопленного пользовательского опыта разработчики предлагают новые фичи и готовят план возможных улучшений. За этим следует первый этап цикла — написание кода.
Причины популярности CI/CD
У концепции CI/CD есть ряд преимуществ, которые и сделали её популярной в среде разработчиков. Что это за преимущества?
Уменьшение времени разработки. Скорость разработки растёт, необходимые изменения могут быть внесены за несколько дней (или недель, если проект сложный). Без CI/CD сроки могут серьёзно растянуться — на месяцы. Разработчики быстрпее тестируют и выкатывают обновления для приложений, опережая конкурентов.
Возможность тестирования вариантов. Разработчик может быстрее тестировать код, выполняя больше итераций. За счёт этого проще отсеять неудачные или неподходящие варианты кода на начальных этапах, сосредоточившись на более перспективных. Экономичное расходование времени разработчиков и ресурсов компании повышает эффективность компании.
Повышение качества. Комбинирование автотестов и ручной проверки обеспечивает более высокую чистоту кода, защищая от выявления ошибок на поздних стадиях. Снижается риск того, что на этапе релиза всплывёт какой-то неприятный баг, из-за которого застопорится работа над проектом.
Надо сказать, что и недостатки у CI/CD тоже есть. Например, высокие требования к опыту. Для перехода на новую концепцию все разработчики должны её понимать и иметь практические навыки. Присутствует и некоторая сложность в плане постоянного скоординированного взаимодействия команды/команд разработки. В идеале должен быть человек, который налаживает коммуникацию внутри коллектива.
Средства работы по CI/CD всё время меняются, поэтому перечислять их здесь не имеет смысла. Можно выделить лишь GitLab и Jenkins, которые считаются чуть ли не основными инструментами разработчика.
