На заре развития IT процесс разработки был запутанным. Программисты писали код и передавали его отделу тестирования, QA-инженеры искали ошибки и возвращали проект на доработку, после нескольких итераций код получала команда эксплуатации. Каждый отдел работал сам по себе, из-за чего разработка продвигалась медленно, а фрагменты кода часто конфликтовали между собой.
В начале 2000-х годов разработчики задумались над автоматизацией процессов. Появились инструменты для автоматического тестирования кода, затем — решения для его доставки пользователям. К 2010-м годам компании начали формировать из этих практик единый процесс, который получил название CI/CD.
Внедрение практик CI/CD стало ключевым элементом DevOps. В 2009 году в городе Генте в Бельгии состоялась первая конференция DevOps Days, организованная Патриком Дебуа, что стало важным этапом в популяризации методологии.
Что такое CI/CD
CI/CD — это способ разработки, в котором тестирование и развёртывание кода происходит автоматически. Основная цель — ускорить выпуск обновлений и повысить качество ПО за счёт регулярного тестирования.
Разберём, из каких элементов состоит процесс.
Continuous integration (CI, непрерывная интеграция) — автоматическая интеграция кода в репозиторий проекта. Цель CI — упростить объединение кода от разных разработчиков и быстро выявлять ошибки. Когда программист отправляет код в репозиторий, система запускает тесты. Если в проекте найдутся ошибки, то разработчику придётся забрать код на доработку.
Continuous delivery (CD, непрерывная доставка) — это автоматическая подготовка кода к выпуску. Представьте команду, которая разрабатывает веб-приложение. При каждом изменении кода CD-система автоматически тестирует работоспособность, собирает нужные файлы и разворачивает приложение в тестовой среде. Когда менеджер проекта принимает решение о выпуске новой версии, он активирует публикацию одним нажатием — и подготовленный код разворачивается на рабочем сервере.
Continuous deployment (CD, непрерывное развёртывание) — автоматическая доставка кода пользователям без участия разработчиков. Каждое изменение в коде, прошедшее тесты, сразу уходит на основной сервер.
Непрерывная интеграция в CI/CD — обязательный этап, а доставка и развёртывание — опциональные. Доставка подходит командам, которые хотят контролировать, когда и какие обновления будут получать пользователи, а развёртывание — тем, кому важно, чтобы изменения моментально появлялись на продакшене.
Зачем нужен CI/CD-процесс
Представьте, что три автора пишут одну книгу вместе. В идеальной ситуации их роли распределены: один пишет, другой подаёт идеи, третий собирает материал и так далее. Важно, что у всей команды есть общее понимание замысла: о чём книга, кто главные герои, как они могут себя вести, а как — нет.
Но теперь представьте, что каждый автор действует сам по себе. Один меняет финал, другой меняет мотивацию персонажа, третий дополняет сюжет новыми событиями. Без общей системы согласования изменений работа над книгой превращается в хаос: события противоречат друг другу, повествование теряет логику.
То же и с разработкой. Когда несколько программистов работают над одним проектом без CI/CD-системы, изменения в коде могут противоречить друг другу. Например, один разработчик обновляет библиотеку, а другой в это время дописывает код для старой версии — из-за такой невинной ошибки целый проект может рухнуть.
Довольно аналогий — пройдёмся по основным функциям CI:
- Статический анализ. Линтеры для разных языков программирования анализируют код, проверяют синтаксис, стиль и ищут ошибки. Это позволяет ещё до запуска программы найти проблемы с производительностью и отправить код на доработку.
- Тестирование кода. На этом этапе система проверяет, не ломает ли обновление уже те функции, которые есть в программе, и насколько новый код работоспособен. Если автоматические тесты выявляют ошибку, то обновление возвращают программистам на доработку.
- Проверка качества. В каждой команде используют свои архитектурные решения, стандарты безопасности и требования к оформлению кода. На этом этапе проверяют, соблюдаются ли все эти правила.
- Сборка кода. Проект обычно представляет собой набор файлов с кодом, которые надо связать между собой, создать исполняемый файл, упаковать всё в 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 открытый код, поэтому сервис можно бесплатно развернуть на собственном сервере. Это особенно важно для компаний, которые работают с чувствительными данными и не хотят доверять обработку кода сторонним системам. Также есть большая библиотека плагинов, с помощью которых можно добавлять поддержку новых функций.
В Jenkins можно настраивать CI/CD-процессы любой сложности и оптимизировать сборку под любые платформы. Единственный минус в том, что в Jenkins довольно сложный процесс настройки конфигурации, который может запутать новичков.
GitHub Actions
GitHub Actions — CI/CD-платформа, интегрированная в сервис GitHub. Решение отлично подойдёт командам и разработчикам, которые хранят код своих проектов на GitHub. Конфигурации настраивать проще, чем в Jenkins. Также есть библиотека шаблонов для разных платформ.
Минус платформы в том, что вся обработка кода происходит в облаке. Это ставит под угрозу данные проектов, которым важен высокий уровень безопасности.
GitLab CI/CD
GitLab CI/CD — система, интегрированная в сервис GitLab. Она очень похожа на GitHub Actions, но доступна в двух версиях: облачной и локальной. Если в приоритете скорость работы и простота, то можно воспользоваться облачной версией. Для повышения безопасности лучше развернуть GitLab CI/CD на собственном сервере.
TeamCity
TeamCity — коммерческое решение от компании JetBrains, доступное по подписке. Есть как облачная версия, так и локальная. Один из плюсов системы в том, что он интегрирован со средами разработки от JetBrains, поэтому разработчики могут настраивать всё в одном приложении и не переключаться между приложениями.
Настраивать конфигурации в TeamCity можно с помощью YAML-файлов или веб-интерфейса. Второй способ подходит новичкам, которые ещё не могут с ходу написать скрипт для CI/CD-пайплайна.
Travis CI
Travis CI — облачная CI/CD-система с бесплатным тарифом для опенсорс-проектов и интеграцией с GitHub. Для компаний есть локальная версия с упором на безопасность. Конфигурации в Travis CI настраиваются с помощью YAML-файла.
Xcode Cloud
Xcode Cloud — CI/CD-система от Apple, адаптированная для разработчиков iOS-приложений. В ней есть интеграции со средой разработки Xcode, системой управления релизами App Store Connect и платформой тестирования TestFlight. К системе можно подключить сервисы контроля версий GitHub, GitLab, Bitbucket и локальные репозитории.
Бесплатно разработчикам предоставляют 25 часов сборки в месяц. По подписке за 4000 долларов можно расширить лимит до 10 000 часов. Из минусов можно отметить, что Xcode Cloud — облачное решение, поэтому все данные обрабатываются на серверах Apple.
Как выбрать CI/CD-платформу
Как мы уже убедились, выбор CI/CD-платформ очень большой. Помимо популярных решений, есть много нишевых, которые тоже предлагают удобные инструменты. Во время выбора платформы важно учитывать следующие факторы:
Сложность настройки. Если платформу можно легко развернуть и настроить, то команда сможет быстрее начать автоматизировать разработку. Также важно учитывать, что чем больше в системе запутанных механизмов, тем выше вероятность их частого выхода из строя. Лучше выбирать простые системы с подробной документацией и активной службой поддержки.
Также учитывайте, что если в команде много новичков, то лучше обратить внимание на платформу с визуальным редактором конфигураций. Так начинающим разработчикам будет проще разобраться с настройкой, и они быстрее втянутся в работу.
Предустановленный софт. Чем больше инструментов доступно из коробки, тем меньше времени придётся тратить на ручную настройку сторонних систем. Например, если вы разрабатываете приложение для Android, то платформа должна поддерживать работу с Java Development Kit и Gradle, а iOS-разработчикам нужны Xcode и CocoaPods.
Стоимость и время сборок. Коммерческие платформы берут плату за минуты сборок в месяц. Для небольших проектов хватит 500–1000 минут в бесплатных тарифах, а крупным компаниям важно понимать, из чего складывается цена. Обязательно уточните это в отделе продаж или на сайте сервиса. Также учитывайте, что если вам понадобится более мощный сервер, то за него также придётся доплатить.
Сторонние интеграции. Убедитесь, что к системе можно подключать сторонние сервисы. Например, Google Play для автоматической публикации приложений, Slack для отправки уведомлений или GitHub для хранения кода. Чем больше интеграций доступно, тем больше процессов можно автоматизировать.
Самое главное
- CI/CD — это автоматизированный процесс разработки и доставки ПО, включающий в себя непрерывную интеграцию, доставку и развёртывание.
- Непрерывная интеграция (CI) отвечает за проверку кода с помощью линтеров и тестов.
- Непрерывная доставка и развёртывание (CD) готовит проект к релизу или сразу выкатывает его в продакшен без участия разработчиков.
- Главная цель CI/CD — ускорение разработки за счёт автоматизации рутинных задач.
- При выборе CI/CD-платформы стоит учитывать стоимость каждой сборки, возможность интегрировать сторонние сервисы и сложность настройки системы.