Методология разработки CI/CD

В софтверной разработке быстрая и качественная сборка продукта — главное конкурентное преимущество. Если над проектом работает команда программистов, тестировщиков и менеджеров, а изменения в код нужно вносить по нескольку раз в день, каскадная модель сборки (waterfall model), изобретенная еще в 1970-х, — очевидный анахронизм. Мобильные приложения, веб-разработка, игры, e-commerce — те отрасли, где последовательное прохождение стадий проектирования, сборки и тестирования должно быть максимально быстрым. Вместо месяцев на каждый этап счет здесь идет на часы и даже на минуты.

В 1991 году американский программист Гради Буч, будущий лауреат премии «Пионер компьютерной техники», предложил альтернативную концепцию — Continuous integration & Continuous delivery (CI/CD); в переводе — «Непрерывная интеграция / Непрерывное развертывание». Методология опередила время, ее преимущества в полной мере стали осваиваться относительно недавно, в начале 2010-х. Сейчас CI/CD — самая хайповая практика в мире разработчиков.

Главные цели CI/CD — свести к минимуму ошибки, ускорить сборку и повысить качество конечного продукта. В CI/CD тестирование проводится всякий раз, когда в код вносятся изменения. Обнаружение ошибок на ранней стадии разработки существенно экономит время и ресурсы команды, ведь чем позднее выявляется баг, тем труднее и дороже его исправлять. Что касается ускорения, то автоматизация CI/CD помогает значительно оптимизировать все рутинные процессы сборки.

Три кита CI/CD

У методологии CI/CD три подхода, которые используют отдельно или сочетают, в зависимости от стратегии.

Непрерывная интеграция

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

Непрерывная доставка + Непрерывное развертывание

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

Базовый рабочий процесс CI/CD

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

На рисунке ниже изображен базовый GitFlow-процесс:

Внесение изменений, тестирование и сборка новой версии кода происходит в отдельной ветке feature. С помощью инструмента Review Apps можно сделать предпросмотр изменений и увидеть, как будет отрабатывать код в прод-среде. Если разработчик доволен результатом, он может подтвердить изменения (Review and approve), и слить feature-ветку с основной. Далее новая версия кода проходит те же этапы: сборку, тестирование и развертывание, а в финале «выкатывается» на прод; если что-то пойдет не так, изменения можно быстро откатить. На этом этапе очень важно чтобы софтверные окружения Dev и Prod были идентичны.

Циклы CI/CD

Инструмент Cycle Analytics («Аналитика цикла») измеряет время, которое было затрачено на реализацию идеи — от задумки до выпуска продукта. Cycle Analytics показывает узкие места в разработке и причины задержек, которые можно устранить. Cycle Analytics отслеживает семь стадий разработки:

• Задача/Issue (трекер)
• Планирование/Plan (доска)
• Программирование/Code (IDE)
• Тестирование/Test (CI)
• Рецензирование/Review (запрос на слияние)
• Промежуточная стадия/Staging (непрерывное развертывание)
• Производственная стадия/Production (общая продолжительность)

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

• Задача создана в 9:00 (начало стадии Задача).
• Задача добавлена к этапу в 11:00 (конец стадии Задача — начало стадии Планирование).
• В 12:00 начата работа над задачей, создана локальная ветка и внесен один коммит (изменение записано в репозиторий).
• В 12:30 внесен второй коммит в ветке со ссылкой на номер задачи (конец стадии Планирование — начало стадии Программирование).
• В 14:00 записаны изменения в ветку, создан запрос на слияние с инструкцией закрыть задачу в описании (конец стадии Программирование — начало Тестирования и Рецензирования).
• CI запускает скрипты из .gitlab-ci.yml. Занимает 5 минут (конец Тестирования).
• В ходе рецензирования запроса на слияние проблем не найдено, в 19:00 происходит слияние (конец Рецензирования — начало Промежуточной стадии).
• После слияния начинается развертывание в производственной среде, которое завершается в 19:30 (конец Промежуточной стадии).
• Цикл завершен, и сумма значений средней продолжительности предыдущих стадий записывается в Производственной стадии — это время между созданием задачи и развертыванием соответствующего запроса на слияние в производственной среде.

Теперь можно подсчитать длительность каждой стадии и общее время цикла:

• Задача: 2 ч (09:00 – 11:00)
• Планирование: 1 ч (11:00 – 12:00)
• Программирование: 2 ч (12:00 – 14:00)
• Тестирование: 5 мин
• Рецензирование: 5 ч (14:05 – 19:00)
• Промежуточная стадия: 30 мин (19:00 – 19:30)
• Производственная стадия: 10 ч 30 мин (с 09:00 по 19:30)

Итого полный цикл от идеи до релиза продукта занял 10 с половиной часов.

Заключение

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

Эту роль обычно берет на себя DevOps-инженер — специалист, который оптимизирует все этапы разработки ПО (Development Operations). DevOps-инженера можно нанимать в штат; другой вариант — заказать услугу Managed DevOps у поставщика ИТ-сервисов. И в том и в другом случае главная функция DevOps-инженера — обеспечение четкой, слаженной работы всей команды согласно принципам CI/CD. Подробнее о задачах DevOps-инженера расскажем в одном из будущих постов.