Непрерывная интеграция, непрерывная доставка, непрерывное развертывание: просто матрешка

Привет всем!
Напоминаем, что в самом начале сентября у нас вышла интересная книга Эберхарда Вольфа «Continuous delivery. Практика непрерывных апдейтов»
В любой бурно развивающейся отрасли порой бывает полезно определиться с терминами. Для тех, кто пока не успел познакомиться с книгой Вольфа, мы решили перевести небольшую статью Марко Анастасова, где доступно и внятно описаны отличия между Continuous Integration, Continuous Delivery и Continuous Deployment. Добро пожаловать под кат!

Непрерывная интеграция, непрерывное развертывание и непрерывная доставка — словно векторы, направление которых совпадает, а модуль отличается. Цель всех трех приемов одинакова: повысить надежность разработки и релизов ПО, а также ускорить разработку и релизы.
Основное отличие между тремя подходами — объем автоматизации при каждом из них. Новички часто путают эти феномены, поскольку не догадываются, что они не взаимоисключающие, а входят друг в друга как матрешки.
Ядро: непрерывная интеграция
Большинство разработчиков, вкатываясь в тему, первым делом знакомятся с непрерывной интеграцией (CI), которая заключается в следующем: все изменения, вносимые в код, объединяются в центральном репозитории (операция называется «слияние»). Слияние происходит несколько раз в день, и после каждого слияния в конкретном проекте срабатывает автоматическая сборка и тестирование.
Бывает, что перед сборкой и тестированием программу требуется скомпилировать (это зависит от языка, на котором она написана). Сегодня все чаще возникает необходимость упаковать приложение в контейнер Docker. Затем автоматические тесты проверяют конкретные модули кода, работу UI, производительность приложения, надежность API и пр. Все эти этапы в совокупности обычно называют «сборкой».
CI – это своеобразная страховочная сетка, позволяющая разработчикам избежать массы проблем перед сдачей проекта. Поэтому программисты чувствуют себя увереннее, сдавая такой код, но сама работа при этом вряд ли ускорится – возможно, развертывание так и будет выполняться вручную, подолгу, и на этом этапе также могут возникать ошибки.
Максимум, что разработчики могут сделать на первом этапе – добиться, чтобы комплект автоматизированных тестов получился исчерпывающим и достаточно стабильным, чтобы можно было спокойно пускать любую сборку, прошедшую CI, сначала в обкатку, а затем и в продакшен. Так можно обойтись без длительного ручного тестирования (QA).
Во-вторых, обратите внимание на скорость CI: я убежден, что разработчики должны получать результат CI максимум за 10 минут, иначе продуктивность падает из-за потери концентрации и частого переключения между задачами. Чтобы ускорить CI, удобно распараллеливать тесты на какой-нибудь мощной платформе.
Переход к непрерывной доставке и развертыванию
Непрерывная доставка (CD) – это практика автоматизации всего процесса релиза ПО. Ижея заключается в том, чтобы выполнять CI, плюс автоматически готовить и вести релиз к продакшену. При этом желательно добиться следующего: любой, кто обладает достаточными привилегиями для развертывания нового релиза может выполнить развертывание в любой момент, и это можно сделать в несколько кликов. Программист, избавившись практически от всей ручной работы, трудится продуктивнее.
Как правило, в процессе непрерывной доставки требуется выполнять вручную как минимум один этап: одобрить развертывание в продакшен и запустить его. В сложных системах с множеством зависимостей конвейер непрерывной доставки может включать дополнительные этапы, выполняемые вручную либо автоматически.
Непрерывное развертывание располагается «на уровень выше» непрерывной доставки. В данном случае все изменения, вносимые в исходный код, автоматически развертываются в продакшен, без явной отмашки от разработчика. Как правило, задача разработчика сводится к проверке запроса на включение (pull request) от коллеги и к информированию команды о результатах всех важных событий.
Непрерывное развертывание требует, чтобы в команде существовала отлаженная культура мониторинга, все умели держать руку на пульсе и быстро восстанавливать систему.
Мне приходилось беседовать со многими командами, практикующими непрерывное развертывание. Выяснилось, что разработчики очень ценят умение настраивать развертывание под различные среды; не менее важно, чтобы все представляли, кто, что и когда развертывал. Разработчики, практикующие CI и желающие перейти к непрерывному развертыванию, для начала автоматизируют развертывание в обкаточную среду, а развертывание в продакшен продолжают делать вручную – одним кликом.
Границы понятий
Поскольку «непрерывная доставка» — более зыбкая концепция, нежели «непрерывная интеграция» и «непрерывное развертывание», первый термин применим в более широком контексте, чем на уровне отдельной службы или приложения – он может описывать работу целой системы и даже организации.
Например, можно сказать, что при полноценной непрерывной интеграции должна быть возможность в случае аварии с нуля создать полноценную копию продакшен-среды – одной командой. Либо условиться, что мы не сможем держать требуемый в команде темп разработки, если не укладываемся с развертыванием нового микросервиса примерно в 5 минут. Именно здесь сложно провести грань между непрерывной доставкой и DevOps. Действительно, логичнее оставить в категории DevOps такие задачи, как автоматизированное предоставление инфраструктуры (для этого применяется практика «инфраструктура как код»), логирование в масштабах всего продукта и отслеживание метрик.
Кроме того, иногда возникает путаница, что означает аббревиатура «CD» в паре «CI/CD». Четкого ответа на этот вопрос нет, но в большинстве случаев эта пара понимается как «непрерывная интеграция и непрерывная доставка». Это логично, если учесть, что непрерывное развертывание – частный случай непрерывной доставки, применимый не в каждой системе.
Небольшое резюме и заключительные мысли
- Непрерывная интеграция (CI): короткоживущие функциональные ветки, команда сливает их с основной веткой разработки по несколько раз в день, процессы сборки и тестирования полностью автоматизированы, результат имеем в пределах 10 минут; развертывание выполняется вручную.
- Непрерывная доставка (CD): автоматизируется CI + весь процесс релиза ПО. Может состоять из нескольких этапов. Развертывание в продакшен выполняется вручную.
- Непрерывное развертывание: CI + CD + полностью автоматизированное развертывание в продакшен.
- continuous delivery
- continuous integration
- тестирование
- высокая производительность
- программирование
- книги
Что такое непрерывная поставка?
Непрерывное предоставление ценности стало обязательным требованием для организаций. Чтобы обеспечить ценность конечным пользователям, необходимо постоянно выпускать и без ошибок.
Непрерывная доставка (CD) — это процесс автоматизации сборки, тестирования, настройки и развертывания из сборки в рабочую среду. Конвейер выпуска может создавать несколько сред тестирования или промежуточных сред для автоматизации создания инфраструктуры и развертывания новых сборок. Последовательные среды поддерживают постепенно более длительные действия по интеграции, загрузке и тестированию принятия пользователей.

До CD циклы выпуска программного обеспечения были узким местом для групп приложений и операций. Эти команды часто зависят от ручной передачи, которые привели к проблемам во время циклов выпуска. Процессы вручную привели к ненадежным выпускам, которые приводили к задержкам и ошибкам.
CD — это бережная практика, с целью обеспечения актуальности рабочей среды с самым быстрым путем от нового кода или доступности компонентов к развертыванию. Автоматизация сводит к минимуму время развертывания и времени для устранения (TTM) или времени для устранения рабочих инцидентов (TTR ). В кратных терминах CD оптимизирует время процесса и устраняет время простоя.
Непрерывная интеграция (CI) запускает процесс CD. Конвейер выпуска выполняет этапы каждой последовательной среды в следующую среду после успешного завершения тестов. Конвейер автоматического выпуска CD позволяет быстро выполнить проверку, где тесты, скорее всего, завершаются сбоем, а более длительные тесты выполняются только после успешного завершения более быстрых тестов.
Дополнительные методики инфраструктуры как кода (IaC) и мониторинга упрощают cd.
Прогрессивные методы воздействия
CD поддерживает несколько шаблонов для прогрессивного воздействия, также называемого «контролем радиуса взрыва». Эти методики ограничивают воздействие на развертывания, чтобы избежать проблем с общей базой пользователей.
- CD может последовательность нескольких кругов развертывания для прогрессивного воздействия. Кольцо пытается развернуть в группе пользователей и отслеживает их взаимодействие. Первое кольцо развертывания может быть канарной для тестирования новых версий в рабочей среде перед более широким развертыванием. CD автоматизирует развертывание из одного круга в следующее. Развертывание на следующем кольце может при необходимости зависеть от шага утверждения вручную, где создатель решений подписывает изменения в электронном виде. CD может создать проверяемую запись утверждения для удовлетворения нормативных процедур или других целей контроля.
- Развертывание blue/green зависит от сохранения существующей синей версии в режиме реального времени при развертывании новой зеленой версии. Эта практика обычно использует балансировку нагрузки для прямого увеличения объема трафика к зеленому развертыванию. Если во время мониторинга обнаруживается ошибка, трафик перенаправляется на оставшееся синее развертывание.
- Флаги функций или переключатели функций — это еще один способ экспериментирования и темных запусков. Флаги компонентов включите или отключите функции для различных групп пользователей на основе удостоверений и членства в группах.
Современные конвейеры выпусков позволяют командам разработчиков развертывать новые функции быстро и безопасно. Cd может быстро устранить проблемы, обнаруженные в рабочей среде, перенаправив развертывание. Таким образом, CD создает непрерывный поток ценности клиента.
Следующие шаги
- GitHub Actions
- Azure Pipelines
- Документация по Azure Pipelines
Что такое непрерывная доставка?
Непрерывная доставка – это практика разработки программного обеспечения, когда при любых изменениях в программном коде выполняется автоматическая сборка, тестирование и подготовка к окончательному выпуску. Непрерывная доставка является одним из основополагающих принципов разработки современных приложений, поскольку расширяет практику непрерывной интеграции за счет того, что все изменения кода после стадии сборки развертываются в тестовой и/или в рабочей среде. При правильном внедрении у разработчиков всегда будет готовый к развертыванию собранный экземпляр ПО, прошедший стандартизированную процедуру тестирования.
Непрерывная доставка позволяет разработчикам не только автоматизировать тестирование на уровне модулей, но и выполнять разноплановую проверку обновлений приложений перед тем, как развертывать их для конечных пользователей. Такое тестирование может включать тестирование пользовательского интерфейса, загрузки, интеграции, надежности API и т. д. Все это позволяет разработчикам тщательнее проверять обновления и заблаговременно выявлять возможные проблемы. В отличие от устаревших локальных решений, облачная среда позволяет легко и экономично автоматизировать создание и репликацию нескольких сред тестирования.
Непрерывная доставка и Непрерывное развертывание
При непрерывной доставке каждое изменение программного кода проходит сборку, тестируется и затем отправляется в подготовительную (тестовую или имитационную) среду. Перед развертыванием в рабочей среде можно использовать несколько параллельных стадий тестирования. Отличие непрерывной доставки от непрерывного развертывания заключается в том, что при непрерывной доставке для развертывания обновлений в рабочей среде требуется подтверждение вручную. При непрерывном развертывании это происходит автоматически без специального подтверждения.

Непрерывная доставка автоматизирует весь процесс выпуска ПО. Каждое подтверждение записи версии запускает автоматический процесс сборки, тестирования и размещения обновления. Окончательное решение о развертывании в реальной рабочей среде инициируется разработчиком.
CI/CD
CI/CD (Continuous Integration, Continuous Delivery — непрерывная интеграция и доставка) — это технология автоматизации тестирования и доставки новых модулей разрабатываемого проекта заинтересованным сторонам (разработчикам, аналитикам, инженерам качества, конечным пользователям и др.).

«IT-специалист с нуля» наш лучший курс для старта в IT
Принципы CI/CD
Концепция непрерывной интеграции и развертывания относится к agile-методологиям разработки программного обеспечения. Ее основная цель — уделение достаточного внимания бизнес-требованиям, безопасности и качеству кода конечного продукта. В рамках подхода решаются следующие задачи:
- автоматизация последовательной сборки, упаковки и тестирования программных продуктов;
- автоматизация развертывания приложения в различных окружениях;
- минимизация ошибок и уязвимостей программного продукта.
Разработка по методике CI/CD соответствует таким основным принципам:
- Распределение ответственности. Задачи и этапы разработки разделяются между членами команды или ее подгруппами (при работе над большим проектом). Рабочий процесс организуется с учетом бизнес-логистики, внедрения сквозных функций, проведения тестов, безопасности хранения данных и т.д.
- Сокращение рисков. Каждый разработчик или подгруппа разработчиков должны стремиться минимизировать уязвимости и ошибки на всех этапах разработки. Для этого постоянно контролируется бизнес-логистика, проводится пользовательское тестирование продукта, оптимизируется хранение, обработка данных и т.д.
- Оптимизация обратной связи. Успех проекта зависит от того, как работают друг с другом разработчики, клиенты и пользователи. Это влияет на скорость внесения в приложение корректировок и обновлений. Если сборку и тестирование можно автоматизировать, то во многих других операциях требуется участие человека. Чтобы взаимодействие происходило конструктивнее, уменьшается количество посредников между заказчиком, исполнителями и пользователями.
- Создание рабочей среды. Для удобства совместной работы у разработчиков должно быть общее рабочее пространство. Помимо основной ветки процесса в нем должна быть побочная – в ней удобнее проводить тестирование, вносить корректировки, отслеживать отказоустойчивость и т.д.
Профессия / 8 месяцев
IT-специалист с нуля
Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

СI/CD представляет собой современную аналогию конвейерного производства. Их объединяют четкое распределение труда, непрерывный, потоковый характер рабочего процесса, параллельное выполнение сразу нескольких задач (например, кодинга и тестирования). Сегодня эта концепция является доминирующей в DevOps.
Читайте также Как выбрать IT-специальность в новых реалиях?
Этапы CI/CD
Написание кода. Каждый разработчик создает код отведенного ему модуля и тестирует его в ручном режиме. Затем разработанный и проверенный программный блок интегрируется в основной ветке с текущей версией продукта. Как только все модули будут опубликованы в главной ветке, команда переходит к следующему этапу.
Сборка. Заранее подобранная система контроля версий запускает автоматизированную сборку и тестирование всего продукта. Триггеры могут быть настроены автоматически или вручную. Автоматическая сборка выполняется с помощью Jenkins или другого сервера непрерывной интеграции.
Ручное тестирование. Как только CI-сервер закончит автоматизированную сборку продукта, он передается тестировщикам на проверку. Они используют различные методики тестирования для выявления и устранения ошибок и уязвимостей программы.
Релиз. После исправления ошибок вычищенный и отлаженный код переходит на этап релиза для клиентов. Его проверяет заказчик, возможно, с привлечением своих специалистов или ограниченной группы пользователей. По результатам проверки код отправляется на доработку или согласуется.
Развертывание. Текущая версия программы размещается на продакшн-серверах разработчика. Заказчик может работать с программой, исследовать ее функции, искать уязвимости.
Поддержка и отслеживание. После развертывания приложение становится доступным конечным пользователям. Параллельно этому разработчики выполняют его поддержку и одновременно мониторят реакцию пользователей, анализируют их опыт взаимодействия с программой.
Планирование. На основании данных, полученных при изучении пользовательского опыта, разработчик подготавливает план доработок, включающий новые функции, исправление ошибок и т.д. После этого он вносит все корректировки в продукт — и цикл разработки начинается снова.
Таким образом, рабочий процесс по методологии CI/CD включает как последовательные, так и параллельные этапы. Именно для распараллеливания в рабочем пространстве создается побочная ветка — в ней проще вести работу, не вмешиваясь в основной код до тех пор, пока программируемый модуль не будет готов к интеграции. Условно рабочий процесс по методологии CI/CD можно представить в виде следующей схемы:

Преимущества CI/CD
- Сокращение сроков разработки. Методология уменьшает время доработок до нескольких дней, в сложных проектах — недель. Это позволяет разработчикам быстрее тестировать и опробовать нововведения, а затем внедрять их в продукт раньше конкурентов.
- Отбор перспективных вариантов. Быстрое тестирование и большое количество итераций позволяют разработчику вовремя отсеивать бесперспективные варианты кода на начальных этапах. Это также способствует экономичному расходованию времени и ресурсов без их распыления на тупиковые направления.
- Качество тестирования. Сочетание ручной и автоматизированной проверки позволяет выявлять ошибки на ранних этапах разработки. Это снижает вероятность их накопления на этапе релиза, что еще больше сокращает время работы над проектом.

Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить
Недостатки CI/CD
- Высокие требования к опыту. Рабочий процесс в любой компании можно перевести на методологию CI/CD. Однако это требует от разработчиков как знания самой концепции на практическом уровне, так и умения быстро реорганизовать процессы в самой организации. Иными словами, CI/CD имеет достаточно большой порог вхождения в сравнении со многими традиционными методологиями.
- Сложность постоянного взаимодействия. Непрерывная интеграция и доставка программного продукта требуют от разработчиков высокой скоординированности действий. На практике это означает, что должно быть отдельное лицо, которое занимается организацией рабочего процесса и налаживанием взаимодействия между членами команды.
Инструменты для CI/CD
Так как непрерывная интеграция и развертывание подразумевает автоматизацию многих процессов в ходе разработки, для этого созданы различные программные инструменты и сервисы:
- GitLab. Эта платформа позволяет управлять хранилищами проекта, документировать результаты тестирования и доработок, анализировать и дополнять функциональность проекта, выявлять и устранять ошибки.
- Docker. СD-система, позволяющая контейнеризировать проект, то есть упаковать его со всем окружением и зависимостями.
- Travis-CI. Сервер, который можно подключать к виртуальным репозиториям GitHub с минимальными настройками. Благодаря использованию облачных технологий его не нужно отдельно устанавливать.
- Jenkins. Один из самый популярных DevOps-инструментов, совместимый со всевозможными плагинами для адаптации под различные проекты и задачи.
- PHP Censor. CI-сервер, автоматизирующий сборку PHP-проектов. Может работать с репозиториями GitLab, Mercurial и другими, с библиотеками для тестирования Atoum, PHP Spec, Behat.
Возможность оперативно вносить изменения, постоянно тестировать и дорабатывать продукт, взаимодействовать не только друг с другом, но и с клиентом — вот что делает концепцию CI/CD популярной среди разработчиков. Сегодня ее понимание и практическое освоение являются важной рекомендацией при разработке как крупных, так и небольших проектов.
IT-специалист с нуля
Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.

Статьи по теме: