CI/CD или конвейер качественного кода

Обложка: CI/CD или конвейер качественного кода
5
Александра Смолик
Александра Смолик

руководитель агентства CHILLICODE

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

Можно ли избежать страха и ненависти как клиента, так и конечных пользователей? Равно как и потери значительной части времени специалистов от общего количества часов разработки? Мы в агентстве CHILLICODE считаем, что да. И в этом нам может помочь применение методологии CI/CD.

Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения программного обеспечения.

В свое время Генри Форд перевел создание автомобилей от ручной сборки к поточному конвейерному производству, перевернув тем самым промышленность своего времени. Принцип действия CI/CD (Continuous Integration & Continuous Deployment) в чем-то похож на конвейер: методика выполняет интеграционную функцию, включая различные типы автоматических тестов на каждом этапе, с последующей доставкой и развёртыванием кода в готовый продукт для конечного пользователя.

Мы у себя с недавнего времени внедрили CI/CD в большинство  наших проектов, что позволило выстроить процесс релиза обновлений буквально в один клик, снизить риски появления багов, внедрив автотестирование и анализ качества кода перед каждым релизом, а также исключить особенности различий окружения хоста разработчика и сервера путем упаковки приложения в так называемые «контейнеры».

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

Какие этапы релиза можно автоматизировать?

Тестирование и контроль качества

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

Сборка и упаковка кода

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

Открытая отчетность

При добавлении клиента в репозиторий, он сможет самостоятельно отслеживать все процессы тестирования, сборки и доставки приложения на прод.

Как обезопасить релиз?

В каких местах могут возникнуть проблемы?

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

Как предохраниться от логических ошибок функциональности и багов?

Чтобы полностью исключить ошибки при деплое стоит комбинированно подойти к каждой итерации разработки продукта. Мы в CHILLICODE проводим релизы проектов в 5 этапов:

  1. После разработки новой фичи разработчик создает запрос на слияние ветки с новой функциональностью в основную ветвь приложения.
  2. Тимлид проекта перед слиянием проверяет качество его кода и при возникновении проблем отправляет код на доработку.
  3. После принятия запроса на слияние приложение проходит несколько этапов автоматического тестирования, анализа качества кода и разворачивается на нашем стейдж сервере.
  4. Выделенный QA специалист дополнительно проверяет всю функциональность приложения на стейдж серверах перед показом клиенту.
  5. И уже после одобрения клиентом всех правок мы отправляем приложение в релиз.

Что делать если критическая ошибка все равно осталась незамеченной и попала в прод?

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

Итого

При работе с CI/CD мы имеем:

  • Сокращение действий для деплоя до одного клика.
  • Снижение рисков появления потенциальных ошибок.
  • Автоматизация модульных и регрессионных тестов.
  • Щепетильный контроль качества кода.
  • Контейнеризация приложений и исключение различий среды разработки со средой выполнения.
  • Возможность моментального отката версии приложения при возникновении критических ситуаций.
  • Общее сокращение времени разработки на 10-20%.

Внедряйте CI/CD в свои проекты, как это делаем мы в агентстве и пользуйтесь на здоровье. Если вы все еще сомневаетесь или остались какие-то вопросы, пишите комментарии и мы постараемся ответить.

Что думаете?