Методология CI/CD: как развиваться

За последние 30 лет ИТ-рынок попробовал немало методик разработки ПО. Началось всё с каскадной модели (waterfall model) — сложного, многоступенчатого процесса, который чем дальше, тем меньше соответствовал быстро меняющемуся рынку. В каскадной модели каждый из разработчиков занят своей частью кода. Интеграция происходит на заключительной стадии сборки, при этом выявление ошибок влечет за собой непредсказуемую задержку релиза. Полный цикл сборки может длиться не один месяц. В той же веб-разработке, где изменения в код нужно вносить часто и быстро, waterfall model малопригодна.

На смену каскадной модели пришли гибкие методологии разработки — такие, как Agile. Ввиду удобства и универсальности ее используют в ритейле, финансах, ИТ и не только, как малый, так и крупный бизнес. У Agile, впрочем, есть ряд минусов, особенно выделяющихся на фоне другой, не менее популярной методологии CI/CD — непрерывной интеграции и доставки кода (Continuous integration & Continuous delivery). В этом посте сделаем краткий сравнительный анализ этих двух методик, а также расскажем, как правильно внедрять CI/CD без лишних затрат и нервов — с опорой на собственный опыт ITGLOBAL.COM.

Agile vs CI/CD

Методология Agile основана на итеративном подходе: команда работает короткими циклами — спринтами, выпуская продукт поэтапно. Agile хороша в тех областях разработки, где требуются быстрые и регулярные, до сотен раз в день, релизы рабочих и обновленных версий ПО: мобильные приложения, GameDev, веб-разработка, e-commerce и т. д. Темпы сборки и релиза диктуют длительность спринта, которая обычно составляет от одной до двух недель — и это как раз одно из проблемных мест Agile, в котором практика расходится с теорией.

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

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

Agile фокусируется на взаимодействии между бизнесом и командой разработчиков, в то время как методология CI/CD — на взаимодействии разработчиков и администратора инфраструктуры, на которой «живут» код и продукт. Предложенные CI/CD принципы дали стимул для развития инструментов автоматизации и упрощения процесса сборки кода. Главные производители ПО — в том числе GitHub и GitLab, — помимо работы с репозиторием, внедрили канбан-доски, визуализирующие рабочий процесс, и автоматизировали деплой (развертывание ПО).

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

Конвейерный режим

Принципы CI/CD тесно связаны с DevOps — особой культурой менеджмента, которая объединяет разработчиков, тестировщиков и поддержку (operations) в единую команду для общей цели — быстрой доставки ПО пользователю. DevOps-инженер собирает проект в единое целое, контролируя процесс разработки и сборки кода, использование правильных технологий и взаимодействие команды.

В рамках DevOps процесс разработки построен по типу конвейера (pipeline). Конвейеризация здесь подразумевает создание единой, непрерывной и максимально автоматизированной цепочки сборки. При этом методология CI/CD непосредственно реализуется с помощью программных инструментов вроде упомянутого GitLab в рамках трех основных этапов:

• Написание кода;
• Тестирование кода (юнит-, UI- и E2E-тесты);
• Развертывание его в производственной среде в виде готового продукта.

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

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

Вывод

Для корректной настройки конвейера в соответствии с методологией CI/CD необходимо понимать вектор развития технологий сборки, уметь пользоваться теми же Docker и Kubernetes, быстро масштабировать архитектуру. Дополнительное преимущество — знание практики IaC («инфраструктура как код»), когда инфраструктура управляется при помощи кода. Однако владения инструментами недостаточно, важно также понимание того, где и какие использовать, и для каких целей — это, собственно, и есть основа правильного развития.

В практике ITGLOBAL.COM встречалось немало клиентских команд, которые применяли Node.js, JavaScript, Docker и другие современные инструменты, — но без настроенного конвейера. Результаты часто бывали далеки от запланированных. Потому что неважно, какие технологии используются, важно, что при невыстроенных процессах возрастает количество факторов, которые негативно отражаются на продукте.

Компания ITGLOBAL.COM накопила большой опыт внедрения методологии CI/CD и готова делиться этим опытом с рынком.