Непрерывная интеграция, непрерывная поставка,непрерывное развертывание,CI,CD

непрерывная интеграция (CI): короткоживущие функциональные ветки, команда сливает их с основной веткой разработки по несколько раз в день, процессы сборки и тестирования полностью автоматизированы, результат имеем в пределах 10 минут; развертывание выполняется вручную.

Непрерывная доставка (CD): автоматизируется CI + весь процесс релиза ПО. Может состоять из нескольких этапов. Развертывание в продакшен выполняется вручную.

непрерывное развертывание : CI + CD + полностью автоматизированное развертывание в продакшен.

Аббревиатуры CI и CD часто используются в контексте современных методов разработки и DevOps. Аббревиатура CI означает непрерывную интеграцию. Это фундаментальная рекомендация DevOps, согласно которой разработчики регулярно проводят слияние изменений кода в центральном репозитории, где выполняются автоматизированные сборки и тесты. При этом аббревиатура CD может означать как непрерывную поставку, так и непрерывное развертывание.

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

При использовании непрерывной интеграции уделяется большое внимание автоматизации тестирования, в результате которого при интеграции новых коммитов в основную ветку работа приложения не нарушается.

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

Это значит, что автоматизирован не только процесс тестирования, но и процесс выпуска продукта, поэтому приложение можно развернуть в любое время одним нажатием.

Теоретически при непрерывной поставке вы можете выпускать релизы ежедневно, еженедельно, каждые две недели или с любой другой периодичностью, актуальной для бизнеса. Однако если вы действительно хотите получить преимущества от непрерывной поставки, следует выполнять развертывание в рабочей среде как можно раньше, обеспечивая выпуск небольших пакетов изменений, в которых легко найти ошибку в случае проблем.

Непрерывное развертывание идет на один шаг дальше, чем непрерывная поставка. При этом подходе каждое изменение, которое проходит все стадии производственного процесса, выпускается клиентам. Вмешательство человека не требуется, и развертыванию нового изменения в рабочую среду может помешать только ошибка во время теста.

Непрерывное развертывание — это отличный способ ускорить цикл обратной связи с клиентами и избавить команду от лишнего напряжения, потому что Дня релиза больше не бывает. Разработчики могут сосредоточиться на создании ПО. Они видят, как их код запускается в работу за считанные минуты, стоит только закончить.

Проще говоря, непрерывная интеграция является частью как непрерывной поставки, так и непрерывного развертывания. А непрерывное развертывание похоже на непрерывную поставку, за исключением того, что релизы выполняются автоматически.

Мы объяснили разницу между непрерывной интеграцией, непрерывной поставкой и непрерывным развертыванием, но еще не рассмотрели причины, по которым стоит внедрять эти подходы. Об этом говорит сайт https://intellect.icu . Очевидно, что внедрение каждого из них требует расходов, но это в значительной степени оправдывается получаемыми преимуществами.

• Вашей команде придется писать автоматические тесты для каждой новой функции, улучшения или баг-фикса.
• Необходим сервер непрерывной интеграции, который может отслеживать основной репозиторий и автоматически запускать тесты для каждого нового отправленного коммита.
• Разработчикам необходимо выполнять слияние своих изменений как можно чаще, как минимум один раз в день.

• В рабочую среду попадает меньше багов, поскольку за счет автоматических тестов ухудшения обнаруживаются на ранних этапах.
• Когда все проблемы интеграции решаются на ранних этапах, сборка релиза проходит легко.
• Переключаться на другой контекст приходится реже, так как разработчики получают предупреждение сразу же, как только нарушат сборку, и могут поработать над исправлением, прежде чем перейти к другой задаче.
• Радикально снижаются затраты на тестирование: ваш CI‑сервер может выполнять сотни тестов за несколько секунд.
• Команда контроля качества тратит меньше времени на тестирование и может сосредоточиться на повышении культуры качества.

• Для непрерывной интеграции нужна прочная основа. Ваш комплект тестов должен покрывать достаточную часть базы кода.
• Развертывания необходимо автоматизировать. Хотя запуск все еще осуществляется вручную, после начала развертывания вмешательство человека требоваться не должно.
• Скорее всего, вашей команде понадобится освоить флаги возможностей, чтобы возможности, работа над которыми не завершена, не влияли на работу клиентов.

• Отныне развертывание ПО перестало быть сложным. Вашей команде больше не нужно тратить несколько дней на подготовку к релизу.
• Можно чаще выпускать релизы, ускоряя цикл обратной связи со своими клиентами.
• Решения по поводу небольших изменений принимаются без лишнего напряжения, что способствует ускорению итераций.

• Ваша культура тестирования должна быть на самом высоком уровне. Качество вашего комплекта тестов будет определять качество ваших релизов.
• Процесс документирования должен идти в ногу с темпами развертываний.
• Флаги возможностей становятся неотъемлемой частью процесса выпуска серьезных изменений. Они обеспечивают возможность координировать работу с другими отделами (такими как поддержка, маркетинг, PR и т. д).

• Вы сможете ускорить процесс разработки, так как вам не нужно будет прерывать его на время релизов. Конвейеры развертывания срабатывают автоматически при каждом внесении изменений.
• Сокращается количество рисков, связанных с релизами, и облегчается выпуск фиксов в случае появления проблем, поскольку каждое развертывание осуществляется после внесения сравнительно небольшого количества изменений.
• Клиенты видят непрерывный поток улучшений, при этом качество повышается каждый день, а не раз в месяц, квартал или год.

Традиционно одной из статей расходов, связанных с непрерывной интеграцией, является установка и обслуживание сервера CI. Однако можно значительно сократить расходы на внедрение этих подходов, используя облачный сервис, например Bitbucket Pipelines, который добавляет возможности автоматизации в каждый репозиторий Bitbucket. Просто добавив файл конфигурации в корень репозитория, можно создать конвейер непрерывного развертывания, который будет выполняться для каждого нового изменения, отправляемого в основную ветку.

Если вы только начинаете работу над новым проектом и у вас пока нет пользователей, вам может быть просто развертывать каждый коммит в рабочую среду. Можно даже начать с автоматизации развертываний и выпустить альфа-версию в рабочую среду без клиентов. Затем, по мере разработки приложения, вы будете повышать культуру тестирования и увеличивать покрытие кода. А к тому времени, когда вы будете готовы подключать пользователей, у вас выработается отличный процесс непрерывного развертывания, где все новые изменения тестируются перед их автоматическим выпуском в рабочую среду.

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

Как только выпуск ПО начнет происходить ежедневно, можно начинать рассматривать возможность непрерывного развертывания. Однако перед этим необходимо убедиться, что к такому повороту готова и остальная часть вашей организации. Документация, поддержка, маркетинг. Эти подразделения тоже должны адаптироваться к новой частоте выпуска релизов. Важно организовать процесс так, чтобы они не пропускали значительных изменений, которые могут повлиять на клиентов.

Непрерывная интеграция, непрерывное развертывание и непрерывная доставка — словно векторы, направление которых совпадает, а модуль отличается. Цель всех трех приемов одинакова: повысить надежность разработки и релизов ПО, а также ускорить разработку и релизы.

Основное отличие между тремя подходами — объем автоматизации при каждом из них. Новички часто путают эти феномены, поскольку не догадываются, что они не взаимоисключающие, а входят друг в друга как матрешки.

Ядро: непрерывная интеграция

Большинство разработчиков, вкатываясь в тему, первым делом знакомятся с непрерывной интеграцией (CI), которая заключается в следующем: все изменения, вносимые в код, объединяются в центральном репозитории (операция называется «слияние»). Слияние происходит несколько раз в день, и после каждого слияния в конкретном проекте срабатывает автоматическая сборка и тестирование.

Бывает, что перед сборкой и тестированием программу требуется скомпилировать (это зависит от языка, на котором она написана). Сегодня все чаще возникает необходимость упаковать приложение в контейнер Docker. Затем автоматические тесты проверяют конкретные модули кода, работу UI, производительность приложения, надежность API и пр. Все эти этапы в совокупности обычно называют «сборкой».

CI – это своеобразная страховочная сетка, позволяющая разработчикам избежать массы проблем перед сдачей проекта. Поэтому программисты чувствуют себя увереннее, сдавая такой код, но сама работа при этом вряд ли ускорится – возможно, развертывание так и будет выполняться вручную, подолгу, и на этом этапе также могут возникать ошибки.

Максимум, что разработчики могут сделать на первом этапе – добиться, чтобы комплект автоматизированных тестов получился исчерпывающим и достаточно стабильным, чтобы можно было спокойно пускать любую сборку, прошедшую CI, сначала в обкатку, а затем и в продакшен. Так можно обойтись без длительного ручного тестирования (QA).

Во-вторых, обратите внимание на скорость CI: я убежден, что разработчики должны получать результат CI максимум за 10 минут, иначе продуктивность падает из-за потери концентрации и частого переключения между задачами. Чтобы ускорить CI, удобно распараллеливать тесты на какой-нибудь мощной платформе.

Переход к непрерывной доставке и развертыванию

Непрерывная доставка (CD) – это практика автоматизации всего процесса релиза ПО. Ижея заключается в том, чтобы выполнять CI, плюс автоматически готовить и вести релиз к продакшену. При этом желательно добиться следующего: любой, кто обладает достаточными привилегиями для развертывания нового релиза может выполнить развертывание в любой момент, и это можно сделать в несколько кликов. Программист, избавившись практически от всей ручной работы, трудится продуктивнее.

Как правило, в процессе непрерывной доставки требуется выполнять вручную как минимум один этап: одобрить развертывание в продакшен и запустить его. В сложных системах с множеством зависимостей конвейер непрерывной доставки может включать дополнительные этапы, выполняемые вручную либо автоматически.

Непрерывное развертывание располагается «на уровень выше» непрерывной доставки. В данном случае все изменения, вносимые в исходный код, автоматически развертываются в продакшен, без явной отмашки от разработчика. Как правило, задача разработчика сводится к проверке запроса на включение (pull request) от коллеги и к информированию команды о результатах всех важных событий.

Непрерывное развертывание требует, чтобы в команде существовала отлаженная культура мониторинга, все умели держать руку на пульсе и быстро восстанавливать систему.

Мне приходилось беседовать со многими командами, практикующими непрерывное развертывание. Выяснилось, что разработчики очень ценят умение настраивать развертывание под различные среды; не менее важно, чтобы все представляли, кто, что и когда развертывал. Разработчики, практикующие CI и желающие перейти к непрерывному развертыванию, для начала автоматизируют развертывание в обкаточную среду, а развертывание в продакшен продолжают делать вручную – одним кликом.

Границы понятий

Поскольку «непрерывная доставка» — более зыбкая концепция, нежели «непрерывная интеграция» и «непрерывное развертывание», первый термин применим в более широком контексте, чем на уровне отдельной службы или приложения – он может описывать работу целой системы и даже организации.

Например, можно сказать, что при полноценной непрерывной интеграции должна быть возможность в случае аварии с нуля создать полноценную копию продакшен-среды – одной командой. Либо условиться, что мы не сможем держать требуемый в команде темп разработки, если не укладываемся с развертыванием нового микросервиса примерно в 5 минут. Именно здесь сложно провести грань между непрерывной доставкой и DevOps. Действительно, логичнее оставить в категории DevOps такие задачи, как автоматизированное предоставление инфраструктуры (для этого применяется практика «инфраструктура как код»), логирование в масштабах всего продукта и отслеживание метрик.

Кроме того, иногда возникает путаница, что означает аббревиатура «CD» в паре «CI/CD». Четкого ответа на этот вопрос нет, но в большинстве случаев эта пара понимается как «непрерывная интеграция и непрерывная доставка». Это логично, если учесть, что непрерывное развертывание – частный случай непрерывной доставки, применимый не в каждой системе.