Домой » Теория автоматизации » Какая разница между Continuous Delivery, Continuous Deployment и Continuous Integration

Какая разница между Continuous Delivery, Continuous Deployment и Continuous Integration

Поскольку DevOps закрепляет свои позиции в мире разработки программного обеспечения, то нам следует привыкнуть к новому термину “Continuous”. Непрерывность присутствует, наверное, во всех процессах, связанных с DevOps, и на слуху практически каждый день.

Хотя это слово стало широко распространенным, но некоторым до сих пор не понятно что именно оно означает? Когда оно используется в понятиях Continuous Delivery, Continuous Deployment и Continuous Integration, то как меняется его смысл? И какие именно различия между этими тремя терминами? В этой статье сделана попытка разобраться в данных терпинах и понять как их можно сочетать в одной среде.

Что значит непрерывный?

Прежде, чем мы начнём разбираться в различных концепциях DevOps, следует понять, что значит “непрерывный” в области программного обеспечения. Проще говоря, термин “непрерывности” относится к изменениям программного обеспечения, которые происходят в течении всего процесса разработки ПО.

Конечно же есть доля лукавства в термине “непрерывный”. На самом деле после реализации функционала может пройти некоторое время до того, как код попадёт в продакшен, но это время всё-таки гораздо меньше, чем было до появления DevOps.

Continuous delivery (непрерывная доставка)

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

Разработчик, сделав какую-либо фичу, отправляет её QA-инженерам для тестирования. Тестировщикам легче досконально оттестировать небольшой новый функционал и написать к нему тест-кейсы. Как только все проверки – прошли, новая фича попадает на дальнейшее тестирование авто-тестами и потом уже в релизный брэнч в системе контроля версий.

Continuous delivery поставляет бизнесу каждый функционал постепенно. Это позволяет получить сразу отклик от клиента и, при необходимости, сделать некоторые изменения.

Другие преимущества Continuous delivery:

  1. Внесение нового функционала в back-end для проверки совместимости с системой;
  2. Быстрое реагирование на потребности рынка;
  3. Возможность подстраивания под изменение бизнес-стратегии;
  4. Низкое количество потенциальных ошибок.

Continuous deployment(непрерывное развёртываение)

Continuous deployment часто путают с continuous delivery, хотя между ними существуют чёткие различия, которые следует знать и понимать.

Как выше было уже сказано непрерывная доставка обеспечивает постоянный выпуск обновлений пользователям. А непрерывное развёртывание отвечает за то, чтобы весь новый функционал после тестирования сразу же попал в основную программу без ручного вмешательства инженеров DevOps.

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

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

Continuous integration (непрерывная интеграция)

Непрерывная интеграция является ключевым компонентом практики Agile Development. Основой данной практики является постоянное попадание кода в центральный репозиторий после успешного запуска тестов. Основные цели continuous integration – поиск и устранение потенциальных проблем как можно быстрее, улучшение качества ПО и сокращение время для выпуска обновлений.

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

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

Как это всё работает вместе?

Перед тем как вы дойдёте до непрерываного развёртывания вам предстоит длинный путь. Сначала вы должны будете многое автоматизировать и пройти фазы непрерываной интеграции и доставки.

CI, CD, DevOps

Continuous Integration Continuous Delivery Continuous Deployment
Необходимы автотесты на каждую новую фичу или баг-фикс Тестами должно быть покрыто достаточный объём кода Качество тестов влияет на качество готового продукта
Из-за ранней регрессии меньше багов попадает на продакшен Развёртывание должно быть автоматизировано, обновления должны быть выпущены вручную Развёртывание автоматизировано и тригеры настроены на каждое изменение
Разработчики должны мержится как можно чаще (минимум раз в день) Команда может использовать фича — тоглинг Фиче – тоглинг является неотъемлимой частью больших изменений

Идеальный процесс выглядит примерно так:

  • разработчик отправляет код в центральный репозиторий;
  • на сервере непрерывной интеграции изменения объединяются с основным кодом, выполняются юнит – тесты и всё заливается на стэйжинг среду;
  • в стэйжинг среде QA инженеры тестируют приложение;
  • дальше всё проверяется для попадания на продакшен;
  • развёртывание на продакшене.

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

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*
*