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

Александра Смолик

руководитель агентства 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 в свои проекты, как это делаем мы в агентстве и пользуйтесь на здоровье. Если вы все еще сомневаетесь или остались какие-то вопросы, пишите комментарии и мы постараемся ответить.