Что такое CI/CD. Основы методологии непрерывной интеграции и  доставки

Определение CI/CD

CI/CD (Continuous Integration, Continuous Delivery) переводится как «непрерывная интеграция и доставка». Если говорить простым языком, CI/CD — это технология автоматизации тестирования и доставки новых модулей разрабатываемого проекта заинтересованным сторонам: разработчикам, аналитикам, инженерам качества, конечным пользователя и другим.

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

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

Инструменты CI/CD помогают настраивать конкретные параметры окружения, которые должны быть установлены во время развертывания. Кроме того, автоматизация CI/CD осуществляет необходимые запросы к веб-серверам, базам данных и другим сервисам, которые могут потребовать перезапуска или выполнения дополнительных действий в процессе развертывания приложения.

В чем отличие от DevOps

Иногда новички задаются таким вопросом, но он не совсем уместен. Ведь CI/CD является одной из практик в рамках DevOps, который, в свою очередь, представляет более обширный подход к организации всех процессов в IT-компании, включая взаимодействие команд разработки, финансовых специалистов и менеджеров. CI/CD же является ключевым элементом этой концепции.

Задача CI/CD-пайплайна

Рассмотрим подробнее функции CI/CD-пайплайна.

1. Регулярная интеграция кода в центральный репозиторий. Это помогает быстро находить и устранять конфликты и ошибки, а также улучшает общее качество кода.
2. Автоматический запуск тестов разных типов, таких как модульные, интеграционные и функциональные. Автоматизированное тестирование позволяет выявлять проблемы на ранних этапах разработки.
3. Автоматическая сборка программного обеспечения и его упаковка в пакеты или контейнеры. Это обеспечивает создание релизов приложения и подготовку его к развертыванию.
4. Автоматическая доставка или развертывание приложения в тестовые, стейджинговые или рабочие среды после успешного прохождения тестов. Это позволяет быстро и надежно предоставлять новые функции и изменения пользователям. Для автоматической доставки кода часто используют GitLab CI/CD.
5. Сбор метрик и логов приложения, а также создание отчетов о прохождении тестов. Это помогает получать обратную связь о работе приложения, его стабильности и производительности.

Принципы CI/CD

Управление версиями исходного кода

Наиболее значимым элементом непрерывной интеграции является управление версиями исходного кода. Этот процесс помогает находить и решать конфликты редактирования, возникающие между несколькими разработчиками, работающими с одной и той же кодовой базой. Существует множество инструментов для управления версиями, среди которых наиболее известными являются Git и Subversion. Системы контроля версий являются основой для продуктов, предлагающих «CI как услугу».

Автоматизированное тестирование

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

Разработчики проводят эти тесты в процессе разработки, чтобы удостовериться, что добавленный код не ухудшает уже существующие возможности. Для автоматизации процесса тестирования можно применять внешние инструменты. Сервисы CI автоматически запускают тестовые сценарии проекта, когда происходит заранее определенное пользователем событие. Например, когда разработчик отправляет код через систему контроля версий, это действие инициирует автоматический запуск полного набора тестов.

Автоматизация сборки

Сборка проекта — артефакт, предназначенный для фиксации состояния текущей версии релиза в процессе разработки программного обеспечения. Она распространяется среди пользователей через различные сети. Инструменты CI содействуют оптимизации процесса сборки, используя автоматические триггеры в системе контроля версий. Например, триггером может быть слияние нового кода с основной веткой в кодовой базе, после чего сборка загружается на удаленный сервер, чтобы пользователи могли ее скачать.

Автоматизация развертывания

Готовые к распространению сборки проходят этап развертывания. Результаты этого процесса могут варьироваться в зависимости от типа проекта. Например, для веб-проектов развертывание осуществляется на публичных веб-серверах, где артефакт, созданный во время сборки, копируется на серверы. Процесс развертывания для мобильных устройств и настольных ПК отличается и может включать загрузку в магазин приложений, откуда пользователи смогут скачать данное приложение.

Сопутствующие принципы

Сегрегация ответственности заинтересованных сторон. Участники процесса разработки и потребители готового проекта разделяют между собой ответственность за ту или иную стадию жизненного цикла продукта. Разработчики и дизайнеры проектируют бизнес-логику, а также обеспечивают положительный пользовательский опыт взаимодействия с готовой системой. Инженеры по качеству вводят сквозные функции и приемочные тесты, DevOps-инженеры организуют логистику кода, а пользователи дают обратную связь по результатам использования системы.

Снижение риска. Каждая группа участников процесса разработки минимизирует возможные риски при прохождении продукта через стадии жизненного цикла (контроль целостности бизнес-логики, пользовательского опыта, оптимизация хранения и обработки данных, миграции и пр.).

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

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

Этапы CI/CD

Написание кода

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

2. Затем разработчик вносит изменения в форке или на локальной копии. Рекомендуется создавать новую ветку и работать в ней.

3. Далее формируется pull-реквест — запрос на слияние с основной веткой. В процессе pull-реквеста можно проверить все предложенные изменения, обсудить их и достичь консенсуса.

5. После утверждения всех изменений они объединяются с основной веткой репозитория.

Сборка

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

Для автоматизации сборки могут использоваться различные системы. Наиболее популярные из них — Jenkins, Bitbucket Pipelines, GitLab CI/CD, GitHub Actions и JetBrains TeamCity.

Тестирование

Когда CI система успешно проверила работоспособность тестовой версии, код отправляется тестировщикам для ручного обследования. При этом тестовая сборка получает номер кандидата для дальнейшего релиза продукта (например, v.1.0.0-1).

Создание артефакта

После завершения сборки и тестирования создается артефакт — комплект всех файлов, необходимых для развертывания и функционирования приложения. Это может быть архив с исполняемыми файлами, Docker-контейнер, образ диска или другая форма представления приложения.

Релиз

По итогам ручного тестирования сборка получает исправления, а итоговый номер версии кандидата повышается (например, после первого исправления версия v.1.0.0-1 становится v.1.0.0-2). После этого выпускается версия кода для клиента (например, v.1.0.0) и начинается следующий этап цикла.

Именно на этапе релиза инструменты CI/CD начинат собирать различные пользовательские и внутренние данные. Например, можно отслеживать количество выполненных задач, скорость их выполнения и другие показатели.

Развертывание

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

Поддержка и мониторинг

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

Планирование

На основе пользовательского опыта формируются запросы на новые функции для продукта, готовится план доработок. После этого цикл замыкается и переходит в начальную стадию — написание кода. Далее начинается новая итерация CI/CD разработки.

Преимущества CI/CD

Метод CI/CD помогает оперативнее выпускать новые опции продукта (работа с запросами клиентов). Как правило, на это уходят считаные дни или недели. В то же время при классическом подходе к разработке клиентского софта это может занять год.

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

Недостатки CI/CD

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

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

Также заслуживает внимания и организация взаимодействия между проектными группами, поскольку CI/CD сильно завязан на человеческий фактор. Инженеры, scrum-специалисты, аналитики, dev-группы и другие функциональные единицы должны работать в единой экосистеме с адекватным руководством и проектным управлением.

CI/CD — просто тренд или реальная необходимость

Впервые CI/CD предложили использовать в 2006 году, а в 2008 специалисты отметили, что ее растущая популярность связана с развитием облачных технологий. При этом желание применять CI/CD для различных задач обусловлено не только популярностью, но и ее достоинствами — возможностью быстро согласовывать и внедрять обновления с учетом пользовательского опыта.

В условиях «гонки» между компаниями эта методология становится необходимой, так как помогает существенно сократить время от написания кода до выхода продукта. CI/CD отлично подходит для веб-разработки, омниканальных решений, электронной коммерции и других компонентов. Однако использование Continuous Integration и Continuous Delivery оправдано не всегда: например, в областях, где обновление программного обеспечения происходит редко, эта методология может быть неэффективной.

Инструменты для CI/CD

Software-разработчики используют различные инструменты для автоматизации тестирования и доставки кода своих проектов конечным пользователям.

GitLab CI. Среда позволяет управлять репозиториями проекта, документировать функциональность и результаты доработок и тестов, а также отслеживать ошибки и работать с CI/CD pipeline.

Travis-CI. Инструмент подключается к репозиториям в GitHub при минимуме настроек. Решение облачное и не требует локальной установки. Кроме того, оно бесплатно для open-source проектов.

Circle-CI. Продукт использует бесшовную интеграцию с GitHub. Предлагается веб-интерфейс для отслеживания версий сборок и ведения задач. Также решение поддерживает отправку оповещений по почте и другим каналам связи.

Jenkins. Довольно популярный инструмент в DevOps-среде. Заслужил свою репутацию благодаря работе с различными плагинами, позволяющими гибко настраивать CI/CD процессы под требования разработки конкретного продукта.

TeamCity. В бесплатном режиме позволяет работать только с тремя агентами сборки. Техническая поддержка предоставляется по подписке.

PHP Censor. CI-сервер для автоматизации сборки PHP-проектов, работающий с репозиториями GitLab, GitHub, Mercurial и другими. Для тестирования используются библиотеки Atoum, PHP Spec, Behat. Проект хорошо документирован, но предполагает самостоятельную настройку и хостинг.

Rex. Предназначен для автоматизации CI-процессов в дата-центрах. Работает на Perl-скриптах.

Open Build Service (OBS). Предназначен для автоматизации CI/CD в разработке дистрибутивов приложений.

Buildbot. CI-система, позволяющая автоматизировать сборку и тестирование приложений. Поддерживает современные VCS и позволяет гибко настраивать сборку за счет Python-компонентов.

Какой инструмент подойдет вашей компании

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

Аспект 1. Поддержка системы контроля версий

Ключевым элементом CI/CD является поддержка и интеграция с системой контроля версий (VCS). Наиболее распространенны такие системы, как Git, Subversion, Mercurial и Perforce. Облачные CI-решения могут поддерживать одну или несколько из этих систем, поэтому важно выбрать инструмент CI, который соответствует системе контроля версий ваших проектов.

Аспект 2. Поддержка контейнеров

Контейнеризация — это актуальная тенденция в разработке ПО, которая позволяет разрабатывать изолированные и стандартизированные копии приложений. Инструменты, такие как Docker и Kubernetes, активно поддерживают этот подход, а современные CI-инструменты интегрируют контейнеризацию в процессы CI/CD. Использование контейнеров помогает устранить проблемы совместимости, гарантируя, что код, созданный командой, будет работать в среде, аналогичной локальной.

Аспект 3. Сравнение локальной и облачной среды

Некоторые инструменты CI, такие как Jenkins, можно установить на локальных серверах. В этом случае ваша команда будет отвечать за настройку и управление CI-системой в вашей инфраструктуре. Это может быть полезно для обеспечения конфиденциальности и безопасности данных, особенно если необходимо соблюдать нормативные требования по защите данных клиентов. Однако локальная установка может потребовать дополнительных усилий, которые могут отвлекать от основных бизнес-задач. 

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

Аспект 4. Плагины и интеграции с решениями сторонних разработчиков

Инструменты CI становятся еще более эффективными, когда интегрируются с другими технологиями. Они могут собирать данные об эффективности работы команды разработчиков и связываться с приложениями для управления спринтами. Тем самым позволяют автоматически обновлять статусы после внесения изменений в код. Эти интеграции могут помочь в управлении показателями KPI и дорожными картами команды разработчиков.

СI/CD на практике

На практике внедрение CI/CD в компаниях перекликается с теми этапами, которые мы описали выше.

Анализ текущего состояния и оценка потребностей. Первый шаг во внедрении CI/CD — оценка текущего процесса разработки и потребностей команды. На этом этапе компания определяет текущие проблемы и узкие места в процессе разработки, а также цели, которые нужно достичь с помощью CI/CD. К таким целям могут относиться повышение скорости развертывания и качества кода или автоматизация рутинных задач.

Выбор инструментов CI/CD. Исходя из анализа потребностей, выбирается набор инструментов CI/CD, который лучше всего подходит для проекта. Это могут быть:

• системы непрерывной интеграции, например, Jenkins или CircleCI;
• системы управления версиями;
• инструменты контейнеризации, например, Docker;
• системы управления конфигурациями — Ansible, Terraform или что-то еще.

Создание конвейера CI/CD. На этом шаге команда проекта создает конвейер CI/CD — он автоматизирует процесс сборки, тестирования и развертывания приложения. Между этими процессами настраиваются связи, чтобы каждый из них автоматически запускался сразу же после завершения предыдущего.

Тестирование. Особое внимание уделяется настройке автоматизированных тестов, которые будут запускаться на каждом этапе конвейера CI/CD. Как правило, разработчики пишут юнит-тесты и интеграционные тесты, чтобы обеспечить полное покрытие функциональности приложения. Для автоматического тестирования компания может использовать JUnit, Selenium, или PyTest.

Развертывание в продакшн. Наконец, на последнем шаге (условно последнем — помним, что цикл бесконечный) настраивается автоматическое развертывание приложения в продакшн после успешного прохождения всех этапов конвейера CI/CD. 

Здесь команды используют Ansible или Terraform, чтобы обеспечить консистентность окружения и минимизировать риск появления проблем при развертывании.

Если вам нужна помощь в организации СI/CD, воспользуйтесь услугой DevOps as a Service. Наши специалисты помогут организовать непрерывную интеграцию и доставку приложений, а также обеспечат автоматизацию их развертывания.

Советы по СI/CD

Определитесь с технологиями и практиками перед внедрением CI/CD и придерживайтесь этого выбора во время работы в командах. 

Автоматизируйте все, что только возможно. Используйте современные инструменты и скрипты, чтобы минимизировать ручной труд. Помните, что практически все этапы процесса CI/CD можно автоматизировать, начиная со сборки кода и заканчивая деплоем.

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

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

И главное — постоянно обучайтесь. Мир разработки меняется с каждым днем. В нем появляются новые инструменты и технологии. Важно следить за тенденциями (и не только в области CI/CD) и постоянно улучшать процесс разработки в компании.