Cdl cdp что это

Разница между Continuous Delivery и Continuous Deployment

Continuous Integration (CI) — непрерывная интеграция, это практика разработки программного обеспечения, при которой члены команды часто интегрируют свою работу. Интеграция это слияние новой версии кода со стабильной и проверка, что при этом ничего не сломалось. Следуя этой практике, обычно, каждый сотрудник интегрирует изменения по крайней мере ежедневно, что приводит к нескольким интеграциям в день. Каждая интеграция проверяется автоматизированной сборкой (включая тестирование), чтобы как можно быстрее обнаружить ошибки интеграции. Многие команды пришли к выводу, что такой подход приводит к значительному сокращению проблем интеграции и позволяет команде быстрее разрабатывать целостное программное обеспечение. Подробнее можно почитать у Мартина Фаулера. В современном IT многие знакомы с CI, но мало кто знает, что скрывается за аббревиатурой CD.

Собеседуя Ops’ов в OneTwoTrip, среди прочего я спрашивал что такое CI, а потом что такое CD. Не смотря на то, что зачастую люди могли дать какой-либо вразумительный ответ, почти никто не мог рассказать разницу между Continuous Delivery и Continuous Deployment. Я и сам постоянно забываю правильный ответ, поэтому решил написать эту заметку. Для кого-то это может быть критично, например если на собеседовании вам попадется такой же поехавший как я.

Разница между Continuous Delivery и Continuous Deployment очень маленькая. Представим два пайплайна для одного и того же приложения. В каждом есть шаги:

Source Control — внесение изменений в систему контроля версий ПО
Build — сборка приложения и прогон unit тестов
Staging — деплой на тестовое окружение, прогон интеграционных, нагрузочных и других тестов
Production — деплой на окружение с пользователями

Каждый пайплайн запускается автоматически по триггеру из системы контроля версий. В случае Continuous Deployment каждый следующий шаг, будет выполнен автоматически если предыдущий был успешный, включая деплой на Production.

Если же у вас Continuous Delivery, то шаги будут выполняться автоматически только в безопасной среде, а перед деплоем на Production пайплайн остановится и будет ждать ручного подтверждения. Механизм, как это будет реализовано может быть разным. От самого простого, когда ответственный человек должен зайти в пайплайн и нажать кнопку Next, до интерактивного бота с кнопками в корпоративном мессенджере.

Зачем нужен ручной апрув перед деплоем на Production, ведь это тормозит пайплайн т.е. доставку фич и исправлений багов? Вопрос резонный, но ответ такой же. Не все проекты одинаковые, есть такие в которых решение о деплое на Production должно быть принято человеком ответственно и осознанно. Когда бизнес сложный, с большим количеством факторов и нельзя переложить выбор “деплоить или нет” на пару алгоритмических критериев, тогда и применяется Continuous Delivery, а не Continuous Deployment.

Для простоты я сделал специальную диаграмму, она доступна по короткой ссылке doam.ru/cdvscd.

#DevOps #CI/CD

Поблагодарить автора
Telegram канал

Cdl cdp что это

DevOps = красивое название для ПРОЦЕССОВ активного взаимодействия разработчиков с администраторами (БД и систем) и автоматизаторами тестирования , которые (процессы) максимально стандартизированы с помощью договорённостей в командах и обеспеченностью сред для разработки и автоматизированы за счёт использования специальных инструментов поставки, прогона тестов, развёртывания.

ускорения и упрощения оргпроцедур по получению техники для разработчика с уже установленной или быстро устанавливаемой/обновляемой IDE и другого необходимого инструментария, а также по получению необходимых сетевых доступов с рабочих станций.
упрощения и ускорения процедур по выделению и масштабированию мощностей для стендов, необходимых для развёртывания ПО и его тестирования
, обычно за счёт использования облачных решений (Amazon AWS, Google Cloud, Microsoft Azure, SberCloud, Yandex.Cloud)
использования средств автоматизации операций для всего процесса поставки (Jenkins, TeamCity, рукописные скрипты)
использования средств виртуализации и контейнеризации (Docker, Kubernetes)
внедрения практики CI/CD/CDP и неизбежно с ней связанной автоматизацией тестов (unit, API, web-API, regress)
внедрения решений по мониторингу как целых стендов, так и отдельных хостов, ВМ, веб-сервисов и приложений
перехода на микросервисную архитектуру и service mesh с автотестированием контрактов многочисленных API (особенно если используется модный сейчас gRPC, например-например)

N.B. В повседневности словом devops чаще обозначают РОЛЬ администратора, который сопровождает стенды разработки и тестирования, управлением всеми этими средствами автоматизации поставки CI/CD/CDP (см. ниже).

Суть CI/CD/CDP

CI, CD(L), CDP

чекина изменений в репозиторий;
статического анализа кода: на уязвимости, на соответствие требованиям и стандартам;
компиляции и формирования билда (сборки);
передачи обратной связи об успехе/неудаче билда в виде уведомлений по выбранным каналам;
деплоев на dev / test / staging / prod;
всех необходимых тестов (unit, smoke, acceptance, regression, integration, end-to-end);
заведения issue в СУП в случае ошибок;
слияния изменений с нужной веткой в случае «зелёных» тестов.

VM и Docker

Основы Docker. Большой практический выпуск (Артем Матяшов , 2020). Отлично разъясняет суть Docker, демонстрирует практические примеры.
Основы Kubernetes

Суть

Контейнер = набор процессов, изолированный от остальной ОС, и запускаемый с отдельного образа, который содержит все файлы, необходимые для их работы (runtime & supporting files). Образ содержит все зависимости приложения и поэтому может легко переноситься из среды разработки в среду тестирования, а затем в промышленную среду.

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

Разница между Виртуальной машиной и Контейнером

Примеры решений контейнеризации

Облачные решения:
- Amazon AWS ECS
- Azure Container Service (ACS)
- Docker
- Kubernetes
- Docker Engine API
- Kubernetes
- Azure Service Fabric
Поясняющая схемка OS, Istio, k8s

Поясняющая схемка некоторых сущностей Openshift, Istio, k8s для себя.
Доразобраться с Route и Gateway.

Аутентификация к API OS через curl
1. Делаем запрос на получение OAuth token, используя, например, basic-аутентификацию OS User’ом curl -X GET «https://master-address:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token» -H «Content-Type: application/json» -H «X-CSRF-Token: XXX» -u [username] -ikL
2. Из ответа из header’а < Location: https://10.64.33.43:8443/oauth/token/implicit#access_token=TOKENSCHMOKEN&expires_in=86400&scope=user%3Afull&token_type=Bearer берём значение TOKENSCHMOKEN (можно сразу grep'ать вместе с запросом выше), это и будет наш Bearer-токен для последующих запросов к API OS.
3. Выполняем нужный нам запрос, например почитать yaml какого-то Deployment’а curl -X GET «https://api.master-address:8443/apis/apps/v1/namespaces/[namespace]/deployments/[deployment]» -H «Content-Type: application/json» -H «Authorization: Bearer TOKENSCHMOKEN» -ik , и в ответе получаем искомый yaml.
- GitHub Gist — tuxfight3r’s curl notes — openshift rest api login / json patch via curl
- OpenShift documentation — Architecture — Additional Concepts — Authentication
- OpenShift documentation — AIP reference — apps — Deployment
Контракты API

API = application programming interface = опубликованный программный интерфейс компонента/системы, позволяющий другим компонентам/системам получать доступ к какой-либо функции.
- Функциональная (сигнатура и семантика):
  1. Название API
  2. Входные данные / параметры вызова (протокол, URI)
  3. Возвращаемые данные
  4. Семантика (описание функциональности)
  5. Шаблон интеграционного взаимодействия
  6. Потребитель
- Нефункциональная ( SLA ):
  1. Доступность (availability, %)
  2. Время ответа (latency, ms) = время, необходимое приложению, чтобы ответить на запрос
  3. Пропускная способность (throughput, transactions per second, tps) = количество транзакций (запросов), которое приложение может обработать в течение секунды
  4. Какие-либо ограничения (по размеру сообщения, безопасности и т.п.)
Обычно контракты API ведут как в Confluence, так и в специальных системах — реестр API.

CDC (Consumer Driven Contract)

CDC (Consumer Driven Contract) = контракт потребителя сервиса.
Представляет из себя соглашение между сервисом-поставщиком и сервисом-потребителем в том, что
сервис-поставщик обязуется уметь принимать на вход от сервиса-потребителя определённую структуру данных определённых типов, сериализованную JSON/XML/binary/.
и гарантирует возвращать в ответ определённую структуру данных определённых типов, также сериализованную.

CDC фокусируется на поведении и данных, которые важны Потребителю, т.е. требования исходят от Потребителя: мне нужно вот это.
- OpenAPI для Swagger
- WSDL для SOAP
- WADL для REST HTTP сервисов
- Protocol Buffers для gRPC
Этот подход когда-то реализован в виде WSDL/WADL-сервисов
, развивался для REST HTTP в виде, например, OpenAPI с его .yaml-файлами контрактов ( Contract-First API Development with OpenAPI Generator and Connexion)
, а сейчас его популярность сильно возросла в связи с активным продвижением gRPC и его .proto-файлами контрактов (статьи GRPC сервис на примере генератора паролей и gRPC — фреймворк от Google для удалённого вызова процедур)
- Пирамида тестов на практике # Контрактные тесты
- Consumer Driven Contracts глазами разработчика
- Consumer Driven Contracts — HTTP-REST контрактные тесты на Java & Spring & Gradle/Maven
Оценка задач

Метод трёх точек (3-point estimation)

Метод для расчёта временных затрат в проектах с уникальными задачами в условиях неопределённости и при наличии нескольких типов рисков. Используется в IT достаточно широко.
Для того, чтобы начать применять этот метод, нужно проанализировать предмет доработки и описание реализации. Попытаться провести аналогии с ранее выполненными задачами с похожим скоупом. Определить риски и описать мероприятия по устранению этих рисков (что делаем, если сработал тот или иной риск).

WM = (O + 4*BG + P) / 6
О (opitimistic) — оптимистичное время выполнения задачи, если все пойдет хорошо, т.е. если не наступит ни один из выявленных и зафиксированных рисков.
BG (best guess) — наиболее вероятное время, или средняя продолжительность выполнения аналогичной задачи, при условии выполняли её уже много раз.
Р (pessimistic) — пессимистичное время выполнения задачи, если сработали все выявленные риски.
WM (weighted mean) — взвешенное значение с учетом рисков и последствий воздействия негативных и позитивных факторов.
SD (standard deviation) — стандартное отклонение, используемое для расчета вероятностей.

Как видим, суть метода сводится к тому, что мы предполагаем, что с вероятностью 4/6 всё пойдёт так, как было и ранее в подобных случаях, с учётом менее вероятных (по 1/6) отклонений в стороны «всё будет плохо» и «всё пройдёт идеально».
- Точности (используется 3 оценки вместо одной)
- Повышения ответственности членов команды за оценку, поскольку они должны учитывать риски
- Получить описание рисков в каждой задаче
Метод «Объём неясен, дам заведомо большую оценку, поторгуемся»

Суть в том, что по некоторым задачам ты вроде бы не знаешь даже примерно сколько она займёт трудозатрат, но готов назвать запредельно большую оценку (чувствуешь в ней внутреннюю уверенность, хоть и боязно произнести), за которую вы уж точно сделаете, но которая точно не понравится вопрошающему (заказчику работ).
Что это даёт — это выкладывает на стол переговоров повод для торга «ты мне уточнение входных данных, я тебе уточнение оценки».
Например, «Слушай, я не знаю во сколько её оценить, давай на все непонятные CR напишем по 500 часов, потом поторгуемся с возмущённым Клиентом, пусть разъяснит».

Кастомный метод для T-Shape оценки «размера» задачи

Связан с методологией Kanban.
Набросокъ:
- Интерфейсы (интеграция с новыми Системами)
- данные (в БД, файлах)
- формы GUI
- интерфейсы (интеграция с другими Системами)
- периодические задания (SSIS-пакеты, job’ы, cron’ы)
- вспомогательные (плагины, хранимые процедуры SQL)
- сообытийные процедуры для форм GUI
- те или иные отчёты
- подсистема управления правами
- предполагаются изменения в БП = Регистрация Клиента (S)
- но потребность в вовлечении заказчика = средняя (M)
- и объект доработки = форма GUI, событийные процедуры для форм GUI, данные (M)
Что делаем: оцениваем задачи таким образом, некоторое время накапливаем статистику по времени выполнения оценённых таким образом задач, а далее при планировании мы уже на этапе такой оценки будем знать, что задача L скорее всего будет выполняться за X дней и т.п.

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

Во фронт или в бэк?
- проверка что в форму для числа введено число, а не срока — это чистый фронт;
- проверка по КЛАДР -однозначный бэк;
Уровень квалификации

Junior — тот, кого нельзя оставить без присмотра. Задачу надо разжевать, код придирчиво отревьюить, время от времени узнавать, как дела и поправлять на ходу. Выхлопа от работы джуна ожидать не стоит (т.е. времени он не сэкономит, скорее потратит), но на него можно сгрузить рутину и через некоторое время он подтянется и выхлоп будет.

Middle — работает работу сам. В задачах тоже разбирается сам, где не может, сам задаёт релевантные вопросы. Кроме ревью кода пригляда за ним не требуется, но и помощи в определении курса тоже не ожидается.

Senior — автономная боевая единица. Если в него кинуть размытой формулировкой проекта, то он её сам уточнит, ещё и укажет на слабые места и покритикует, подберёт рабочий стек технологий (без оглядки на хайп) и сам в одиночку всё запрограммирует (и за джунами присмотрит). Ещё и заказчика пнёт (возможно, через прокладку-менеджера, если таковая зачем-то есть), что тот ему ещё вчера обещал уточнения к ТЗ прислать.

CI/CD/CD. Continuous Integration / Continuous Delivery / Continuous Deployment

Непрерывная интеграция (CI), непрерывная доставка (CD) и непрерывное развёртывание (CD) — DevOps-подход к разработке и апгрейду ПО, подразумевающий непрерывное конвейерное тестирование, сборку, доставку и развёртывание обновлений. Возможно как отдельное применение компонентов этого подхода (CI или CI + CD), так и их последовательное использование в рамках единого процесса (CI + CD + CD).

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

CI — это метод разработки программного обеспечения, при котором изменения кода постоянно интегрируются в репозиторий. Далее интеграция автоматически собирается и тестируется, что помогает обнаружить и устранить конфликты и ошибки. CI улучшает качество и стабильность ПО и позволяет ускорить цикл выпуска. CI обычно реализуется с помощью инструмента CI/CD (Continuous Integration/Continuous Deployment), который автоматизирует процесс сборки, тестирования и развертывания. Автоматизируя эти задачи, CI/CD помогает сократить количество ошибок, допускаемых вручную и повысить эффективность, позволяя командам сосредоточиться на разработке новых функций и улучшений.

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

Непрерывная доставка (CD) — CI + CD. Следующий после CI уровень. Теперь новая версия не только создаётся и тестируется при каждом изменении кода, регистрируемом в репозитории, но и может быть оперативно запущена по одному нажатию кнопки развёртывания. Однако запуск развёртывания всё ещё происходит вручную ту самую кнопку всё же надо кому-то нажать. Этот метод позволяет выпускать изменения небольшими партиями, которые легко изменить или устранить в случае необходимости.

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

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

Что такое CI/CD?

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

Всё о CI/CD

CI/CD является собирательным термином, охватывающим несколько этапов DevOps. CI (непрерывная интеграция) — это способ интеграции изменений кода в репозиторий по несколько раз в день. У CD есть два значения: непрерывная доставка автоматизирует интеграцию в то время, как непрерывное развертывание автоматически выпускает финальную сборку для конечных пользователей. Регулярное тестирование в рамках CI/CD уменьшает количество ошибок и дефектов кода, что делает эту методику незаменимой для рабочего процесса DevOps.
- Непрерывная интеграция (CI)
- Непрерывная интеграция (CI)
- Непрерывная интеграция (CI)
- Непрерывная доставка
- Чем отличаются DevOps и CI/CD?
Непрерывная интеграция (CI)

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

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

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

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

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

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

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

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

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

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

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

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

Чем отличаются DevOps и CI/CD?

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

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

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