CI/CD: что это и почему без неё не обходится разработка ПО
2026-02-21 19:34 Diff
https://skillbox.ru/media/code/cicd-chto-eto-i-pochemu-bez-nee-ne-obhoditsya-razrabotka-po/

#статьи

  • 18 апр 2025
  • 0

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

Иллюстрация: Катя Павловская для Skillbox Media

Автор статей о программировании. 14 лет в IT. Умеет рассказывать о технологиях простыми словами. Автор спецпроекта Advertising for Social Change.

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

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

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

Содержание

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

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

Continuous integration (CI, непрерывная интеграция) — автоматическая интеграция кода в репозиторий проекта. Цель CI — упростить объединение кода от разных разработчиков и быстро выявлять ошибки. Когда программист отправляет код в репозиторий, система запускает тесты. Если в проекте найдутся ошибки, то разработчику придётся забрать код на доработку.

Continuous delivery (CD, непрерывная доставка) — это автоматическая подготовка кода к выпуску. Представьте команду, которая разрабатывает веб-приложение. При каждом изменении кода CD-система автоматически тестирует работоспособность, собирает нужные файлы и разворачивает приложение в тестовой среде. Когда менеджер проекта принимает решение о выпуске новой версии, он активирует публикацию одним нажатием — и подготовленный код разворачивается на рабочем сервере.

Continuous deployment (CD, непрерывное развёртывание) — автоматическая доставка кода пользователям без участия разработчиков. Каждое изменение в коде, прошедшее тесты, сразу уходит на основной сервер.

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

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

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

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

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

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

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

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

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

Работа любой 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-платформы. В команде должны быть DevOps-инженеры, которые будут обновлять и обслуживать систему. Эту работу не стоит поручать разработчикам, так как у них не будет хватать времени на всё сразу.
  • Ложные срабатывания на ошибки. Даже небольшие ошибки в коде могут прерывать сборку всего проекта. В таких ситуациях команды приходится отвлекаться от задач и выяснять, что пошло не так.

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

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

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

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

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

GitLab CI/CD — система, интегрированная в сервис GitLab. Она очень похожа на GitHub Actions, но доступна в двух версиях: облачной и локальной. Если в приоритете скорость работы и простота, то можно воспользоваться облачной версией. Для повышения безопасности лучше развернуть GitLab CI/CD на собственном сервере.

TeamCity — коммерческое решение от компании JetBrains, доступное по подписке. Есть как облачная версия, так и локальная. Один из плюсов системы в том, что он интегрирован со средами разработки от JetBrains, поэтому разработчики могут настраивать всё в одном приложении и не переключаться между приложениями.

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

Travis CI — облачная CI/CD-система с бесплатным тарифом для опенсорс-проектов и интеграцией с GitHub. Для компаний есть локальная версия с упором на безопасность. Конфигурации в Travis CI настраиваются с помощью YAML-файла.

Xcode Cloud — CI/CD-система от Apple, адаптированная для разработчиков iOS-приложений. В ней есть интеграции со средой разработки Xcode, системой управления релизами App Store Connect и платформой тестирования TestFlight. К системе можно подключить сервисы контроля версий GitHub, GitLab, Bitbucket и локальные репозитории.

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

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

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

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

Предустановленный софт. Чем больше инструментов доступно из коробки, тем меньше времени придётся тратить на ручную настройку сторонних систем. Например, если вы разрабатываете приложение для Android, то платформа должна поддерживать работу с Java Development Kit и Gradle, а iOS-разработчикам нужны Xcode и CocoaPods.

Стоимость и время сборок. Коммерческие платформы берут плату за минуты сборок в месяц. Для небольших проектов хватит 500–1000 минут в бесплатных тарифах, а крупным компаниям важно понимать, из чего складывается цена. Обязательно уточните это в отделе продаж или на сайте сервиса. Также учитывайте, что если вам понадобится более мощный сервер, то за него также придётся доплатить.

Сторонние интеграции. Убедитесь, что к системе можно подключать сторонние сервисы. Например, Google Play для автоматической публикации приложений, Slack для отправки уведомлений или GitHub для хранения кода. Чем больше интеграций доступно, тем больше процессов можно автоматизировать.

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