Что такое CI / CD? Объяснение непрерывной интеграции и непрерывной доставки

Непрерывная интеграция (CI) и непрерывная доставка (CD) воплощают в себе культуру, набор принципов работы и набор практик, которые позволяют командам разработчиков приложений более часто и надежно вносить изменения в код. Реализация также известна как конвейер CI / CD

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

CI / CD определены

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

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

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

Инструменты CI / CD помогают сохранять параметры среды, которые должны быть упакованы при каждой доставке. Затем автоматизация CI / CD выполняет все необходимые служебные вызовы к веб-серверам, базам данных и другим службам, которые могут потребовать перезапуска или выполнения других процедур при развертывании приложений.

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

Зрелая практика DevOps CI / CD позволяет реализовать непрерывное развертывание, при котором изменения приложения проходят через конвейер CI / CD, а проходящие сборки развертываются непосредственно в производственной среде. Команды, практикующие непрерывную доставку, выбирают развертывание в производственной среде по ежедневному или даже почасовому графику, хотя непрерывная доставка не всегда оптимальна для каждого бизнес-приложения.  

Видео по теме: Как ускорить доставку кода с помощью CI / CD

Как непрерывная интеграция улучшает сотрудничество и качество

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

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

Многие команды используют флаги функций , механизм конфигурации для включения или выключения функций и кода во время выполнения. Функции, которые все еще находятся в стадии разработки, обертываются с помощью флагов функций в коде, развертываются вместе с основной веткой в ​​производственной среде и отключаются до тех пор, пока они не будут готовы к использованию. Согласно недавнему опросу, 63 процента команд, использующих флаги функций, сообщают о лучшем тестировании и более высоком качестве программного обеспечения. Инструменты пометки функций, такие как CloudBees Rollout, Optimizely Rollouts и LaunchDarkly, интегрируются с инструментами CI / CD и позволяют выполнять конфигурации на уровне функций.

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

Сам процесс сборки затем автоматизируется путем упаковки всего программного обеспечения, базы данных и других компонентов. Например, если вы разрабатываете приложение Java, CI будет упаковывать все файлы статического веб-сервера, такие как HTML, CSS и JavaScript, вместе с приложением Java и любыми сценариями базы данных.

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

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

Непрерывное тестирование выходит за рамки автоматизации тестирования

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

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

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

После того, как тестирование автоматизировано, непрерывное тестирование подразумевает, что автоматизация интегрирована в конвейер CI / CD. Некоторые модульные тесты и тесты функциональности могут быть интегрированы в CI, который выявляет проблемы до или во время процесса интеграции. Тесты, требующие полной среды доставки, такие как тестирование производительности и безопасности, часто интегрируются на компакт-диск и выполняются после доставки сборок в целевые среды.

Конвейер CD автоматизирует изменения в нескольких средах

Непрерывная доставка - это автоматизация, которая подталкивает приложения к средам доставки. У большинства групп разработчиков обычно есть одна или несколько сред разработки и тестирования, в которых изменения приложений проводятся для тестирования и проверки. Инструмент CI / CD, такой как Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo или Travis CI, используется для автоматизации шагов и предоставления отчетов.

Типичный конвейер компакт-дисков включает этапы сборки, тестирования и развертывания. Более сложные конвейеры включают в себя многие из этих шагов:

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

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

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

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

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

Реализация конвейеров CI / CD с Kubernetes и бессерверными архитектурами 

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

Существует множество подходов к совместному использованию контейнеров, инфраструктуры как кода и конвейеров CI / CD. Вы можете изучить варианты, изучив такие руководства, как Kubernetes с Jenkins или Kubernetes с Azure DevOps.

Архитектура бессерверных вычислений представляет собой еще один путь для развертывания и масштабирования приложений. В бессерверной среде инфраструктура полностью управляется поставщиком облачных услуг, и приложение потребляет ресурсы по мере необходимости в зависимости от своей конфигурации. Например, на AWS бессерверные приложения работают как функции Lambda, а развертывания могут быть интегрированы в конвейер Jenkins CI / CD с помощью подключаемого модуля. 

CI / CD позволяет чаще развертывать код

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

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

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

Влияние внедрения конвейеров CI / CD можно измерить как ключевой показатель эффективности (KPI) DevOps. KPI, такие как частота развертывания, время выполнения изменений и среднее время восстановления (MTTR) после инцидента, часто улучшаются, когда внедряется CI / CD с непрерывным тестированием. Однако CI / CD - это лишь один из процессов, который может способствовать этим улучшениям, и есть другие предпосылки для повышения частоты развертывания.

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