Методология разработки CI/CD
В софтверной разработке быстрая и качественная сборка продукта — главное конкурентное преимущество. Если над проектом работает команда программистов, тестировщиков и менеджеров, а изменения в код нужно вносить по нескольку раз в день, каскадная модель сборки (waterfall model), изобретенная еще в 1970-х, — очевидный анахронизм. Мобильные приложения, веб-разработка, игры, e-commerce — те отрасли, где последовательное прохождение стадий проектирования, сборки и тестирования должно быть максимально быстрым. Вместо месяцев на каждый этап счет здесь идет на часы и даже на минуты.
В 1991 году американский программист Гради Буч, будущий лауреат премии «Пионер компьютерной техники», предложил альтернативную концепцию — Continuous integration & Continuous delivery (CI/CD); в переводе — «Непрерывная интеграция / Непрерывное развертывание». Методология опередила время, ее преимущества в полной мере стали осваиваться относительно недавно, в начале 2010-х. Сейчас CI/CD — самая хайповая практика в мире разработчиков.
[text_with_btn btn=»Узнать больше» link=»https://itglobal.com/ru-by/managed-it/outsourcing-services/managed-devops/»]Managed DevOps[/text_with_btn]Главные цели 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-инженера расскажем в одном из будущих постов.