CI/CD в два клика и без простоев
CI/CD – это процесс непрерывной интеграции и непрерывной доставки продукта.
Концепция CI/CD относится к гибким методологиям разработки ПО и ориентирована на внимание к бизнес-требованиям и безопасности, а также на обеспечение высокого качества конечного продукта. Этот подход включает в себя:
- автоматизацию процессов сборки, упаковки и тестирования программного обеспечения;
- автоматическое развертывание приложения в разных окружениях (например, на тестовых, промежуточных и продуктовых серверах);
- минимизацию ошибок и уязвимостей в программном продукте путем постоянной проверки и корректировки кода.
Приведем пример: для того чтобы выполнить расчеты в EXCEL, удобнее воспользоваться формулой и получить результат за секунду, чем высчитывать каждую строку вручную на калькуляторе.
Основными принципами CI/CD являются:
- Разделение ответственности за различные этапы процесса, минимизация рисков на каждом этапе жизненного цикла продукта.
- Сокращение времени обратной связи за счет автоматизации.
- Создание единого рабочего пространства для разработчиков, сопоставимого с производственной, тестовой и средой для разработки.
Преимущества CI/CD
- Повышение скорости разработки: разработчики могут быстрее тестировать и вводить изменения в продукт.
- Качество тестирования: возможность выявлять ошибки на ранней стадии разработки.
- Выбор оптимального варианта: разработчики могут протестировать различные варианты кода быстро и внедрить наиболее подходящий.
Под непрерывной интеграцией, мы понимаем развертывание кода в тестовых системах, а под непрерывной доставкой – доставку приложения до продукта (максимально упрощая: написал – отправил в репозиторий, всё само собралось, автоматически протестировалось, установилось).
Из чего состоит CI/CD?
- Git (инструмент для автоматизации рутинных задач, возникающих в процессе разработки программного обеспечения).
- Автоматизированные инструменты развертывания
- GitLab (инструмент для автоматизации процессов тестирования, развертывания и мониторинга проектов).
Для того чтобы работала CI/CD, нужно настроить гид, развернуть тестовое окружение с необходимым перечнем: фронт, тест, в зависимости от того, какие уровни у заказчика, и конечный сервер, на котором всё должно появиться после одобрения.
Основная проблема в том, чтобы понимать все взаимосвязи этого процесса: как происходит взаимодействие и по каким алгоритмам, весь список сторонних компонентов, которые будут использованы в работе. Должны быть проработаны алгоритмы действий на случай если что-то пошло не так.
Как проходит процесс CI/CD
- Необходимо забрать из репозитория код и переместить на тестовый сервер.
- Выполнить сборку приложения
- Запустить автоматизированное тестирование, если приложение собралось без ошибок.
Если все три процесса прошли успешно, тогда первые два разворачиваем для продуктовой среды.
Процесс CI/CD
Однако не всё так просто, дьявол кроется в деталях.
Все перезапуски, обновления приложений требуют времени, поэтому сервер перестает быть доступным, когда мы обновляем наше приложение. Рассмотрим несколько проблем, с которыми можно столкнуться в процессе работы.
Проблема № 1
При развертывании произошел сбой сервера – сервис недоступен или работает с ошибкой. В таком случае необходимо ввести дополнительную стадию тестирования после развертывания в продуктовое окружение. В классическом случае – откат из резервной копии, здесь мы получаем неправильно выстроенный процесс CI/CD.
Решение: обращаемся к дополнительным технологиям, например контейнеризации. В этом случае разворачиваем приложение на новой среде – не на физическом сервере, а на еще одной копии, чаще всего для этого используются контейнеры. После того как приложение заработало, делаем новый продуктовый сервер, а старый удаляем.
Уходим на точку балансировки нагрузки – перебалансируем нагрузку со старого продуктового сервера на новый. Если всё заработало на тесте, то для точки балансировки нагрузки мы вводим данные, что тест – это новый прод, а старый прод удаляем.
Проблема № 2
Изменились алгоритмы, выполнение которых необходимо для развертывания приложений. Это связано с тем, что разработчик постоянно обновляет свое приложение и в какой-то момент алгоритмы CI/CD могут устареть. Девопс-разработчики должны быть постоянно вовлечены в процессы поддержки и обновления CI/CD – эти процессы должны быть частью приложения.
Решение: необходимо вести документацию по развертыванию приложения и поддерживать ее в актуальном состоянии. Девопс-инженер занимается обслуживанием серверного ПО.
Проблема № 3
Организация алгоритмов. Система контроля версий позволяет иметь несколько ветвей. Ветвь в репозитории – набор точек (коммитов), расположенных в хронологическом порядке. Основная ветвь (корень) появляется при создании репозитория, а дополнительные используются для исправления ошибок или доработок функционала. Таким образом, все изменения в проекте создаются в дополнительных ветвях, а затем сливаются с основной ветвью.
Иногда процессы CI/CD организуются таким образом, что при успешном их прохождении изменения переносятся в продукт автоматически, а из-за неучтенных нюансов возникает ошибка, и сервер перестает работать.
Решение: нужно производить тестирование на продуктовых данных перед релизом и исключить автоматические переносы изменений в продуктовые ветки. А также контролировать происходящие процессы, не полагаясь на автоматику. Важно иметь регламент, согласно которому осуществляются релизы.
Кто подключен к процессу разработки CI/CD?
-
Девопс – единоличный организатор всей концепции.
-
Тимлид управляет всеми процессами, чаще взаимодействует с заказчиком, ставит задачи девопсу, собирает концепцию приложения воедино.
-
Менеджер проекта ведет учет затрат.
Что нужно сделать, чтобы настроить CI/CD?
- Спланировать все процессы, которые будут происходить в разрезе развертывания приложения.
- Спланировать развертывание приложения.
- Организовать тестирование приложения.
- Проработать организацию взаимодействия всех участников, предусматривать возможные ошибки.
- Выбрать целевую архитектуру.
- Подобрать инструменты.
- Приступить к реализации.
Инструменты для CI/CD
- GitLab – платформа для управления репозиториями, документирования результатов тестирования и разработки, анализа и улучшения функциональности проекта, выявления и исправления ошибок.
- Docker – CD-система для контейнеризации проекта.
- Travis-CI – сервер, который подключается к виртуальным GitHub-репозиториям с минимальными настройками и не требует отдельной установки.
- Jenkins – совместим с различными плагинами для адаптации к различным проектам и задачам.
- PHP Censor – CI-сервер для автоматизации сборки PHP-проектов. Может работать с репозиториями GitLab, Mercurial и др., с тестовыми библиотеками Atoum, PHP Spec, Behat.
Суть непрерывной интеграции заключается в том, что все участники процесса разработки регулярно публикуют изменения, внесенные в код, в центральном репозитории. Начало внедрения непрерывной интеграции заключается в отправке изменений в систему контроля исходного кода. Это необходимо для того, чтобы все участники работали с одним и тем же исходным кодом. Каждый коммит становится триггером для сборки и автоматического тестирования кода с целью проверки его поведения и подтверждения его корректности.
Что касается непрерывного развертывания, то это уже процесс выпуска программного обеспечения, в ходе которого проводится автоматическое тестирование для проверки правильности и стабильности изменений в коде и последующего автоматического развертывания ПО в рабочей среде. Стоит отметить, что непрерывная доставка является составной частью процесса развертывания. Развертывание, по сути, представляет собой доставку программного обеспечения плюс его тестирование перед официальным выпуском для пользователей.
Например, представим ситуацию, когда вы заказываете посылку из интернет-магазина. Интеграция в данном случае представляет собой процесс сборки посылки, ее проверки на предмет правильности вложения, комплектации и т. д. Далее следует этап доставки посылки до пункта выдачи и, наконец, ее непосредственное получение и проверка.
Таким образом, концепция CI/CD помогает разработчикам мгновенного вносить изменения, непрерывно тестировать и совершенствовать продукт, а также взаимодействовать не только друг с другом, но и с заказчиком.
Опубликовано 27.03.2024