Блог

Технология CI/CD: что это такое и как внедряется

14 февраля 2025
16 мин. 181
image
image
image
Елена Андреева редактор-копирайтер
image
Кирилл Шушкин руководитель IT-отдела
Технология CI/CD: что это такое и как внедряется

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

CI/CD, что это и зачем нужен этот метод

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

В популярных статьях о методологии CI/CD можно встретить мнение о том, что главная её особенность — короткие циклы выпуска и постоянные обновления. Но это не совсем так. Сейчас длинные циклы разработки уже не применяются ни в одном методе, и частую интеграцию можно делать и без CI/CD. А основное преимущество методологии CI/CD для разработчиков — автоматизация и повторяемость действий.
Вся ценность CI/CD в том, что это не просто частая интеграция, а частая интеграция со сборкой и тестированием. Самый большой её плюс — это автоматизация сборки, причём в повторяющем окружении.
Например, в разработке по другим методологиям часто можно встретить такую проблему: код написали; в инструкции указано, как собирать его дальше вручную. Но если что-то где-то изменилось — например, один из разработчиков вручную исправил код и никому не сказал — то при деплое может всё сломаться. То же самое произойдёт, если есть небольшая разница в окружении — например, в переменных. Разница может появиться, если кто-то внёс изменения и забыл передать остальным либо внести в документацию; или просто человеческая ошибка — не ту команду ввели. Из-за этого сборка пойдёт неправильно, и «баги уедут на прод», то есть ошибки окажутся в рабочей версии программы.
Эту проблему решает автоматизация тестирования и повторяемость действий, характерная для CI/CD.
Кирилл Шушкин
руководитель отдела IT в Uplab

Чтобы понять преимущества методологии и её ценность для разработчиков и заказчика, разберём каждую часть этого определения и объясним, как это работает в связке.

Что такое CI?

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

Что такое CD?

Если аббревиатура CI всем понятна и не вызывает разночтений, то со второй частью (CD) всё не так просто. За ней может скрываться как «непрерывная доставка» (Continuous Delivery, т.е. финальная сборка для конечных пользователей), так и «непрерывное развёртывание» (Continuous Deployment): автоматический процесс внедрения программного обеспечения после внесения обновлений. Как говорят сами разработчики, «CD начинается там, где заканчивается CI». Ключевое различие между Continuous Delivery и Continuous Deployment — в наличии ручного запуска автоматической доставки релиза в продакшн.

В целом процессы Continuous Delivery и Continuous Deployment абсолютно идентичны; разница в том, что процесс деплоя в случае с Continuous Deployment автоматизирован и происходит без участия человека, с начала и до конца. А в Continuous Delivery он не запускается, пока не получено подтверждение от разработчика.
С Continuous Deployment процесс доходит до конца без каких-либо остановок. А в случае с Delivery он начинается, останавливается в точке «Развёртывание в рабочей среде», ждёт ручного подтверждения и только после него продолжается дальше. Это и есть ручной запуск автоматической доставки.
Различием и обусловлен один момент, который становится очень важным именно в Continuous Deployment. Тесты должны быть очень чётко настроены; требуются большие инвестиции на качественное тестирование — иначе повышается вероятность ошибок в рабочей версии программы, поскольку она обновляется без контроля разработчиков. А в Continuous Delivery, напротив, можно аккумулировать обновления, дополнительно их тестировать вручную для исключения ошибок и только потом запускать. Поэтому большинство компаний выбирают Delivery.
Кирилл Шушкин
руководитель отдела IT в Uplab

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

Зачем нужен подход CI/CD?

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

Инструменты

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

1. SaaS («software as a service») и не SaaS. Разница между ними заключается в типе установки.

SaaS инструменты как понятно из расшифровки названия, предоставляются как услуга через интернет: не нужно устанавливать программу на свой компьютер или сервер; доступ даётся через веб-браузер или API. При этом вся инфраструктура (серверы, хранилище данных, обновления и обслуживание) лежит на стороне поставщика SaaS. Эти инструменты чаще всего платные, и вносить оплату нужно в формате подписки, раз в месяц или год. Примеры: GitHub Actions, Team City, CircleCI, TravisCI.

Не-SaaS инструменты — это программное обеспечение, которое устанавливается и запускается на собственных серверах или компьютерах пользователя. Примеры: Jenkins, GitLab.

2. Платные и бесплатные. Первые предполагают оплату ежемесячной подписки, лицензию или однократную оплату при покупке (пример — TravisCI); вторые используются свободно (примеры: Jenkins, GitLab, GitHub Actions, Team City, CircleCI). У некоторых инструментов есть ограниченный бесплатный функционал и расширенный платный.

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

CI/СD системы

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

GitLab CI/CD (хостинг Git + CI/CD)

Похожие инструменты: GitHub Actions

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

Jenkins (самостоятельный сервер CI/CD)

Похожие инструменты: GoCD, Buildbot

Open-source платформа CI/CD, известная как сервис с высокой гибкостью и широкими возможностями кастомизации. Может быть развернута на собственной инфраструктуре, что обеспечивает большой контроль, но требует большего администрирования. Обладает огромным сообществом и богатым набором плагинов, позволяющих интегрироваться практически с любым инструментом. Сложнее в настройке, чем GitLab CI/CD или Azure DevOps, но идеально подходит для специфических требований и сложных конвейеров. Бесплатный, но требует инвестиций в инфраструктуру и администрирование.

У CI/CD платформы Jenkins крупное и сплоченное комьюнити пользователей. Но, несмотря на всю поддержку и многочисленные мануалы, это сложный инструмент, и его внедрение займёт время.

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

CI/CD и этапы разработки ПО

Жизненный цикл разработки программного обеспечения (software development life cycle) можно представить как путь из шести этапов:

  1. анализ требований;

  2. планирование;

  3. проектирование;

  4. разработка;

  5. тестирование кода;

  6. развертывание(деплоймент) + поддержка.

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

1. Анализ требований

На этом этапе разработчик и заказчик активно общаются. Цель — понять, что именно нужно создать. В процесс вовлечены бизнес-аналитики, менеджеры и другие лица, заинтересованные в конечном продукте. Собирается информация о том, какую проблему должна решить программа, какие функции она должна выполнять, для кого она предназначена. Задача аналитиков и менеджеров проекта — уточнить и детализировать данные.

Например, заказчик говорит: «Мне нужна программа для учета клиентов». Аналитику нужно выяснить: какие данные нужно учитывать о клиентах, как эти данные будут использоваться, какие отчеты нужны и какие интеграции с другими системами необходимы.

Результат анализа фиксируется в документе: функционально-технических требованиях или документе бизнес-требований.

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

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

Также определяется, какие ресурсы (люди, оборудование, программное обеспечение) понадобятся для проекта и как они будут распределены между задачами. Формируется команда разработчиков, назначаются роли и ответственности. Создаётся дорожная карта проекта с графиком работ; бюджет рассчитывают и распределяют по этапам.

3. Проектирование

На этом этапе требования трансформируются в конкретные решения по реализации. Разработчик определяет:

  • общую структуру системы, ее основные компоненты и способы их взаимодействия;

  • стиль (например, микросервисная архитектура, монолитная архитектура, клиент-серверная архитектура);

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

На этом этапе также происходит разработка структуры базы данных и выбор системы управления ими; проектирование интерфейсов пользователя (UI/UX дизайн); выбор стека разработки.

4. Разработка (Кодирование, Реализация)

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

Если при разработке используется методология CI/CD, то разработчики регулярно (часто несколько раз в день) интегрируют свой код в общий репозиторий, например, Git. Это позволяет быстро выявлять и устранять проблемы, ускоряет процесс разработки и обеспечивает более стабильную работу.

5. Тестирование кода

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

6. Развертывание (Деплоймент) + Поддержка

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

Методология CI/CD позволяет быстро добавлять обновления и поддерживать актуальность сервиса.

Преимущества использования практики CI/CD

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

  1. Ускорение процесса разработки и вывода продукта на рынок (Time-to-Market). Автоматизация большинства этапов, от сборки до развертывания, значительно сокращает время, необходимое для выпуска новых версий и обновлений. Частые, небольшие релизы позволяют быстрее реагировать на потребности пользователей и конкурентов.

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

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

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

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

  6. Улучшение обратной связи от пользователей: частые релизы позволяют быстрее получать обратную связь от пользователей, что позволяет оперативно реагировать на их потребности и пожелания, улучшая продукт и повышая удовлетворенность клиентов.

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

  8. Улучшение мониторинга и отслеживания: инструменты CI/CD предоставляют подробную информацию о каждом этапе процесса, позволяя отслеживать производительность и выявлять узкие места. Это помогает оптимизировать процесс разработки и повысить его эффективность.

Расскажите
о вашем проекте