Сервисы
Managed IT
Решения
Security
Импортозамещение
Партнерам
О компании

Методология разработки 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 отслеживает семь стадий разработки:

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

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

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

Заключение

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

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