Почему конвейер разработки ПО не срабатывает, и как это исправить

Сергей Зинкевич

директор по развитию бизнеса КРОК Облачные сервисы

Для организации процесса современной ИТ-разработки в России принято использовать концепции и практики непрерывной интеграции и доставки (CI/CD). О ней говорят много, но, как часто бывает на практике, редко кто применяет правильно. Причина кроется в нехватке специалистов, которые могли бы методологически выстроить конвейер и автоматизировать её. Расскажем о том, какие распространенные ошибки в CI/CD мы видим в проектах.

Но сначала немного ликбеза

CI/CD — это целая культура, которая включает в себя набор принципов и реализует последовательность этапов доставки программного обеспечения с момента его написания разработчиком до развёртывания в продуктивном контуре. Собственно, в основе данной аббревиатуры отдельные шаги, которые принято рассматривать в комплексе:

• Continuous integration — непрерывная интеграция;
• Continuous delivery — непрерывная доставка;
• Continuous deployment — непрерывное развёртывание.

Continuous integration (CI) – это упаковка приложения разработчиком и тестирование. На шаге планирования у бизнеса или владельца продукта появляется идея, как улучшить клиентский сервис и какие фичи для этого нужны. На этом же этапе аналитик собирает бизнес-требования и передаёт их разработчику.

Тот (или скорее те, так как в крупной компании в разработке занято несколько человек) пишет код и загружает так называемый билд — изменённое приложение — в отдельную ветку. Билд тестируется — вручную и/или с помощью автотестов — и переходит на следующий этап конвейера.

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

Continuous deployment – это процесс непрерывной доставки кода до продуктива без каких-либо дополнительных согласований и ручных операций. Мониторинг таких выкаток должен также осуществляться постоянно и автоматизированно. Его цель – молниеносно определить проблему с билдом и дать возможность разработчику откатить назад версию приложения и параллельно «пофиксить» ошибки.

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

Распространённые ошибки при реализации CI/CD

Слабо применяется автоматизация

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

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

В результате в 2-3 раза увеличивается срок выпуска в эксплуатацию приложения, а вместе с этим растет количество конфликтов внутри команды, так как сложно понять, на каком этапе процесс стопорится.

Нет формально прописанных зон ответственности

Нередко видим другую ситуацию — в целом процесс CI/СD работает неплохо, но иногда даёт сбой. ИТ-директор одного российского банка как-то жаловался, что при выкатке новой версии релиза часть пакетов и скриптов «не доезжает», а обратная связь о неработающих сервисах при этом приходит не от DevOps-инженеров, а непосредственно от пользователей.

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

Чтобы это исправить, рекомендуется использовать RACI-матрицу. Её, к слову, часто применяют провайдеры. Они «на берегу» определяют, кто и за что будет отвечать в проекте. Например, мы прописываем в документе свою обязанность разворачивать и поддерживать виртуальные машины и инфраструктурные компоненты там, где являемся поставщиками инфраструктуры и кластеров Kubernetes. А сам софт и доступность CI остаются на совести клиента.

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

Отказ следовать IaC

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

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

Так, первичное развёртывание инфраструктуры может стоить условно 100 000 руб, но повторное, основанное на готовом шаблоне, потребует всего 35 000 руб, так как трудозатраты не пойдут ни в какое сравнение с тем, что было до автоматизации.