CI/CD в ПО для бизнеса: как непрерывная интеграция ускоряет реакцию на требования рынка?

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

Кнопки переехали, нужный раздел исчез, или оно вообще не открывается. В лучшем случае вы испытаете легкое раздражение. В худшем – найдете другой сервис, более стабильный и предсказуемый.

А теперь посмотрим на ту же ситуацию глазами бизнеса. Представьте, что ваш отдел маркетинга придумал акцию, которая должна стартовать через три дня. Нужно срочно добавить в приложение новый экран с промокодами и счетчиком времени до конца распродажи. Вы приходите к команде разработки и слышите: «Сделаем, но релиз будет через две недели. У нас ручной процесс, мы выкатываем обновления раз в месяц, потому что боимся что-то сломать».

Долгое время это считалось нормой. Разработка ПО напоминала запуск космического корабля: полгода подготовки, сложная ручная проверка каждого винтика, и молитва, чтобы при взлете ничего не отвалилось. Если что-то шло не так – пользователи просто ждали следующего «окна» для исправления, которое могло случиться через месяц.

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

Как же компаниям удается выкатывать новые функции чуть ли не каждый день и при этом не терять качество? Дело не в том, что у них работают супер-программисты, которые никогда не ошибаются. Дело в процессах, которые страхуют от последствий этих ошибок до того, как с ними столкнутся пользователи.

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

Что такое CI/CD?

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

CI: Continuous Integration (Непрерывная интеграция)

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

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

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

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

Если какой-то тест падает, система мгновенно сообщает команде: «Внимание, только что добавленный код что-то сломал, нужно срочно разбираться». Причем разбираться идет именно тот, кто добавил этот код, а не вся команда. Ошибку чинят сразу, по горячим следам, пока она еще не успела обрасти новыми наслоениями и не забылась.

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

CD: Continuous Delivery (Непрерывная доставка)

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

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

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

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

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

CD: Continuous Deployment (Непрерывное развертывание)

Иногда в аббревиатуре CI/CD вторую букву D расшифровывают иначе – как Continuous Deployment, непрерывное развертывание, но разница здесь принципиальная. В случае с непрерывной доставкой мы останавливались перед последним шагом: решение о выходе на реальных пользователей принимал человек.

Непрерывное развертывание убирает и этот барьер. Если код успешно прошел все тесты на этапе интеграции, если сборка прошла успешно, если тестовая среда подтвердила, что всё работает, – система сама принимает решение выкатить обновление всем пользователям.

Звучит рискованно, и для многих бизнесов это действительно избыточно. Банковским системам или медицинскому ПО не нужны обновления каждый час, им нужна стабильность. Поэтому для них обычно используется модель непрерывной доставки, когда подготовленное обновление ждет одобрения человека.

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

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

Как работает непрерывный конвейер?

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

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

Первый этап: Коммит

Всё начинается с того, что разработчик написал код, проверил, что он запускается у него на компьютере, и готов отправить его коллегам. Этот момент отправки кода в общее хранилище называется коммитом. Как только код попадает в хранилище, просыпается автоматика.

Второй этап: Сборка и модульное тестирование

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

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

Третий этап: Автоматические приемочные тесты

Модульные тесты проверяют детали, но не отвечают на главный вопрос: работает ли программа в целом так, как задумано? Может ли пользователь пройти полный путь от входа в систему до оформления заказа?

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

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

Четвертый этап: Развертывание на тестовой среде

Код успешно прошел все автоматические проверки. Теперь его можно впервые увидеть в деле – не на компьютере разработчика, а в среде, максимально похожей на реальную. Система автоматически разворачивает собранное приложение на специальном тестовом сервере.

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

Важно понимать, что тестовая среда – это полная копия реальной, но с одним отличием: она работает с тестовыми данными и не влияет на настоящих клиентов. Можно проводить любые эксперименты, и если что-то сломается, никто не пострадает.

Пятый этап: Развертывание на продуктивной среде

Последний этап – перенос кода на реальные сервера, где с ним работают все пользователи. Как именно происходит этот перенос, зависит от того, какую модель выбрала компания.

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

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

В любом случае даже после выкатки процесс не заканчивается. Система продолжает следить за работой обновленного приложения: не упали ли сервера, не выросло ли время ответа, не появилось ли необычных ошибок. Если что-то идет не так, механизм может автоматически откатить изменения назад до выяснения причин.

Почему это выгодно?

Скорость вывода новых функций на рынок

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

Для бизнеса это означает:

• Возможность реагировать на действия конкурентов в течение дней, а не месяцев
• Оперативное внесение изменений по запросам пользователей
• Запуск маркетинговых акций строго к назначенной дате без риска переносов
• Быструю проверку гипотез и отказ от неудачных идей до того, как они потратят много ресурсов

Снижение стоимости ошибок

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

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

Стабильность и предсказуемость продукта

Конвейер CI/CD обеспечивает стабильность именно за счет того, что каждое изменение проходит через одни и те же ворота проверок. Вы не выкатываете обновление, в котором уверены на 80%, надеясь, что пронесет. Если тесты написали грамотно, они не пропустят ситуацию, когда новое обновление ломает старую, но важную функцию.

Прозрачность процесса для руководителя

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

Вы всегда можете:

• Посмотреть, на какой стадии находится то или иное изменение
• Увидеть, прошло ли оно тесты и какие именно проверки были пройдены
• Получить объективные данные о качестве кода, а не устные заверения команды
• Понимать, когда конкретно та или иная функция появится у пользователей

Честная цена разработки

Наконец, CI/CD позволяет более честно оценивать стоимость разработки. Когда процесс выкатки долгий и болезненный, команда начинает избегать изменений. Проще сказать заказчику, что что-то сделать нельзя или слишком долго, чем потом проходить через муки релиза.

Когда выкатка становится рутиной, отношение меняется. Экспериментировать становится не страшно. Можно попробовать гипотезу, быстро выкатить ее на небольшую группу пользователей, посмотреть на реакцию и либо развивать успех, либо откатывать неудачное решение. Стоимость такого эксперимента оказывается минимальной, а польза для бизнеса – огромной.

Страхи и правда о CI/CD

Давайте разберем самые распространенные возражения внедрению CI/CD и посмотрим, что за ними стоит на самом деле.

«Это только для крупных компаний, нам пока рано»

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

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

«Это долго и дорого настраивать»

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

В реальности базовый конвейер можно настроить за пару дней работы одного инженера. Начать можно с малого: просто настроить автоматическую сборку проекта после каждого коммита и запуск модульных тестов. Это уже принесет пользу и будет стоить почти бесплатно.

Дороже обходится как раз отсутствие автоматизации. Каждый ручной релиз съедает часы работы команды, которые могли быть потрачены на создание нового функционала.

«Это лишит нас контроля над релизами»

С точки зрения бизнеса, контроль над тем, что и когда попадает пользователям, – критически важная вещь. И поначалу кажется, что если процесс автоматизирован, то решения начинает принимать машина, а человек отстраняется.

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

«У нас слишком сложный проект, это не подойдет»

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

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

Разработка ПО от 66 Бит

Итак, всего за 10 минут вы разобрались что такое CI/CD, как работает конвейер и почему непрерывная интеграция выгодна для вашего бизнеса. А если вы задумались о разработке своего программного обеспечения или внедрении в него новых технологий, советуем обратиться в 66 Бит!

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