Роль CI/CD в DevOps

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

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

В 2001 году, когда эта тенденция только начала проявляться, группа разработчиков ПО разработала манифест Agile, предлагая решение для ряда проблем, существовавших в тот момент в сфере разработки ПО. Манифест описывает ценности и принципы разработки программного обеспечения, которые могут быть реализованы в виде различных методологий. Одна из наиболее известных из них — Scrum.

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

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

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

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

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

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

Создание автоматического CI/CD-пайплайна позволяет реализовать принципы DevOps на практике.

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

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

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

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

Задача CI/CD и DevOps в целом — ускорить процесс доставки нужного пользователями ПО без ущерба для качества. Принципы DevOps перекликаются с идеями Agile и «бережливого производства» и дополняют их. Рассматривая весь процесс разработки и доставки ПО в целом и оптимизируя каждый его этап, можно быстрее создавать продукт и быстрее получать обратную связь. Тем самым обеспечивается непрерывное развитие и улучшение продукта.