В большинстве IT-проектов есть продуктовый аналитик или менеджер, который формулирует требования и ставит задачи разработчикам. Программист, в свою очередь, берет задачу из таск-менеджера, реализует ее локально на своём компьютере и затем отправляет изменения в репозиторий Git, во временную ветку, например, fix/add-search-bar.
Однако любые новые изменения потенциально могут сломать проект. Разработчик проверяет код только в своём локальном окружении, которое может отличаться от окружения других разработчиков или от продакшена. Кроме того, при работе в команде коммиты разных людей могут конфликтовать друг с другом. Чтобы снизить эти риски и автоматизировать процесс, создают CI/CD-пайплайн.
Что такое CI/CD
CI/CD — это практика, которая помогает запускать процесс сборки и поставки программного обеспечения по триггеру, а также снижает влияние человеческого фактора. Разберемся с аббревиатурами CI и CD.
CI (Continuous Integration, непрерывная интеграция) — это практика, при которой разработчик регулярно вносит правки в код. При этом каждый новый пул реквест или изменение в репозитории автоматически запускает пайплайн.
Пайплайн представляет собой последовательность автоматических действий, которые стартуют автоматически и следуют друг за другом: сборка проекта, анализ кода, запуск тестов, в случае ошибки — уведомление разработчиков и откат изменений. Количество шагов в пайплайне не ограничено и может включать как стандартные инструменты (линтеры, модульные тесты), так и собственные прикладные решения компании.
При этом все полностью автоматизировано: DevOps-инженер один раз описывает сценарий выполнения или вносит в него изменения, после чего процесс будет стартовать сам при каждом изменении кода.
Пайплайн запускается с помощью CI-приложений, таких как Jenkins, GitLab CI и других. Это специальные программы, запущенные на сервере. Git-репозитории посылает уведомление, например, на Jenkins, о том, что произошел новый пул реквест или другое событие. Приложение, в свою очередь, копирует репозиторий к себе и запускает обработку по пайплайну.
CD (Continuous Delivery, непрерывная поставка) начинается там, где заканчивается CI. Этот этап отвечает за подготовку уже проверенного кода к релизу: настройку окружений, конфигурацию сервисов и другие действия, необходимые для выпуска продукта, а также — сам релиз. При этом само развертывание в продакшен можно как запустить вручную, так и выполнить автоматический деплой.
Если же код развертывается автоматически, без участия человека, такой подход называется Continuous Deployment (непрерывное развертывание). Это более высокий уровень зрелости процессов, который подходит не всем компаниям из-за требований к безопасности и контролю релизов.
Принципы Continuous Integration и Continuous Delivery
Вот несколько принципов, следуя которым, можно выстроить нормальный рабочий процесс:
- Частая интеграция кода. Разработчики должны регулярно вносить изменения в общую ветку. При этом обновления предполагаются небольшие, так как их проще проверять.
- Автоматизация процессов. Сборка, тестирование и развертывание должны выполняться автоматически. От программистов и тестировщиков требуется только написать код, всё остальное должно происходить без участия сотрудников.
- Непрерывное тестирование. Тесты запускаются на каждый новый коммит или изменения в коде. Это позволяет проверять качество постоянно, а не перед самым релизом.
- Единая среда. Окружения разработки, тестирования и продакшена должны быть максимально похожи. В этом помогает использование контейнеров и инфраструктуры как кода.
Инструменты CI/CD
Как уже было сказано выше, CI-система — это отдельное приложение, запущенное на сервере. В этом блоке разберем, какие решения существуют.
Облачные сервисы
GitHub Actions — встроенный CI/CD-инструмент от GitHub. Пайплайн настраивается с помощью YAML-конфигурации. Есть множество готовых скриптов для тестирования и сборки.
Сервис можно использовать бесплатно для публичных репозиториев. Платные возможности использовать напрямую из РФ не получится.
GitLab CI/CD — инструмент пайплайнов, который можно развернуть на своем сервере или использовать в виде облачного решения. Настраивается с помощью конфига на YAML.
Инструмент бесплатный при условии, что пользователь тратит менее 400 минут вычислений в месяц. Также можно установить GitLab на собственный сервер.
AWS CodePipeline — это облачный сервис для CI/CD от Amazon, предназначенный для автоматизации процессов доставки приложений в инфраструктуре AWS. Он легко интегрируется с другими сервисами AWS, такими как CodeBuild, CodeDeploy и S3.
Можно бесплатно запустить один пайплайн. Далее каждая новая цепочка стоит от $1 в месяц или $0.002 за минуту. Также недоступен в РФ.
CircleCI — облачная система. Среди остальных выделяется возможностями для параллелизма: можно разделять тесты на несколько контейнеров, с помощью чего скорость выполнения уменьшается в разы.
Предоставляет бесплатно до 6000 вычислительных минут в месяц. Далее от $15/мес, однако оплатить из РФ без посредников невозможно.
Drone CI — CI/CD решение. В отличие от остальных сервисов здесь каждый этап сборки и каждый плагин — это отдельный Docker-контейнер. Есть Open Source версия, которая распространяется свободно, и Enterprise Edition с более продвинутым параллелизмом.
Self-Hosted решения
Эти CI/CD сервисы можно установить на собственный сервер.
Jenkins — популярный open-source инструмент для CI/CD, который можно гибко настраивать под задачи тестирования, сборки и деплоя. Разобраться с этим сервисом сложнее, поэтому больше подходит для опытных команд и крупных компаний.
TeamCity — коммерческий CI/CD. Он предлагает понятный интерфейс, глубокую интеграцию с IDE JetBrains и мощные инструменты для тестирования.
Бесплатно можно использовать не больше 100 конфигураций, однако оплатить все функции платформы из РФ не возможно.
Bamboo — коммерческий продукт от Atlassian, поддерживает гибкую интеграцию с Jira, Bitbucket и Confluence, с помощью чего можно, например, видеть статус сборки прямо в задаче, из Jira.
Есть 30-дневная пробная версия. Приобрести лицензию из РФ напрямую нельзя.
Как выбрать подходящий сервис
Вот несколько вопросов, которые помогут выбрать CI/CD-систему:
- Нужна ли интеграция с Git-репозиторием? Если нужно решение, где все лежит внутри одной платформы, стоит обратить внимание на GitLab или Actions. Если же готовы потратить время на ручную настройку, выбирайте любой подходящий сервис.
- Готовы поддерживать свой сервер? Для маленьких команд, у которых мало опыта с настройкой собственной инфраструктуры, подойдет облачная платформа. Если же в компании есть специалисты, готовые взяться за поддержку CI/CD на сервере, лучше обратить внимание на Self-Hosted.
- Работаете только с Kubernetes? Если ответ да, обратитесь к Argo CD, дополнив ее каким-нибудь CI-решением.
Стоит также понимать, что в реалиях РФ большинство DevOps-инженеров работают только с GitLab — 54% — и Jenkins — 31%, поэтому найти специалиста, который понимает все нюансы AWS, CircleCI, Drone CI и других, довольно сложно, а значит, поддержка эти решений будет стоить еще дороже.
Подробный разбор процессов на примере
Рассмотрим, как может быть устроен процесс разработки и доставки приложения. Здесь описан лишь один из возможных вариантов организации CI/CD. В реальных проектах пайплайны могут сильно отличаться в зависимости от размера команды и типа продукта.
Разработка новой функции
Разработчик начинает работу с того, что забирает задачу из таск-менеджера. Затем клонирует репозиторий проекта из Git на свой компьютер, создает рабочую ветку и приступает к решению задачи.
После работы над кодом программист тестирует результат с помощью базовых unit-тестов и статического анализа. Эти действия могут выполняться как автоматически, так и вручную, а основная задача на данном этапе — проверить минимальные части в изоляции.
После того как задача выполнена, автоматически запускается пайплайн, который подсвечивает проблемы. Дополнительно разработчик может отправить результат на ревью, где тимлид посмотрит код и даст комментарии.
Сборка и тесты
В нашем случае для пайплайна используется решение GitLab CI, которое предоставляет специальную программу — Runner. Она запускается на отдельном сервере и «триггерится» на каждый новый pull request или merge в ветку Dev, клонирует актуальную версию репозитория к себе на сервер и начинает сборку.
Собирается проект обычно в Docker-образ, который представляет собой артефакт — упакованное приложение со всеми зависимостями, библиотеками и настройками, необходимыми для запуска.
После успешной сборки запускается этап тестирования. Его основная цель — выявить ошибки и проблемы до того, как код попадёт к пользователям. Тестирование готового образа может включать несколько видов проверок:
- интеграционные тесты;
- системное тестирование;
- E2E (End-to-End) тесты;
- smoke-тестирование;
- нагрузочные тесты;
- и т. д.
Само тестирование обычно тоже реализовано в виде конвейера (pipeline), состоящего из отдельных шагов и скриптов. Кроме того, в проекте могут существовать специфические тесты, написанные под особенности конкретно этого продукта.
Развертывание на тестовом сервере и продакшен
Если все автоматические проверки прошли успешно, приложение разворачивается в тестовой среде — Staging. Здесь код проверяют тестировщики вручную: они выполняют сценарии использования, ищут логические ошибки, проверяют интерфейс и поведение системы — а после всех тестов приложение отправляется в продакшен.
Если автоматические тесты не пройдены, выполнение пайплайна останавливается, соответствующий этап помечается как неуспешный, а дальнейшие этапы блокируются. Система фиксирует ошибку и отправляет уведомление программисту, например, по почте.
Также разработчики используют хранилище для предыдущих версий приложения. Например, при работе с Docker таким хранилищем может быть тот же GitLab — реестр Docker-образов, где сохраняются все релизы. Благодаря такому архиву в любой момент можно откатиться на предыдущую версию, просто развернув соответствующий Docker-образ из реестра.
Преимущества CI/CD
Меньше ошибок. CI/CD помогает уменьшить количество ошибок за счет регулярных автоматических проверок. Тестирование запускается при каждом изменении, поэтому большинство багов выявляется на ранних этапах.
Автоматизация. Сборка, тестирование и деплой выполняются без ручного вмешательства, поэтому вероятность человеческого фактора снижается, а сами разработчики могут сосредоточиться на написании кода.
Сокращение сроков разработки. CI/CD подход ускоряет доставку в продакшен за счет множества мелких изменений и налаженного пайплайна тестирования.
Недостатки CI/CD
Риск получить неправильный результат. Рассмотрим простой пример. CI/CD состоит из трех основных этапов: сборка, тестирование и продакшен. На каждом шаге находится своя мини-инфраструктура, которая состоит из серверов, сетевого оборудования, различных скриптов и т. д. Все это требует регулярного обновления и изменений в конфигурациях.
Из-за этого может возникнуть ситуация, когда специалисты, которые обслуживают среду разработки, обновили базовый образ, что привело к обновлению библиотек, а разрабатываемый софт оказался с ними не совместим. В результате при каждом коммите появляется множество ошибок.
Дополнительные затраты. Помимо предыдущей проблемы, компоненты CI/CD требуют дополнительных серверных ресурсов, не говоря уже о том, что для внедрения нужны квалифицированные DevOps-инженеры с опытом работы со специфическими инструментами. Кроме того, на первичную настройку пайплайна и создание скриптов для тестирования понадобится время.
Дополнительная точка отказа. Если сервер с CI/CD-приложением недоступен или работает нестабильно, останавливается весь процесс доставки.
Заключение
Из этой статьи вы узнали, что означает подход CI/CD и как он помогает разработчикам писать стабильный код для приложений.
Нужно ли вам вообще CI/CD? Если релизы происходят регулярно и не хочется каждый раз делать повторяющиеся действия, скорее всего, внедрение неизбежно.
Чтобы внедрить эту методологию, когда опыта практически нет, попробуйте начать с малого. Установите, например, GitLab на собственный VDS, настройте базовую конфигурацию, добавьте автотесты, которые будут запускаться при каждом обновлении кода, а также автоматизируйте сборку. Затем постепенно расширяйте пайплайн и добавляйте деплой на тестовую среду.
