Ci cdl cdp devops что это
CI/CD/CD. Continuous Integration / Continuous Delivery / Continuous Deployment
Непрерывная интеграция (CI), непрерывная доставка (CD) и непрерывное развёртывание (CD) — devops-подход к разработке и апгрейду программного обеспечения, подразумевающий непрерывное, конвейерное тестирование, сборку, доставку и развёртывание обновлений. Возможно как отдельное применение компонентов этого подхода (CI или CI + CD), так и их последовательное использование в рамках единого процесса (CI + CD + CD).
Непрерывная интеграция (CI)
Непрерывная интеграция (CI) — первичный, базовый процесс обновления ПО, в рамках которого все изменения на уровне кода вносятся в единый центральный репозиторий. Такое внесение принято называть слиянием. После каждого слияния (которое проходит по несколько раз в день) в изменяемой системе происходит автоматическая сборка (часто приложение упаковывается в Docker) и тестирование (проверка конкретных модулей кода, UI, производительности, надёжности API). Таким образом разработчики страхуются от слишком поздних обнаружений проблем в обновлениях.
Непрерывная интеграция. Каждый этап запускается и выполняется автоматически
Непрерывная доставка (CD)
Непрерывная доставка (CD) — CI + CD. Следующий после CI уровень. Теперь новая версия не только создаётся и тестируется при каждом изменении кода, регистрируемом в репозитории, но и может быть оперативно запущена по одному нажатию кнопки развёртывания. Однако запуск развёртывания всё ещё происходит вручную — ту самую кнопку всё же надо кому-то нажать. Этот метод позволяет выпускать изменения небольшими партиями, которые легко изменить или устранить в случае необходимости.
Непрерывная доставка. Развёртывание выполняется автоматически, но запускается вручную
Непрерывное развёртывание (CD)
Непрерывное развёртывание (CD) — CI +CD + CD. После автоматизации релиза остаётся один ручной этап: одобрение и запуск развёртывания в продакшен (злосчастная кнопка). Практика непрерывного развёртывания упраздняет и это, не требуя непосредственного утверждения со стороны разработчика. Все изменения развёртываются автоматически.
Непрерывное развёртывание. Все этапы запускаются и выполняются автоматически
Как правило, под CI/CD подразумеваются только непрерывная интеграция и доставка.
Continuous integration vs. continuous delivery vs. continuous deployment
We will see in this article what these three practices mean and what’s required to use them.
CI and CD are two acronyms frequently used in modern development practices and DevOps. CI stands for continuous integration, a fundamental DevOps best practice where developers frequently merge code changes into a central repository where automated builds and tests run. But CD can either mean continuous delivery or continuous deployment.
What are the differences between CI, CD, and CD?
Continuous integration
Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer’s changes are validated by creating a build and running automated tests against the build. By doing so, you avoid integration challenges that can happen when waiting for release day to merge changes into the release branch.
Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.
Continuous delivery
Continuous delivery is an extension of continuous integration since it automatically deploys all code changes to a testing and/or production environment after the build stage.
This means that on top of automated testing, you have an automated release process and you can deploy your application any time by clicking a button.
In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.
Continuous deployment
Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There’s no human intervention, and only a failed test will prevent a new change to be deployed to production.
Continuous deployment is an excellent way to accelerate the feedback loop with your customers and take pressure off the team as there isn’t a Release Day anymore. Developers can focus on building software, and they see their work go live minutes after they’ve finished working on it.
How the practices relate to each other
To put it simply continuous integration is part of both continuous delivery and continuous deployment. And continuous deployment is like continuous delivery, except that releases happen automatically.
What are the benefits of each practice?
We’ve explained the difference between continuous integration, continuous delivery, and continuous deployments but we haven’t yet looked into the reasons why you would adopt them. There’s an obvious cost to implementing each practice, but it’s largely outweighed by their benefits.
CI, CD и снова CD: принцип работы и отличия
Несмотря на общие тенденции к автоматизации процессов разработки, все еще можно встретить компании, в которых тестирование и развертывание никак не автоматизировано. Отсутствие автоматизированных процессов влияет на скорость доставки изменений и увеличивает влияние человеческого фактора, что негативно отражается на всей компании в целом, а не только на самом отделе разработки.
В этой статье я постараюсь объяснить разницу между процессами непрерывной интеграции (Continuous Integration/CI), непрерывной доставки (Continuous Delivery/CD) и непрерывного развертывания (Continuous Deployment/CD). Мало кто разделяет два последних термина, но мы все-таки рассмотрим их по отдельности для общего понимания.
Continuous Integration (CI)
Процесс непрерывной интеграции (Continuous Integration) нацелен на автоматизированную проверку интеграции между изменениями разработчика и остальным кодом.
В этот процесс может входить статический анализ кода на уязвимости и несоответствие общим практикам разработки, сборка приложения и автоматизированное тестирование с динамической проверкой на уязвимости.
Автоматизация процессов CI позволяет ускорить процесс разработки, устраняя рутинные операции по ручной проверке интеграции с остальным кодом и сокращая нагрузку на отдел тестирования благодаря более раннему нахождению проблем интеграции с остальными частями приложения. Кроме того, у разработчика не выйдет сэкономить себе время, отправив изменения на тестирование без какой-либо проверки.
Continuous Delivery (CD)
Целью этого этапа является доставка измененной версии приложения в эксплуатацию.
Так, процессом доставки Docker-образов является обычная загрузка образа в реестр образов Docker и последующая его загрузка с хостовой машины. В системах с повышенными требованиями безопасности также может встречаться ситуация, в которой Docker-хосты не имеют доступа к каким-либо реестрам, и в таком случае может применяться доставка Docker-образов с применением команд docker save и docker load.
В системах без использования Docker доставка может быть реализована посредством SCM, apt/yum-репозиториев, ssh, S3-совместимого хранилища для образов VM (собранных с использованием, например, Packer) и многих других способов, область применения которых, опять же, во многом зависит от возникающих требований и удобства поддержки.
В вышеуказанном примере с Docker изменения будут доставлены вместе с новым образом через загрузку в реестр образов Docker.
Автоматизация процессов CD позволяет ускорить процесс доставки, исключить влияние человеческого фактора, а также сделать доставку более доступной для остальных членов команды.
Continuous Deployment (CD)
Процесс нацелен на развертывание новой версии приложения в окружение эксплуатации или тестирования. Обычно этот этап не выделяют как отдельный, развертывание включают в процесс доставки. Он зависит от предъявляемых к нему требований и используемых инструментов, но, как правило, вариант реализации процесса лежит на поверхности.
Инструменты CI/CD
Есть множество SaaS-решений, для обзора которых потребовалась бы отдельная статья. Остановимся на основных решениях, которые легко интегрируются в подавляющем большинстве случаев:
Подробный разбор процессов на вымышленном примере
Представим возможный процесс в вымышленной IT-компании и возможные требования, которые предъявляются от заинтересованных сторон. Возьмем небольшой IT-отдел, в котором присутствуют команды разработки, тестирования и эксплуатации. Рабочий процесс построен по Git-flow, а развертывание выполняется на Docker-хостах. Опишем основные требования каждой из сторон в формате таблицы.
Команда
Требования
Процессы CI/CD не должны отнимать много времени (отсутствие избыточных действий).
Требуется простой для понимания процессов CI/CD (описание процесса в виде кода с минимумом ручных действий).
По возможности процессы CI/CD во всех проектах должны быть похожи друг на друга (порог вхождения в новый проект).
Требуется возможность быстрого отката изменений в случае возникших проблем (устранение влияния человеческого фактора на процесс развертывания).
Тестирование должно быть по возможности автоматизировано (правка от разработчика уже как минимум не приводит к нарушению работоспособности остальных частей системы).
Должна быть возможность простого развертывания разных версий приложения для исследования регрессий (автоматизация процессов развертывания новых окружений).
Необходим простой способ развертывания окружения с несколькими сервисами для интеграционного тестирования без необходимости привлекать другие отделы (простота использования).
Требуется минимизация простоя между развертываниями приложений (развертывание без простоя и минимизация человеческого фактора при развертывании новых версий).
Необходима возможность быстро доставлять новую функциональность пользователям для тестирования гипотез (автоматизация процессов и отсутствие избыточных действий).
После сбора требований мы можем сформировать примерный вид процессов CI/CD в команде:
Разбор по части CI
Процесс интеграции не обязательно должен быть общим во всех случаях, намного удобнее описать различные сценарии для каждой ситуации. Давайте опишем возможные ситуации в качестве примера:
Почему нельзя построить общий процесс CI? В этом просто нет смысла – если выполнять сборку образа для интеграционного тестирования после ручного подтверждения для релизной ветки, то неминуемо случится ситуация, в которой про необходимость ручного запуска сборки просто забудут, и отдел тестирования будет проверять неактуальную версию приложения. Проводить проверку соответствия стандартам кодирования и юнит/функциональное тестирование на версии, помеченной тегом, – пустая трата времени, ведь все изменения уже есть в релизной ветке.
Чем больше будет автоматизированных задач, тем больше бессмысленной работы будет выполнено в общем процессе.
Разбор по части CD (Delivery)
В нашем случае доставкой является загрузка Docker-образа с приложением в Registry, из которого образы будут загружены на конкретный Docker-хост в процессе развертывания. Реестр может быть как общим, так и отдельным – для окружения разработки и тестирования и окружения эксплуатации. Тут все зависит от требований безопасности в конкретной компании.
Разбор по части CD (Deployment)
В нашем случае деплой в окружение эксплуатации может выполняться путем перенаправления всех новых HTTP-запросов на новый экземпляр приложения (основываясь на том, что максимальное время запроса ограничено сверху разумным лимитом для обеспечения развертывания без простоя).
Небольшим проектам или проектам без необходимости создания собственной инфраструктуры стоит обратить внимание на облачные хостинги, которые позволяют автоматизировать разработку проекта, налаживая процессы CI/CD.
Выводы
Надеюсь, теперь вы точно разобрались в отличиях CI и CD, а также поняли всю важность автоматизации данных процессов.
Подведем итог по всему вышесказанному – внедрение CI/CD само по себе является непрерывным процессом и постоянно видоизменяется в зависимости от новых требований отдельно взятой компании. В то же время процессы CI/CD требуют дополнительных инструментов и времени на внедрение, которое можно сократить, используя уже готовые сервисы для их автоматизации.
Поэтому вывод о необходимости автоматизации того или иного процесса каждый должен сделать для себя сам. Я считаю, что автоматизация рассмотренных процессов должна присутствовать в каждой компании, которая связана с разработкой.
Что такое CI/CD? Разбираемся с непрерывной интеграцией и непрерывной поставкой
В преддверии старта курса «CI/CD на AWS, Azure и Gitlab» подготовили для вас перевод полезного материала.
Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения программного обеспечения.
CI/CD — это одна из DevOps-практик. Она также относится и к agile-практикам: автоматизация развертывания позволяет разработчикам сосредоточиться на реализации бизнес-требований, на качестве кода и безопасности.
Определение CI/CD
Непрерывная интеграция — это методология разработки и набор практик, при которых в код вносятся небольшие изменения с частыми коммитами. И поскольку большинство современных приложений разрабатываются с использованием различных платформ и инструментов, то появляется необходимость в механизме интеграции и тестировании вносимых изменений.
С технической точки зрения, цель CI — обеспечить последовательный и автоматизированный способ сборки, упаковки и тестирования приложений. При налаженном процессе непрерывной интеграции разработчики с большей вероятностью будут делать частые коммиты, что, в свою очередь, будет способствовать улучшению коммуникации и повышению качества программного обеспечения.
Непрерывная поставка начинается там, где заканчивается непрерывная интеграция. Она автоматизирует развертывание приложений в различные окружения: большинство разработчиков работают как с продакшн-окружением, так и со средами разработки и тестирования.
Инструменты CI/CD помогают настраивать специфические параметры окружения, которые конфигурируются при развертывании. А также CI/CD-автоматизация выполняет необходимые запросы к веб-серверам, базам данных и другим сервисам, которые могут нуждаться в перезапуске или выполнении каких-то дополнительных действий при развертывании приложения.
Непрерывная интеграция и непрерывная поставка нуждаются в непрерывном тестировании, поскольку конечная цель — разработка качественных приложений. Непрерывное тестирование часто реализуется в виде набора различных автоматизированных тестов (регрессионных, производительности и других), которые выполняются в CI/CD-конвейере.
Зрелая практика CI/CD позволяет реализовать непрерывное развертывание: при успешном прохождении кода через CI/CD-конвейер, сборки автоматически развертываются в продакшн-окружении. Команды, практикующие непрерывную поставку, могут позволить себе ежедневное или даже ежечасное развертывание. Хотя здесь стоит отметить, что непрерывная поставка подходит не для всех бизнес-приложений.
Непрерывная интеграция улучшает коммуникации и качество
Непрерывная интеграция — это методология разработки, основанная на регламентированных процессах и автоматизации. При внедренной непрерывной интеграции разработчики часто коммитят свой код в репозиторий исходного кода. И большинство команд придерживается правила коммитить как минимум один раз в день. При небольших изменениях проще выявлять дефекты и различные проблемы, чем при больших изменениях, над которыми работали в течение длительного периода времени. Кроме того, работа с короткими циклами коммитов уменьшает вероятность изменения одной и той же части кода несколькими разработчиками, что может привести к конфликтам при слиянии.
Команды, внедряющие непрерывную интеграцию, часто начинают с настройки системы контроля версий и определения порядка работы. Несмотря на то что коммиты делаются часто, реализация фич и исправление багов могут выполняться довольно долго. Для контроля того, какие фичи и код готовы существует несколько подходов.
Многие используют фича-флаги (feature flag) — механизм для включения и выключения функционала в рантайме. Функционал, который еще находится в стадии разработки, оборачивается фича-флагами и развертывается из master-ветки в продакшн, но отключается до тех пор, пока не будет полностью готов к использованию. По данным недавнего исследования 63 процента команд, использующих фича-флаги, говорят об улучшении тестируемости и повышении качества программного обеспечения. Для работы с фича-флагами есть специальные инструменты, такие как CloudBees Rollout, Optimizely Rollouts и LaunchDarkly, которые интегрируются в CI/CD и позволяют выполнять конфигурацию на уровне фич.
Другой способ работы с фичами — использование веток в системе контроля версий. В этом случае надо определить модель ветвления (например, такую как Gitflow) и описать как код попадает в ветки разработки, тестирования и продакшена. Для фич с длительным циклом разработки создаются отдельные фича-ветки. После завершения работы над фичей разработчики сливают изменения из фича-ветки в основную ветку разработки. Такой подход работает хорошо, но может быть неудобен, если одновременно разрабатывается много фич.
Этап сборки заключается в автоматизации упаковки необходимого программного обеспечения, базы данных и других компонент. Например, если вы разрабатываете Java-приложение, то CI упакует все статические файлы, такие как HTML, CSS и JavaScript, вместе с Java-приложением и скриптами базы данных.
CI не только упакует все компоненты программного обеспечения и базы данных, но также автоматически выполнит модульные тесты и другие виды тестирования. Такое тестирование позволяет разработчикам получить обратную связь о том, что сделанные изменения ничего не сломали.
Большинство CI/CD-инструментов позволяет запускать сборку вручную, по коммиту или по расписанию. Командам необходимо обсудить расписание сборки, которое подходит для них в зависимости от численности команды, ожидаемого количества ежедневных коммитов и других критериев. Важно, чтобы коммиты и сборка были быстрыми, иначе долгая сборка может стать препятствием для разработчиков, пытающихся быстро и часто коммитить.
Непрерывное тестирование — это больше, чем автоматизация тестирования
Фреймворки для автоматизированного тестирования помогают QA-инженерам разрабатывать, запускать и автоматизировать различные виды тестов, которые помогают разработчикам отслеживать успешность сборки. Тестирование включает в себя функциональные тесты, разрабатываемые в конце каждого спринта и объединяемые в регрессионные тесты для всего приложения. Регрессионные тесты информируют команду: не сломали ли их изменения что-то в другой части приложения.
Лучшая практика заключается в том, чтобы требовать от разработчиков запускать все или часть регрессионных тестов в своих локальных окружениях. Это гарантирует, что разработчики будут коммитить уже проверенный код.
Регрессионные тесты — это только начало. Тестирование производительности, тестирование API, статический анализ кода, тестирование безопасности — эти и другие виды тестирования тоже можно автоматизировать. Ключевым моментом является возможность запуска этих тестов из командной строки, через веб-хук (webhook) или через веб-сервис и возврат результата выполнения: успешный был тест или нет.
Непрерывное тестирование подразумевает не только автоматизацию, но и интеграцию автоматического тестирования в конвейер CI/CD. Модульные и функциональные тесты могут быть частью CI и выявлять проблемы до или во время запуска CI-конвейера. Тесты, требующие развертывания полного окружения, такие как тестирование производительности и безопасности, часто являются частью CD и выполняются после разворачивания сборок в целевых средах.
CD-конвейер автоматизирует поставку изменений в различные окружения
Непрерывная поставка — это автоматическое развертывание приложения в целевое окружение. Обычно разработчики работают с одним или несколькими окружениями разработки и тестирования, в которых приложение развертывается для тестирования и ревью. Для этого используются такие CI/CD-инструменты как Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo, Travis CI.
Типичный CD-конвейер состоит из этапов сборки, тестирования и развертывания. Более сложные конвейеры включают в себя следующие этапы:
В более сложном CD-конвейере могут быть дополнительные этапы, такие как синхронизация данных, архивирование информационных ресурсов, установка обновлений и патчей. CI/CD-инструменты обычно поддерживают плагины. Например, у Jenkins есть более 1500 плагинов для интеграции со сторонними платформами, для расширения пользовательского интерфейса, администрирования, управления исходным кодом и сборкой.
При использовании CI/CD-инструмента разработчики должны убедиться, что все параметры сконфигурированы вне приложения через переменные окружения. CI/CD-инструменты позволяют устанавливать значения этих переменных, маскировать пароли и ключи учетных записей, а также настраивать их во время развертывания для конкретного окружения.
Также в CD-инструментах присутствуют дашборды и отчетность. В случае сбоя сборки или поставки они оповещают об этом. При интеграции CD с системой контроля версий и agile-инструментами облегчается поиск изменений кода и пользовательских историй, вошедших в сборку.
Реализация CI/CD-конвейеров с Kubernetes и бессерверными архитектурами
Многие команды, использующие CI/CD-конвейеры в облаках используют контейнеры, такие как Docker, и системы оркестрации, такие как Kubernetes. Контейнеры позволяют стандартизировать упаковку, поставку и упростить масштабирование и уничтожение окружений с непостоянной нагрузкой.
Есть множество вариантов совместного использования контейнеров, инфраструктуры как код и CI/CD-конвейеров. Подробнее изучить это вы можете в статьях Kubernetes with Jenkins и Kubernetes with Azure DevOps.
Архитектура бессерверных вычислений представляет собой еще один способ развертывания и масштабирования приложений. В бессерверном окружении инфраструктурой полностью управляет поставщик облачных услуг, а приложение потребляет ресурсы по мере необходимости в соответствии с его настройками. Например, в AWS бессерверные приложения запускаются через функции AWS Lambda, развертывание которых может быть интегрировано в CI/CD-конвейер Jenkins с помощью плагина.
CI/CD обеспечивает более частое развертывание кода
Итак, подведем итоги. CI упаковывает, тестирует сборки и оповещает разработчиков, если что-то пошло не так. CD автоматически разворачивает приложения и выполняет дополнительные тесты.
CI/CD-конвейеры предназначены для организаций, которым необходимо часто вносить изменения в приложения с надежным процессом поставки. Помимо стандартизации сборки, разработки тестов и автоматизации развертываний мы получаем целостный производственный процесс по развертыванию изменений кода. Внедрение CI/CD позволяет разработчикам сосредоточиться на улучшении приложений и не тратить силы на его развертывание.
CI/CD является одной из DevOps-практик, поскольку направлена на борьбу с противоречиями между разработчиками, которые хотят часто вносить изменения, и эксплуатацией, требующей стабильности. Благодаря автоматизации, разработчики могут вносить изменения чаще, а команды эксплуатации, в свою очередь, получают большую стабильность, поскольку конфигурация окружений стандартизирована и в процессе поставки осуществляется непрерывное тестирование. Также настройка переменных окружения отделена от приложения и присутствуют автоматизированные процедуры отката.
Эффект от внедрения CI/CD-конвейеров можно измерить в виде ключевых показателей эффективности (KPI) DevOps. Такие KPI как частота поставки (deployment frequency), время реализации изменений (change lead time) и среднее время восстановления после инцидента (mean time to recovery) часто улучшаются при внедрении CI/CD с непрерывным тестированием. Однако CI/CD — это лишь один из процессов, который может способствовать этим улучшениям. Есть и другие условия для увеличения частоты поставки.
Для начала работы с CI/CD команде разработчиков и эксплуатации необходимо совместно определиться с технологиями, практиками и приоритетами. Команды должны выработать консенсус в отношении правильных подходов к своему бизнесу и технологиям, чтобы после внедрения CI/CD команда постоянно придерживалась выбранных практик.