Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) являются неотъемлемыми частями и фундаментом DevOps. Цель, которую преследуют CI/CD – получение качественного кода в сжатые сроки. Когда изменения в организации происходят постоянно, становятся нормой, то и циклы разработки ПО становятся более частыми. Используя процессы CI/CD в разработке программного обеспечения, можно добиться более частого выпуска обновлений на постоянной основе без потери в качестве.
Традиционный подход к интеграции
Изначально у команды разработчиков могло не быть центрального сервера сборки. При этом исходный код мог храниться в едином репозитории, но разработчики не обязательно регулярно вносили туда наработанные изменения кода. Перед запланированным релизом разработчики вручную интегрировали созданные командой изменения, что приводило к множеству проблем, например, из-за коллизий на последних минутах, когда многие разработчики одновременно объединяли куски кода, или вследствие отказа компонентов интеграции.
Недостатки традиционной модели интеграции заключаются в следующем:
- разработчики нерегулярно и нечасто интегрируют код в репозитории, что приводит к появлению коллизий (обычно в самый последний момент перед релизом);
- долгая обратная связь;
- трудности с решением проблем из-за большого числа компонентов;
- проблемы с соблюдением сроков разработки;
- высокая стоимость.
Чтобы избавиться от недостатков традиционной модели, был разработан подход CI/CD, который включает в себя множество преимуществ как с технической точки зрения, так и с точки зрения бизнеса.
Непрерывная интеграция
Непрерывная интеграция – практика разработки ПО, при использовании которой от разработчиков требуется выкладывать код в центральном репозитории на регулярной основе – несколько раз в день. Затем каждое обновление кода проверяется при помощи автоматизированных тестов, что позволяет команде разработчиков обнаруживать проблемы на самых ранних стадиях. Это позволяет командам тратить меньше времени поиск проблем в коде и больше времени на создание новых функций.
Основная идея заключается в том, чтобы иметь не одного или пару, а множество разработчиков в проекте, сохраняя при этом основную ветку кода в репозитории в актуальном виде. Каждый из разработчиков может в любое время обратиться к нему за получением последней версии кода.
Процесс интеграции
Разработчики пишут код в своих собственных отдельных ветках, а затем переносят результаты в центральный репозиторий. Запускаются автоматизированные модульные и интеграционные тесты. По их результатам вскрываются ошибки и другие проблемы с качеством кода. После того, как автоматизированные тесты успешно пройдены, разработчики могут просматривать изменения в общей ветке кода и создавать “запросы на включение изменений” (pull requests). Данный механизм позволяет разработчикам напрямую рецензировать и предлагать изменения в основной ветви кода, созданные другими разработчиками, работающими над проектом.
После завершения процесса проверки и объединения нового кода в основную ветвь, циклы дальнейшего рецензирования, проверки и исправления ошибок продолжаются на базе интегрированной основной ветви. Зачастую это происходит по нескольку раз в день, особенно для большой команды, где каждый работает над множеством небольших задач. При этом все работают с одной и той же версией кода. Расхождение версий кода и связанные с этим проблемы, которые могут возникать из-за рассинхронизации действий разработчиков, существенно уменьшаются или сходят на нет.
Непрерывная поставка
Непрерывная поставка – это процесс, в котором изменения в коде автоматически приводят к созданию новой сборки, тестированию и подготовке к выпуску. В результате создаваемое ПО может быть направлено в продуктив в любое время.
Непрерывно интегрируемые новые куски кода дополнительно тестируются на производительность и функциональность до тех пор, пока не будут одобрены разработчикам-рецензентами для включения в основную ветвь кода. Для надёжного и бесперебойного функционирования процесса непрерывной поставки очень важен фундамент в виде эффективного процесса непрерывной интеграции. При правильной реализации разработчики всегда будут иметь готовую к развертыванию версию сборки, прошедшую через стандартизированный процесс тестирования.
Процесс начинается, когда разработчик отправляет написанный код в репозиторий, и заканчивается после полного завершения тестирования, чтобы код был полностью готов к развертыванию в продуктивном окружении. Если во время автоматического тестирования возникнут какие-либо ошибки или недочеты, инструмент CI автоматически уведомит разработчика посредством электронной почты или SMS.
Непрерывная поставка обычно включает в себя стейджинг-среду – окружение, максимально приближенное к промышленному, но без реальных данных, где изменения принимаются вручную перед выпуском в продуктив. Решение о готовности и выпуске в производство – это уже больше решение бизнеса, а не ИТ.
Непрерывное развёртывание
Непрерывное развёртывание очень похоже на непрерывную поставку. Единственное различие между ними заключается в том, что при непрерывном развёртывании любой добавленный кусок кода, прошедший все этапы автоматического тестирования, будет будет сразу же выпущен в промышленную среду.
Непрерывное развёртывание не требует какого-либо дополнительного ручного тестирования в стейджинг-среде, поскольку автоматическое тестирование выполняется на предшествующих этапах. И непрерывная поставка, и непрерывное развёртывание сильно зависят от готовности инфраструктуры и мониторинга приложений, чтобы как можно скорее обнаруживать любые проблемы, которые не были идентифицированы в циклах обратной связи на этапах тестирования, поскольку никакой ручной проверки не предусмотрено.
Преимущества CI/CD
Уменьшение рисков. Некоторые задачи, например, тестирование работы приложения в разных версиях разных браузеров, могут быть автоматизированы, чтобы снизить риск возникновения ошибок.
Быстрое время выхода на рынок. Ошибки в коде обнаруживаются на более ранних этапах и могут быть оперативно устранены, что приводит к увеличению скорости поставки.
Единый источник. Все члены команды разработчиков используют один и тот же центральный репозиторий для написания своего кода. Всегда известно, какие изменения были сделаны, и кем.
Увеличение охвата кода. Сервер CI проверяет наличие тестового покрытия для каждой сборки. Везде, где вы добавляете новые строки кода без нужных тестовых классов, сервер выдаст ошибку, поскольку нет достаточного покрытия кода. Соответственно, разработчики будут вынуждены работать над увеличением покрытия на более низких уровнях, чтобы не было никаких проблем при развертывании.
Качество: от хорошего к великолепному. CI помогает инженерам по контролю качества тратить на 50% меньше времени от общего времени проекта, проводя номинальные тесты для интеграции, ища ошибки и другие проблемы. Это позволяет команде контроля качества глубже погружаться в проблемы, разрабатывать больше тестовых сценариев и в итоге получать общее улучшение результатов.
Уменьшение бэклога. CI / CD уменьшает количество небольших дефектов в бэклоге. Они уже известны заранее и фиксируются перед релизом.
Удовлетворённость заказчиков. Неперывная поставка и развёртывание позволяют получать обратную связь в режиме реального времени, а также оперативно исправлять просчёты команды. При таком подходе разработка нового продукта будет более совершенной и будет в большей степени соответствовать ожиданиям конечного пользователя.
Снижение конфликтов в командах. Практика использования CI гарантирует, что код, написанный несколькими разработчиками в разных местах, всегда интегрируется в центральный репозиторий. Это позволяет избежать хаоса и проблем, возникающих в результате обновлений кода.
Переход к непрерывной интеграции и непрерывной поставке значительно меняет процесс разработки программного обеспечения, позволяя упростить его, тем самым помогая создавать стабильный, безопасный и качественный продукт.
