Какая разница между CI и CD?

102

Несмотря на тенденцию к автоматизации процессов разработки, есть компании, где тестирование и развертывание не автоматизировано вообще. Отсутствие автоматизированных процессов влияет на скорость внесения изменений. А это увеличивает влияние человеческого фактора. Что в свою очередь негативно влияет на всю компанию в целом. В этой должности я постараюсь объяснить разницу между следующими процессами: Непрерывная интеграция (CI), Непрерывная доставка (CD) и Непрерывное развертывание (CD). Большинство людей не разделяют последние два термина. Но мы обсудим их отдельно, чтобы получить общее понимание.

CI, CD и еще один CD: принцип работы и различия

Непрерывная интеграция CI

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

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

Автоматизация процессов CI позволяет ускорить разработку за счет исключения ручной ручной проверки интеграции с остальным кодом. Это снижает нагрузки на отдел контроля качества (Quality assurance). Делается это за счет более быстрого выявления проблем интеграции с остальной частью приложения. Кроме того, разработчик не сможет сэкономить время, подавая изменения на тестирование без верификации.

Непрерывная доставка CD

Этот этап используется для поставки модифицированной версии приложения в производство.

Например, процесс доставки образов Docker заключается в простой загрузке образа в реестр образов Docker. Затем его загрузке с хост-машины. Системы с повышенными требованиями к безопасности также может возникнуть ситуация, когда хосты Docker не имеют доступа к каким-либо реестрам. В этом случае для доставки образов Docker могут использоваться команды docker save и docker load.

А тех система, которые не используют Docker, доставка может осуществляться через SCM, apt/yum репозитории, ssh, S3-совместимое хранилище для образов ВМ (например, собранных с помощью Packer). Область их применения во многом зависит от возникающих требований и удобства поддержки. В приведенном выше примере с Docker изменения будут доставляться вместе с новым образом посредством загрузки в реестр образов Docker. Автоматизация процессов CD позволяет ускорить доставку, устранить влияние человеческого фактора.

Непрерывное развёртывание CD

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

Инструменты CI/CD

Существует множество SaaS-решений, и для их покрытия потребуется еще один пост. Рассмотрим основные решения, которые легко интегрируются в большинстве случаев:

  • GitLab CI — отличный вариант для команд, которые используют SaaS или локальный экземпляр GitLab. Использует YAML для описания процессов CI/CD.
  • GitHub Actions — хороший, но относительно новый вариант для тех, кто использует GitHub. Также использует YAML для описания процессов CI/CD.
  • Jenkins — это проект с длинной историей. Он позволяет использовать Groovy для описания процессов CI/CD. (Это является преимуществом и недостатком одновременно по многим причинам) и ваш собственный DSL в Jenkinsfile.

Детальный анализ процессов на вымышленном примере.

Давайте представим себе возможный процесс в вымышленной IT-компании и возможные требования, которые выдвигают заинтересованные стороны. Возьмем небольшой IT-отдел с командами разработки, тестирования и эксплуатации. Рабочий процесс организован с помощью Git-flow, а развертывание осуществляется на хостах Docker. Опишем основные требования сторон в таблице.

Рабочий процесс организован с помощью Git-flow

После сбора требований, мы можем описать, как процессы CI/CD будут выполняться в команде:

процессы CI/CD

CI Фаза. Анализ

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

  • При обновлении Pull/Merge Request** выполняется статическая проверка кода на соответствие стандартам кодирования компании. Статический анализ кода на наличие возможных ошибок и уязвимостей, автоматизированный модуль и функциональное тестирование с использованием заглушек вместо внешних сервисов.

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

  • Если у нас есть изменения в основной ветке**, то процесс аналогичен вышеуказанному примеру. Но есть исключение, что теперь образ для интеграции собирается всегда: для дальнейшего развертывания на стенде для общего E2E и приемочного тестирования с остальными компонентами.
  • При установке тега**, образ с приложением построен для производства и после развертывания дымового тестирования.

Почему мы не можем построить общий процесс CI?

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

Чем больше автоматизированных задач, тем более бесполезная работа будет выполняться в общем процессе.

CD (Delivery) Phase. Анализ

В нашем случае доставка — это загрузка изображения докера с приложением в реестр. Из реестра образы будут загружаться на определенный узел Docker во время процесса установки. Реестр может быть общим или отдельным: для среды разработки и тестирования и производственной среды. Это зависит от требований безопасности в компании.

Фаза CD (Развертывание). Анализ

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

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

Например, платформа Hostman будет отвечать за доставку изменений. Образ Docker будет встроен в выбранную ветку из новой версии кода и будет автоматически развернут без простоя. В нашем примере автоматизация закончилась бы на этапе слияния изменений разработчика с веткой релиза.

Заключение

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

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

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

Поделитесь в соц.сетях
  • 1
  •  
  •  
  •  
  •  
  •  
  •  

Оставить комментарий

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