CI/CD: что это и почему без неё не обходится разработка ПО

Рассказываем, как работают конвейеры по тестированию и сборке кода.

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

В начале 2000-х годов разработчики задумались над автоматизацией процессов. Появились инструменты для автоматического тестирования кода, затем — решения для его доставки пользователям. К 2010-м годам компании начали формировать из этих практик единый процесс, который получил название CI/CD.

Внедрение практик CI/CD стало ключевым элементом DevOps. В 2009 году в городе Генте в Бельгии состоялась первая конференция DevOps Days, организованная Патриком Дебуа, что стало важным этапом в популяризации методологии.

Что такое CI/CD

Разберём, из каких элементов состоит процесс.

Этапы CI/CD-пайплайна
Инфографика: Skillbox Media

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

Зачем нужен CI/CD-процесс

Представьте, что три автора пишут одну книгу вместе. В идеальной ситуации их роли распределены: один пишет, другой подаёт идеи, третий собирает материал и так далее. Важно, что у всей команды есть общее понимание замысла: о чём книга, кто главные герои, как они могут себя вести, а как — нет.

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

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

Довольно аналогий — пройдёмся по основным функциям CI:

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

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

Основные функции CD:

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

Как работает CI/CD

Работа любой CI/CD-системы начинается с загрузки кода в систему контроля версий, например GitHub, GitLab или локальный Git-репозиторий. Из неё CI/CD-платформа получает исходный код проекта, собирает его и загружает на сервер.

Что именно надо сделать с кодом, определяет конфигурация, которая описана в YAML-файле. Обычно в конфигурации указывают следующие шаги:

• как удалённая машина должна загрузить код;
• по каким правилам следует собрать приложение;
• какие тесты запускать;
• куда загрузить сборку, чтобы пользователи могли получить к ней доступ.

Файл конфигурации хранится в Git-репозитории вместе с кодом. Вот так он выглядит в CI/CD-платформе GitHub Actions:

name: Build and Test on: push: branches: – main pull_request: jobs: build: runs-on: ubuntu-latest steps: – name: Checkout code uses: actions/checkout@v2 – name: Install dependencies run: npm install – name: Run tests run: npm test

Эта конфигурация автоматически запускается при каждом пул-реквесте в ветку main, тестирует код и собирает приложение:

• on — указывает, когда запускать CI/CD (например, при пуше в main);
• jobs — список задач, которые выполняются в пайплайне;
• runs-on — задаёт среду выполнения (ubuntu-latest);
• steps — шаги сборки:

• checkout — загрузка кода;
• npm install — установка зависимостей;
• npm test — запуск тестов.

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

Важно учитывать, что разные CI/CD-платформы используют разные YAML-схемы. Например, вот так выглядит определение среды выполнения в GitHub Actions:

runs-on: ubuntu-latest

А вот так — в Amazon Web Services:

instance_type: ubuntu-latest

Плюсы и минусы CI/CD

Разберём плюсы и минусы использования CI/CD-систем в разработке.

• Быстрые релизы. Грамотно настроенная CI/CD-платформа позволяет командам быстрее выпускать обновления и не задерживать код на разных этапах. Всё происходит автоматически и не стопорится.
• Выявление ошибок на ранних стадиях. Механизм непрерывной интеграции проверят код перед тем, как отправить его на сборку. Это позволяет сразу выявить ошибки, а не узнать о них после релиза.
• Прозрачный процесс разработки. С помощью CI/CD можно отслеживать, на каком этапе находится обновление и как можно оптимизировать доставку обновлений пользователям.

• Сложное внедрение. На этапе внедрения команде надо протестировать несколько CI/CD-платформ, найти оптимальную, настроить её и протестировать. Это обходится дорого и занимает много времени.
• Высокие требования к культуре разработки. Для успешной работы системы разработчикам надо приучить себя писать тесты и исправлять известные ошибки до загрузки кода в репозиторий. Если этого не делать, то CI/CD-система даст мало выгоды.
• Поддержка CI/CD-платформы. В команде должны быть DevOps-инженеры, которые будут обновлять и обслуживать систему. Эту работу не стоит поручать разработчикам, так как у них не будет хватать времени на всё сразу.

• Ложные срабатывания на ошибки. Даже небольшие ошибки в коде могут прерывать сборку всего проекта. В таких ситуациях команды приходится отвлекаться от задач и выяснять, что пошло не так.

Популярные CI/CD-платформы

Давайте рассмотрим популярные CI/CD-платформы, которые позволяют настраивать конвейеры любой сложности и автоматизировать разработку, тестирование и развёртывание ПО.

Jenkins

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

GitHub Actions

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

GitLab CI/CD

TeamCity

Настраивать конфигурации в TeamCity можно с помощью YAML-файлов или веб-интерфейса. Второй способ подходит новичкам, которые ещё не могут с ходу написать скрипт для CI/CD-пайплайна.

Travis CI

Xcode Cloud

Бесплатно разработчикам предоставляют 25 часов сборки в месяц. По подписке за 4000 долларов можно расширить лимит до 10 000 часов. Из минусов можно отметить, что Xcode Cloud — облачное решение, поэтому все данные обрабатываются на серверах Apple.

Как выбрать CI/CD-платформу

Как мы уже убедились, выбор CI/CD-платформ очень большой. Помимо популярных решений, есть много нишевых, которые тоже предлагают удобные инструменты. Во время выбора платформы важно учитывать следующие факторы:

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

Самое главное

• CI/CD — это автоматизированный процесс разработки и доставки ПО, включающий в себя непрерывную интеграцию, доставку и развёртывание.
• Непрерывная интеграция (CI) отвечает за проверку кода с помощью линтеров и тестов.
• Непрерывная доставка и развёртывание (CD) готовит проект к релизу или сразу выкатывает его в продакшен без участия разработчиков.
• Главная цель CI/CD — ускорение разработки за счёт автоматизации рутинных задач.
• При выборе CI/CD-платформы стоит учитывать стоимость каждой сборки, возможность интегрировать сторонние сервисы и сложность настройки системы.

Линтер — инструмент для анализа кода и поиска в нём потенциальных ошибок.

YAML — формат текстовых файлов, которые человек может легко читать и редактировать.

Пул-реквест — запрос на внесение изменений в кодовую базу, который разработчики отправляют в системе контроля версий, например в GitHub.