7.04. DevOps, CI-CD

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО

Разработчику Архитектору Инженеру

Основы

Часто можно запутаться в этих понятиях вроде «прод», «тест» и тому подобное. Смысл прост - нельзя размещать тестовые или непроверенные вариации приложения на рабочей среде, поэтому нужна «копия» рабочей среды для проверок и экспериментов. Поэтому разворачивается целая инфраструктура вроде такой:

Здесь мы видим следующий порядок:

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

Смысл продакшен среды в том, чтобы установить туда рабочую программу и «не трогать, пока работает». Доступ туда даётся лишь ограниченный, как для обычных пользователей. К примеру, открыв любой сайт, маркетплейс, или даже игру, вы как пользователь получаете доступ именно к проду, поэтому да, всё вокруг нас - продакшен. И представьте, вы подаёте заявку на кредит на сайте, и прямо в середине процесса у вас резко меняется цвет интерфейса, а введённые вами данные очистились. Неприятно? Не то слово.

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

В классическом понимании развёртывание на продакшене представляет собой остановку работы приложения, замену файлов кода и всех ресурсов, конфигурация и запуск новой версии. Но представьте, если работа онлайн-банка или маркетплейса по всему миру…остановится, для установки обновления? Это же смертельно для бизнеса!

Поэтому существует автоматический процесс поставки с теста на прод.

Здесь всё искусство администраторов и DevOps-инженеров как раз в том, чтобы аккуратно обновить продакшен без вреда бизнесу. Современные технологии и инструменты позволяют производить такую «поставку» автоматически, что и привело к появлению термина CI/CD.

DevOps, CI/CD – что это?

И так, мы спроектировали решение, определились с архитектурой и даже разработали его. Что дальше? Нужно установить и реализовать. Тут вступает в силу развёртывание, или деплой.

Развёртывание – процесс установки и запуска программного обеспечения на целевой среде (например, сервер). Оно бывает ручным и автоматическим. И если ручное – это классическая установка всех компонентов, зависимостей и программ, то автоматическое – более интересный и сложный процесс, который требует особой квалификации – DevOps.

DevOps (от Development + Operations) – культура, методология и набор практик, которые направлены на автоматизацию и ускорение процессов разработки и развертывания программного обеспечения путем улучшения взаимодействия между разработчиками (Dev) и ИТ-операциями (Ops).

Разработка (Dev) и эксплуатация (Ops) за счет автоматизации, CI/CD и коллаборации

Важно: это не сисадмины, не релиз-мастера, и не конкретный инструмент. Это подход, который затрагивает и меняет весь цикл разработки ПО – от написания кода до его работы в продакшене.

Цель – ускорить выпуск продукта без потери качества. Если привести аналогию – то это использование на производстве автоматического конвейера вместо использования ручного труда. Цели те же, эффект аналогичный, главное не просто запустить проект, «чтобы работало», а сделать этот запуск быстрым, безопасным, надёжным.

Принципы:

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

Возможно, многие сталкивались с традиционной для любой ячейки общества системы «перекладывания ответственности», появившейся из «разделения ответственности». Допустим, разработчик сделал четко, что требуется, закинул код, передал админам, а на любые замечания говорит: «Мне без разницы, вот, смотрите, у меня всё работает». Админы пытаются, настраивают всё вручную, но не получается – то ошибка в тоннах конфигураций серверов, то нет нужных зависимостей, то нагрузка намного выше, чем на тестовом стенде. Итог – бесконечное перекладывание вины, медленные релизы, падение продакшена и конечно же «выдёргивание» разработчика для решения проблемы.

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

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

Как код будет работать в продакшене?
Как код будет масштабироваться?
Как быстро откатить, если что-то сломается?

Администраторы (их ещё называют «операторами», это как раз часть «Ops») участвуют в планировании, взаимодействуют с командой и знают, как устроено приложение.

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

Всё это, в совокупности обеспечивает то, что команда перестаёт бояться изменений, а развертывание продукта становится гибким и плавным.

В DevOps есть такие понятия, как CI/CD, петля обратной связи и пайплайн.

Пайплайн (pipeline) – автоматизированный конвейер, который берёт код, проводит через необходимые этапы и доставляет в продакшен:

Синхронизация кода с Git → Сборка → Автотесты → Деплой на тестовый или продакшен стенд → Ручное тестирование → Деплой на продакшен

CI/CD (Continuous Integration / Continuous Delivery) состоит из двух принципов.

Непрерывная интеграция (Continuous Integration) – постоянный учёт изменений и грамотное использование систем контроля версий, частое слияние кода в соответствующих ветках Git, и при каждом коммите – запуск автоматической сборки и тестов. Это сразу выявляет ошибки, которые проще починить до того, как наступят последствия.
Непрерывная доставка (Continuous Delivery) – автоматическое развёртывание сборки на соответствующем стенде. Часто используется ручное подтверждение релиза – и оно в любом случае представляет собой «клик», а не кропотливую настройку зависимостей и конфигураций.

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

1.1. Как работает CI

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

Технически процесс CI запускается триггером — чаще всего это push в определённую ветку репозитория (например, в main, develop или feature-ветку). Система CI (например, Jenkins, GitLab CI, GitHub Actions, Azure DevOps) перехватывает этот триггер, клонирует репозиторий, устанавливает необходимые зависимости, компилирует код (если требуется), и последовательно выполняет:

Сборку (build): преобразование исходного кода в исполняемый артефакт;
Статический анализ кода: проверка соответствия кода стандартам, поиск потенциальных уязвимостей или антишаблонов;
Запуск автоматизированных тестов: unit-, интеграционные, иногда end-to-end тесты;
Формирование отчётов: о покрытии кода тестами, времени выполнения, количестве найденных ошибок.

Если все этапы завершены успешно, интеграция считается пройденной. В противном случае — система CI сигнализирует о сбое и часто блокирует дальнейшее продвижение изменений (например, не позволяет смёрджить pull request).

1.2. Как организовать CI

Организация CI требует как инфраструктурных, так и процессных решений:

Централизованный репозиторий исходного кода с чёткой политикой ветвления;
Система CI, способная выполнять сборку и тестирование в изолированной среде;
Единая система зависимостей и воспроизводимая сборка (с помощью lock-файлов, Dockerfile, Makefile и т.п.);
Минимальный набор автоматизированных тестов, покрывающих критические участки логики;
Культура частых и небольших коммитов — чтобы уменьшить риск конфликтов и упростить отладку неудачных сборок.

Важно понимать, что CI — это не просто «скрипт, который запускается после коммита». Это дисциплина, в рамках которой каждый коммит рассматривается как кандидат на доставку в production, и, следовательно, должен проходить строгую проверку.

2. Непрерывная доставка и непрерывное развёртывание (Continuous Delivery / Continuous Deployment)

2.1. Как работает CD

Непрерывная доставка (Continuous Delivery) — это расширение практики CI, при котором система не только проверяет изменения, но и подготавливает их к развёртыванию в рабочую среду. Иными словами, после прохождения CI каждый успешный билд становится готовым к развёртыванию в production — в любой момент и с минимальными усилиями.

Непрерывное развёртывание (Continuous Deployment) — это дальнейшее развитие идеи: каждое изменение, успешно прошедшее CI и все необходимые проверки, автоматически развёртывается в production, без вмешательства человека.

Таким образом, отличие между Delivery и Deployment заключается в наличии или отсутствии ручного подтверждения перед попаданием в production. Continuous Delivery предполагает, что развёртывание может быть выполнено вручную по решению команды; Continuous Deployment делает это решение автоматическим.

Процесс CD включает:

Создание артефакта (например, Docker-образа, JAR-файла, ZIP-архива), идентифицируемого по хешу коммита;
Тестирование на staging-среде (предпродакшене), максимально приближённой к production;
Управление конфигурациями и переменными окружения отдельно от кода;
Плавное развёртывание (blue-green, canary, rolling update) для минимизации простоя и рисков;
Механизмы мониторинга и автоматического отката при обнаружении сбоев.

2.2. Как организовать CD

Для организации CD требуется более зрелая инфраструктура и культура, чем для CI:

Единый артефакт, проходящий все стадии без пересборки;
Идемпотентные скрипты развёртывания, не зависящие от состояния целевой системы;
Среды, идентичные друг другу по конфигурации (с возможным различием только в данных);
Автоматизированные проверки качества развёртывания: smoke-тесты, health-check, метрики доступности;
Политики безопасности: управление секретами, ограничение прав на развёртывание, аудит изменений.

Ключевое правило CD: если что-то нельзя автоматизировать — это узкое место, которое необходимо устранить. CD требует доверия к автоматике, а доверие строится на стабильности и прозрачности.

3. Среды разработки и эксплуатации: локальная, тестовая, предпродакшен, продуктив

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

3.1. Локальная разработка

Каждый разработчик работает на собственной машине, используя локально установленные инструменты или контейнеры. Цель — написать и протестировать небольшой функционал в условиях, приближённых к реальным. Однако локальная среда по определению неполна: она не включает зависимости, характерные для распределённой системы (например, очереди сообщений, внешние API, балансировщики).

3.2. Тестовая среда (test/staging)

Тестовая среда — это первый интеграционный уровень, где проверяется взаимодействие компонентов системы. Она может быть частично или полностью клонированной из production и используется для:

Запуска интеграционных и end-to-end тестов;
Проверки совместимости между сервисами;
Валидации миграций баз данных.

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

3.3. Предпродакшен (pre-production)

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

Performance-тесты;
Security-сканирования;
Business-валидация (QA, заказчик, аналитики).

Если система работает корректно в предпроде, она считается готовой к развёртыванию в production.

3.4. Продакшен (production)

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

Доступность (availability);
Надёжность (reliability);
Восстанавливаемость (recoverability).

Любое вмешательство в продакшен должно быть минимальным, контролируемым и обратимым.

4. Варианты развёртывания: от физических серверов до контейнеров

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

4.1. Физические серверы с прямым доступом

Исторически первым способом размещения ПО были выделенные физические серверы, на которых вручную устанавливались операционная система, зависимости и само приложение. Управление осуществлялось через SSH или консольные сессии.

Преимущества:

Полный контроль над «железом»;
Минимальные накладные расходы на виртуализацию.

Недостатки:

Высокая сложность масштабирования;
Слабая воспроизводимость сред («на моей машине работает»);
Длительное время развёртывания;
Сложность автоматизации без использования систем конфигурации (Ansible, Puppet, Chef).

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

4.2. Виртуальные машины (ВМ)

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

Преимущества:

Полная изоляция окружения;
Возможность клонирования и быстрого восстановления;
Поддержка мультиплатформенности (Linux/Windows на одном хосте).

Недостатки:

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

В CI/CD-конвейерах виртуальные машины часто используются как тестовые или staging-среды, однако в production-развёртываниях их постепенно вытесняют более лёгкие и гибкие решения.

4.3. Контейнеризация

Контейнеризация — это парадигма, при которой приложение и все его зависимости упаковываются в изолированный, переносимый образ, выполняемый в общей ОС хоста с использованием механизмов ядра (cgroups, namespaces). Наиболее распространённая реализация — Docker.

Контейнеры стали де-факто стандартом в CI/CD благодаря следующим свойствам:

Иммутабельность: образ создаётся один раз и используется на всех стадиях;
Идемпотентность: запуск одного и того же образа всегда даёт одинаковый результат;
Лёгкость: контейнеры запускаются за секунды и потребляют минимальные ресурсы;
Переносимость: один и тот же образ может работать локально, в облаке, на bare metal.

В сочетании с системами оркестрации (Kubernetes, Docker Swarm) контейнеризация позволяет реализовать масштабируемые, самовосстанавливающиеся и легко управляемые платформы. Именно с контейнерами наиболее органично сочетаются практики CI/CD:

После прохождения CI создаётся Docker-образ с уникальным тегом (например, по хешу коммита);
Образ помещается в registry (Docker Hub, Harbor, ECR и т.п.);
На staging или production система оркестрации подтягивает новый образ и запускает его в соответствии с политикой развёртывания.

Такой подход обеспечивает единый артефакт, проходящий все этапы без пересборки, что исключает так называемый «эффект дивана» («работает в тесте — не работает в проде»).

5. Откат и вывод из эксплуатации

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

5.1. Откат (rollback)

Откат — это процесс возвращения системы к предыдущему известному рабочему состоянию. Он может быть:

Автоматическим: при срабатывании триггеров мониторинга (например, рост ошибок 5xx, падение метрики liveness);
Ручным: по решению инженера или дежурного.

Для эффективного отката необходимы:

Хранение предыдущих версий артефактов (образов, пакетов);
Идемпотентные и обратимые миграции баз данных (или стратегия «только вперёд» с двойной совместимостью);
Версионирование конфигураций (через GitOps, например);
Минимальное время восстановления (MTTR).

Важно: откат не всегда возможен. Например, при изменении структуры данных без поддержки обратной совместимости. Поэтому в зрелых системах часто применяются стратегии развёртывания без отката, такие как feature toggles и постепенное включение функционала.

5.2. Вывод из эксплуатации (decommissioning)

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

Заменой сервиса на новый;
Устареванием функционала;
Снижением нагрузки до нуля.

Процедура включает:

Уведомление зависимых систем;
Миграция или архивирование данных;
Удаление маршрутов и DNS-записей;
Остановку и удаление контейнеров/виртуальных машин;
Документирование и аудит.

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

Gitflow

Gitflow: Это модель ветвления Git, которая определяет, как организовывать ветки кода для различных целей (например, разработка новых функций, исправление ошибок, релизы). Она помогает упорядочить процесс разработки и избежать конфликтов.

Основные ветки:

Ветка	Назначение
main	Стабильная версия продукта. Каждый коммит — полноценный релиз. Теги создаются здесь.
develop	Основная рабочая ветка для разработки. Все фичи объединяются (мерджатся) сюда.
`feature/*`	Ветки, выделенные для реализации новых функций.
`release/*`	Ветки для подготовки к выпуску релиза: тестирование, устранение критических ошибок.
`hotfix/*`	Ветки для оперативного исправления критических проблем в production-версии.

Тонкости CI/CD

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

Непрерывная интеграция (Continuous Integration, CI) и непрерывная доставка/развёртывание (Continuous Delivery/Deployment, CD) давно перестали быть опциональными практиками и превратились в основу современной инженерной дисциплины. Однако за фасадом «автоматической сборки и деплоя» скрывается комплекс взаимосвязанных процессов, инструментов и культурных норм, без которых CI/CD превращается в иллюзию контроля — пайплайны мигают зелёным, а инциденты всё равно случаются. Эта глава посвящена именно этим тонкостям: тем элементам, которые отличают формальное внедрение CI/CD от его зрелого, безопасного и устойчивого применения.

Эволюция платформ: от TFS к Azure DevOps и концепция ALM

Перед тем как говорить о пайплайнах, необходимо понять, в каком контексте они возникают. Многие современные подходы к CI/CD формируются не в вакууме, а под влиянием систем управления жизненным циклом приложений (Application Lifecycle Management, ALM). ALM — это не просто набор инструментов, а целостная методология, объединяющая требования, проектирование, разработку, тестирование, развертывание и поддержку в единую систему отслеживания и контроля.

Microsoft Team Foundation Server (TFS), а позже — его облачный преемник Azure DevOps, стали одними из первых коммерческих решений, предложивших интегрированную ALM-платформу. TFS изначально сочетал в себе контроль версий (сначала TFVC, позже Git), систему отслеживания задач, билд-сервер и средства тестирования. Хотя сегодня TFS морально устарел, его архитектурные решения оказали влияние на целое поколение инструментов: идея централизованного хаба, где всё — от идеи до эксплуатации — находится в одном контексте, оказалась продуктивной.

Azure DevOps унаследовал эту философию, но полностью перестроил архитектуру под открытые стандарты: Git вместо TFVC, YAML-пайплайны вместо графических билд-определений, интеграция с внешними системами через REST API и расширения. Это позволило сохранить преимущества ALM — сквозную трассировку, управление зависимостями, аудит — без привязки к экосистеме Microsoft. Однако важно понимать: ALM — это не про инструменты, а про практики. Даже при использовании GitHub Actions и Jira можно выстроить ALM-подход, если обеспечить связность между задачами, коммитами, пул-реквестами, тестами и деплоями.

CI/CD как система проверок, а не просто автоматизация

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

Предварительная валидация (pre-merge checks)

Каждый пул-реквест должен проходить серию автоматических проверок до мержа. Их цель — не дать «плохому» коду попасть даже в основную ветку. Сюда входят:

Линтинг и статический анализ кода. Инструменты вроде ESLint, Pylint, SonarQube, Checkstyle не просто проверяют стиль, но и могут выявлять потенциальные ошибки: неиспользуемые переменные, небезопасные шаблоны, утечки памяти. Статический анализ — это первая линия защиты от дефектов, обнаруживаемых лишь в рантайме.
Проверка на наличие секретов. Случайный коммит с токеном, паролем или приватным ключом — частая причина компрометации. Инструменты вроде truffleHog, gitleaks или GitGuardian сканируют историю и текущие изменения на наличие шаблонов, соответствующих секретам. Важно: сканирование должно быть частью pre-commit и pre-merge хуков, а не только CI — иначе секрет уже попадёт в репозиторий.
Валидация конфигураций. Современные приложения редко состоят только из кода. Их сопровождают конфигурации: YAML-файлы для Kubernetes, Helm-чарты, манифесты Terraform, Docker Compose. Ошибки в этих файлах — частая причина провалов деплоя. Существуют специализированные валидаторы: kubeval для Kubernetes, tflint для Terraform, helm lint для Helm. Их запуск в CI позволяет поймать синтаксические и логические ошибки до применения.
Policy-as-Code. Это более продвинутый уровень контроля: вместо простой валидации синтаксиса мы проверяем соответствие политике. Например: «все поды должны иметь лимиты CPU», «запрещено использовать образы из публичных реестров», «пароли должны храниться только в Vault». Для этого используются движки вроде Open Policy Agent (OPA) вместе с Conftest, который позволяет писать политики на языке Rego и применять их к любым структурированным данным (JSON, YAML, HCL).

Автоматическое тестирование

Тесты — ядро CI. Но важно понимать градацию:

Unit-тесты: быстрые, изолированные, проверяют логику отдельных функций.
Интеграционные тесты: проверяют взаимодействие компонентов (например, сервис → БД).
End-to-end (E2E) тесты: имитируют поведение пользователя, запускаются в окружении, максимально приближенном к продакшену.

В зрелом CI все три уровня присутствуют, но с разной скоростью выполнения и разной «стоимостью» сбоя. Unit-тесты должны проходить за секунды; E2E — за десятки минут. Критически важно: ни один уровень не должен быть пропущен, даже если пайплайн «спешит». Ложная экономия времени здесь ведёт к увеличению MTTR (Mean Time to Recovery).

Preflight-чеклист как формализация человеческого контроля

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

Подтверждение от ответственного инженера (approval).
Проверка наличия документации.
Подтверждение, что дежурный on-call доступен.
Успешное прохождение канареечного этапа (см. ниже).

В инструментах вроде GitHub Actions или Azure Pipelines такие условия реализуются через environment approvals и deployment gates. Это не бюрократия — это явное разделение зон ответственности и снижение риска «человеческого фактора».

Модели доставки: от полного ручного контроля к безопасному автоматическому деплою

CI/CD не означает, что каждый коммит автоматически попадает в продакшен. Существует спектр моделей:

Continuous Delivery (CDelivery): каждый коммит пригоден к развёртыванию, но развёртывание происходит по решению человека.
Continuous Deployment (CDeployment): каждый успешный коммит автоматически развёртывается в продакшен.

Между ними — множество промежуточных практик, главная из которых — канареечная поставка (canary deployment).

При канареечной поставке новая версия сначала развёртывается на небольшой процент трафика (например, 5%). Если метрики (ошибки, latency, потребление ресурсов) остаются в норме — трафик постепенно переключается на новую версию. В случае отклонения — трафик возвращается к старой версии, а новая откатывается. Это позволяет локализовать инцидент и минимизировать его последствия.

Альтернатива — blue/green deployment, где две идентичные среды («blue» и «green») живут параллельно. Деплой происходит в выключенную среду, после проверки — происходит мгновенное переключение трафика. Преимущество — мгновенный откат; недостаток — удвоенное потребление ресурсов.

Выбор модели зависит от критичности системы, зрелости мониторинга и культуры команды. Однако в любом случае автоматический откат (rollback) должен быть частью пайплайна, а не ручной процедурой из инструкции в Confluence.

Инфраструктура как код (IaC): контроль, валидация и аудит изменений

Современные системы доставки невозможны без концепции Infrastructure as Code (IaC). IaC — это не просто способ описать инфраструктуру в файлах, а фундаментальный сдвиг в управлении средами: инфраструктура становится версионируемой, повторяемой, тестируемой и подконтрольной.

Инструменты и подходы

Наиболее распространённые инструменты IaC:

Terraform — декларативный, провайдер-ориентированный, не привязан к конкретному облаку.
Pulumi — позволяет использовать полноценные языки программирования (TypeScript, Python, C#) для описания инфраструктуры.
AWS CloudFormation — нативное решение для AWS, тесно интегрировано с экосистемой.

Каждый из них требует соблюдения инженерной дисциплины:

Модульная структура. Инфраструктурный код должен разделяться по логическим границам: сеть, вычисления, базы данных, сервисы. Это снижает когнитивную нагрузку, упрощает тестирование и позволяет разным командам работать независимо.
CI для IaC. Каждое изменение в IaC-манифестах должно проходить те же проверки, что и код приложения: линтинг (tflint), проверка на секреты, статический анализ (checkov, tfsec), валидация синтаксиса (terraform validate), а также планирование изменений (terraform plan). Только после успешного прохождения всех этапов изменение может быть применено.
Drift detection. Со временем реальная инфраструктура может отклониться от описанной в коде (configuration drift) — например, из-за ручных изменений через консоль. Это нарушает принцип идемпотентности и создаёт риски. Terraform, Pulumi и облачные платформы (например, AWS Config) позволяют обнаруживать дрифт и либо автоматически выравнивать состояние, либо блокировать дальнейшие изменения до ручного разрешения.

Управление применением изменений

Просто описать инфраструктуру — недостаточно. Нужно контролировать, кто, когда и как её меняет.

Системы оркестрации IaC, такие как Terraform Cloud, Atlantis или Spacelift, позволяют централизовать применение планов. Вместо локального запуска terraform apply инженер создаёт пул-реквест → CI генерирует план → после апрува система автоматически применяет изменения.
Аудит изменений. Каждое применение должно сопровождаться записью: какие ресурсы менялись, кто инициировал, какая версия кода использовалась, ссылка на пул-реквест. Это критично для расследования инцидентов и соблюдения compliance.
Least Privilege в IaC. Учётные данные, используемые для применения инфраструктурных изменений, должны иметь минимально необходимые права. Например, сервисный аккаунт для развёртывания веб-сервиса не должен иметь прав на удаление VPC.

Безопасность пайплайнов: от сканирования зависимостей до двойной аутентификации

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

Анализ уязвимостей

Сканирование зависимостей. Инструменты вроде Snyk, Dependabot, Trivy и Clair анализируют package-lock.json, pom.xml, requirements.txt и другие файлы на наличие известных уязвимостей в используемых библиотеках. Сканирование должно происходить на каждом коммите и при обновлении образов.
Сканирование образов. Контейнерные образы также подвергаются анализу на наличие уязвимостей в ОС и зависимостях. Trivy и Clair особенно эффективны в этом сценарии.

Защита рантайм-креденшилов

Секреты в отдельных хранилищах. Никакие пароли, токены или ключи не должны храниться в коде или переменных окружения в открытом виде. Используются специализированные системы: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager. Доступ к ним предоставляется по принципу least privilege, и часто через временные токены (например, IAM Roles for Service Accounts в Kubernetes).
2FA и audit logs. Ключевые операции — развёртывание в продакшен, изменение IAM-политик, доступ к секретам — должны требовать двухфакторной аутентификации и логироваться с привязкой к пользователю. Логи должны быть неизменяемыми и храниться в отдельной системе, недоступной для редактирования разработчиками.

Наблюдаемость как основа доверия к автоматизации

Автоматический деплой возможен только при наличии наблюдаемости (observability). Без неё автоматизация превращается в «чёрный ящик», который может тихо ломать систему.

Три столпа наблюдаемости

Логи. События должны агрегироваться централизованно (через Loki, ELK, Splunk), с тегированием по сервису, окружению, trace ID. Фильтрация по компонентам позволяет быстро локализовать проблему.
Метрики. Системные (CPU, память, диски) и бизнес-метрики (latency, RPS, error rate) визуализируются на дашбордах (Grafana, Datadog, Prometheus). Дашборды должны быть едиными для всех сервисов — это снижает время реакции.
Трассировка. Распределённые системы требуют сквозного отслеживания запроса. OpenTelemetry (стандарт) в связке с бэкендами вроде Jaeger или Zipkin позволяет видеть путь запроса через микросервисы, выявлять узкие места и зависимости.

Алертинг и действия

Автоматический алертинг настраивается не на «всё подряд», а на отклонения от базовой линии (baseline) или нарушение SLO. Алерт должен содержать контекст: ссылку на дашборд, последний деплой, активные инциденты.
On-call ротация должна быть чётко задокументирована, с автоматическим оповещением (через PagerDuty, Opsgenie) и логированием всех действий дежурного. Это критично для анализа эффективности реагирования.

Организационные и документационные практики

Технологии — лишь часть системы. Без поддерживающей культуры CI/CD деградирует.

Документация как часть пайплайна. README, архитектурные диаграммы, описание переменных окружения — всё это должно поддерживаться в актуальном состоянии. Идеально — автогенерация документации: OpenAPI-спецификации для API, диаграммы из IaC-кода (например, через terraform graph или CloudCraft).
Preview-окружения. Каждый пул-реквест может создавать изолированное окружение (через Vercel, Render, или кастомные Helm-чарты), где можно вручную проверить изменения. Это особенно ценно для UI и интеграционных сценариев.
База знаний. Частые ошибки в пайплайнах, решения инцидентов, FAQ — всё это должно быть в wiki, с тегами и поиском. Это снижает зависимость от «ключевых» людей.
Постмортемы без обвинений. После каждого инцидента проводится анализ (RCA — Root Cause Analysis), фокусирующийся не на «кто виноват», а на «как система допустила сбой». Итог — документ с рекомендациями по улучшению процессов, инструментов или мониторинга.
Инвентаризация и контроль. Регулярный cron-скрипт или дашборд показывает все активные джобы, запланированные развёртывания, сроки действия сертификатов. Это предотвращает «забытые» компоненты, которые ломаются в самый неподходящий момент.

Процесс CI/CD

CI/CD (Continuous Integration / Continuous Delivery or Deployment) — это совокупность практик, инструментов и процессов, направленных на автоматизацию этапов разработки, тестирования, сборки, релиза и развёртывания программного обеспечения с целью обеспечения непрерывной, предсказуемой и надёжной доставки изменений в продуктивную среду.

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

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

В современной инженерной практике CI/CD-пайплайн традиционно разделяется на две логические части:

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

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

Я бы выделил восемь последовательных этапов:

Планирование;
Разработка;
Сборка;
Тестирование;
Релиз;
Развёртывание;
Управление развёртыванием;
Мониторинг.

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

Планирование (Planning).

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

Планирование включает:

Анализ бизнес-потребностей и формирование пользовательских историй (user stories);
Разработку технических спецификаций и диаграмм архитектуры;
Оценку трудозатрат и планирование спринтов (в рамках Agile/Scrum);
Документирование решений, политик доступа, стандартов кодирования и процедур управления конфигурацией.

Инструменты: Jira, Azure DevOps Boards, YouTrack, Trello, Confluence, Notion.

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

Разработка (Development).

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

Ключевые действия:

Написание кода с соблюдением принципов SOLID, DRY и других парадигм;
Реализация unit- и integration-тестов на этапе разработки;
Фиксация изменений в системе контроля версий с соблюдением семантического коммит-менеджмента;
Выполнение локальных проверок кода (linting, форматирование).

Инструменты: GitLab, GitHub, Bitbucket, Azure Repos.

Важно отметить, что мы не говорим о том, что разработчики ещё должны, собственно, разрабатывать продукт - для этого используются, очевидно, инструменты разработки и отладки - IDE (VS, IDEA), клиенты Git (CLI, TortoiseGit, GitHub Desktop, Fork), различные редакторы, СУБД (PostgreSQL, MS SQL), утилиты, прикладное и инженерное ПО - всё, что нужно для написания кода или создания приложений.

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

Разработка — источник изменений. Эффективность всей CI/CD-цепочки зависит от качества и регулярности коммитов в Git. Использование git-flow или trunk-based development определяет стратегию интеграции, поэтому ошибка на предыдущем этапе с выбором направления работы, здесь уже будет непростительной.

Сборка (Build).

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

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

Типовые действия:

Компиляция исходного кода (в случае языков со статической типизацией);
Упаковка в контейнеры, JAR, WAR, MSI, DEB, RPM и другие форматы;
Резолвинг зависимостей через менеджеры пакетов;
Генерация карт зависимостей и метаданных для трассировки.

Инструменты поэтому тут соответствуют языкам и технологиям:

Java/Kotlin/Scala: Maven, Gradle
.NET: MSBuild, dotnet CLI, Cake
Python: pip, poetry, setuptools
JavaScript/TypeScript: Webpack, Vite, esbuild, npm/yarn
Go: go build, mod
PHP: Composer
C/C++: CMake, Bazel, Ninja
Universal: Bazel, Pants (для многоязычных репозиториев)

Сборка обеспечивает воспроизводимость. Если сборка не проходит — дальнейшие этапы не имеют смысла. Артефакт, созданный на этом этапе, становится единственным источником правды (single source of truth) для всех последующих стадий.

Важно учитывать, что сборка может быть именно что автоматической, а от администраторов требуется лишь подтверждать действия, чтобы ускорить развёртывание.

Тестирование (Testing).

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

Различают следующие уровни тестирования:

Unit-тесты — проверяют отдельные модули или функции (например, метод класса).
Интеграционные тесты — проверяют взаимодействие между компонентами (база данных, API, внешние сервисы).
End-to-end (E2E) — имитируют поведение пользователя в полноценной среде.
Статический анализ кода — проверка на соответствие стандартам, наличие уязвимостей, дублирования и сложности.
Тестирование производительности и безопасности — нагрузочные тесты, SAST/DAST сканеры.

Соответственно, инструменты тоже зависят от вида тестирования:

Unit: JUnit (Java), NUnit (.NET), pytest (Python), Jest (JS), GoTest (Go)
Integration/E2E: Playwright, Selenium, Cypress, TestNG
SAST/DAST: SonarQube, Checkmarx, OWASP ZAP, Snyk
Coverage: JaCoCo, Istanbul, Coverage.py

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

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

Тестирование — механизм обратной связи. Автоматизированные тесты являются гарантом стабильности системы. Не прошедшие тесты блокируют продвижение артефакта дальше по пайплайну (gatekeeping).

Релиз (Release).

Релиз — это формальное создание версии продукта, готовой к распространению. На этом этапе артефакт, прошедший все этапы CI, маркируется версией (SemVer), сохраняется в репозиторий артефактов и сопровождается метаданными: хэш коммита, автор, дата, список изменений, ссылки на задачи.

Ключевые действия:

Присвоение версии (v1.2.3-beta.4);
Создание release-ветки или тега в репозитории;
Упаковка changelog, документации, лицензий;
Загрузка артефакта в централизованное хранилище (Artifact Repository).

Инструменты - Jenkins, GitLab CI/CD, Buildkite, CircleCI, GitHub Actions.

Релиз — точка невозврата. После этого этапа артефакт считается потенциально релизным. Он может быть задержан для ручного одобрения (Continuous Delivery) или сразу отправлен на деплой (Continuous Deployment).

Развёртывание (Deployment).

Развёртывание — процесс помещения артефакта в целевую среду (staging, canary, production). Этот этап отличается от сборки тем, что он связан с применением артефакта к работающей системе, а не с его созданием.

Действия включают:

Копирование артефакта на целевые серверы или в контейнерный реестр;
Подготовка конфигураций (config maps, secrets);
Запуск контейнеров, сервисов, функций;
Применение миграций БД (если требуется).

Инструменты:

Контейнеризация: Docker (создание образов), Podman
Serverless: AWS Lambda, Google Cloud Functions, Azure Functions
Облачные платформы: Terraform (инфраструктура как код), Pulumi
Специализированные деплоеры: Argo CD, Flux, Spinnaker

Развёртывание — переход от состояния «код написан» к состоянию «код работает». Качество этого этапа определяется воспроизводимостью и повторяемостью — один и тот же артефакт должен разворачиваться одинаково в dev, staging и prod.

Управление развертыванием (Orchestration & Infrastructure Management).

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

Ключевые задачи:

Управление кластерами контейнеров (оркестрация);
Автоматическое масштабирование по нагрузке;
Обеспечение высокой доступности (HA) и rolling updates;
Управление секретами, сетевыми политиками, RBAC;
Инфраструктура как код (IaC): декларативное описание окружения.

Инструменты:

Оркестрация: Kubernetes, Docker Swarm, Nomad
IaC: Terraform, Pulumi, AWS CloudFormation, Ansible
Управление конфигурацией: Helm, Kustomize, Crossplane

Без оркестрации развертывание становится хаотичным. Этот этап гарантирует, что инфраструктура соответствует описанному состоянию (desired state) и способна адаптироваться к изменениям без ручного вмешательства.

Мониторинг и обратная связь (Monitoring & Observability).

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

Ключевые направления:

Метрики: CPU, память, latency, throughput, error rate (Prometheus, Grafana);
Логи: централизованный сбор и поиск (ELK Stack, Loki, Splunk);
Трассировка: distributed tracing (Jaeger, OpenTelemetry);
Алертинг: автоматическое оповещение о девиациях (Alertmanager, PagerDuty);
Анализ причин отказов: root cause analysis на основе событий.

Инструменты: Prometheus, Grafana, Datadog, New Relic, ELK, Sentry, OpenTelemetry.

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

Azure Repos

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

Она включает в себя:

Azure Boards для отслеживания работы с помощью настраиваемых канбан-досок, интерактивных представлений невыполненной работы;
Azure Pipelines для того, чтобы создавать, тестировать и развёртывать решения с помощью конвейера CI/CD, который поддерживает любой язык, платформу и облако, а также возможностью подключения к GitHub;
Azure Test Plan для проведения тестов с помощью набора средств для произвольного и ручного тестирования;
GitHub Advanced Security для Azure DevOps позволяет использовать набор средств тестирования безопасности, встроенных в Azure DevOps;
GitHub Copilot для Azure DevOps позволяет повысить производительность разработчиков благодаря разработке с ИИ-помощью, используя GitHub Copilot с Azure Repos;
Azure Artifacts позволяет создавать, размещать и совместно использовать пакеты с командой, а также добавлять артефакты в конвейеры CI/CD одним щелчком мыши;

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

Azure Repos — это набор инструментов управления версиями, которые можно использовать для управления кодом.

Azure Repos предоставляет два типа контроля версий:

Git : распределенный контроль версий
Team Foundation Version Control (TFVC) : централизованный контроль версий

Git в Azure Repos — это стандартный Git. Вы можете использовать клиенты и инструменты по своему выбору, такие как Git для Windows, Mac, партнерские сервисы Git и такие инструменты, как Visual Studio и Visual Studio Code.

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

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

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

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

Azure Repos также поддерживает Team Foundation Version Control (TFVC). TFVC — это централизованная система управления версиями. Обычно члены команды имеют только одну версию каждого файла на своих машинах разработки. Исторические данные хранятся только на сервере. Ветви основаны на путях и создаются на сервере.

Порядок работы:

Клонирование или создание репозитория в Azure DevOps. Вы можете клонировать удаленный репозиторий Git, чтобы создать его локальную копию. Клонирование создает как копию исходного кода для работы, так и информацию о контроле версий, чтобы Git мог управлять исходным кодом.
Работа с веткой для каждой функции или исправления:
- создание ветки через git branch;
- переключение на ветку через checkout.

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

Пример:

git checkout main
git pull origin main
git branch users/test/feature1
git checkout users/test/feature1

Работа с кодом.
Объединение изменений с запросом на вытягивание, процесс проверки и слияния кода. После того, как вы закончите исправление ошибки или новой функции в ветке, создайте новый запрос (Create a pull request). Новые запросы на извлечение настроены на слияние вашей ветки с веткой по умолчанию, которая в этом примере — main. Заголовок и описание предварительно заполнены вашим сообщением о коммите.

Team Foundation Version Control — централизованная система управления версиями, чем и отличается от Git. Обычно члены команды имеют только одну версию каждого файла на своих машинах разработки. Исторические данные хранятся только на сервере. Ветви основаны на путях и создаются на сервере.

Git хранит историю как снимок репозитория во времени, в то время как TFVC записывает отдельные операции, которые были выполнены с файлом. Типы изменений в TFVC, такие как переименование, отмена удаления и откат, не могут быть выражены в Git. Вместо того, чтобы увидеть, что файл Aбыл переименован в file B, он отслеживает только, что файл Aбыл удален и file Bбыл добавлен в том же коммите.

У Git нет прямого аналога метки TFVC. Метки могут содержать любое количество файлов любой конкретной версии и могут отражать файлы разных версий. Хотя концептуально они схожи, теги Git указывают на снимок всего репозитория в определенный момент времени. Если проект полагается на метки TFVC, чтобы знать, что было доставлено, теги Git могут не предоставлять эту информацию.

Слияния в TFVC происходят на уровне файлов, а не всего репозитория. Только подмножество измененных файлов может быть объединено из одной ветки в другую. Оставшиеся измененные файлы могут быть затем объединены в последующий набор изменений. В Git слияние влияет на весь репозиторий, и оба набора отдельных изменений не могут рассматриваться как слияние.

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

TFS
Подробнее про TFS

Git в работе DevOps

Код может быть проверен автоматически или вручную. Вручную проверяется, к примеру, старшим разработчиком – такой процесс называют «код-ревью». Автоматическая проверка же включает авторелиз и автотест.

Авторелиз (Continuous Deployment) – процесс автоматического выкладывания новой версии кода в продакшн после успешного прохождения тестов.

Это работает так:

разработчик вносит изменения и пушит в Git;
CI/CD система (GitHub Actions, GitLab CI, Jenkins) запускает тесты;
тесты успешны – код автоматически деплоится на сервер.

Автотесты – программы, которые проверяю код вместо человека. Примеры:

Тип	Проверка	Пример
Unit-тесты	Отдельные функции и методы	Jest, Pytest
Интеграционные	Взаимодействие между компонентами (например, API и база данных)	Postman, Cypress
E2E (End-to-End)	Полный сценарий работы приложения, имитация действий пользователя	Selenium, Playwright

Подробнее о тестировании мы поговорим в отдельной главе.

Системы контроля версий поддерживают механизм хуков – скриптов, которые выполняются при определенных событиях. Допустим, можно проверить стиль кода, запустить линтер, запустить тесты или установить новые зависимости.

Линтер – это инструмент, который автоматически проверяет код на ошибки, стиль и потенциальные проблемы, но не запускает выполнение кода. Словом, выполняет человеческую работу по проверке. Он настраивается под проект, запускается вручную или автоматически, к примеру подсветка ошибок синтаксиса в IDE (и редакторах кода вроде VS Code) и есть работа линтера. Линтер в гит-хуках не даёт закоммитить «грязный» код.

Линтер:

отлавливает простые ошибки (опечатки, синтаксис);
следит за единым стилем (пробелы, отступы, названия переменных);
улучшает читаемость кода.

Примеры линтеров:

Язык	Инструменты	Предмет проверки
JavaScript	ESLint, JSHint	Синтаксис, стиль кода, потенциальные ошибки, безопасность
Python	Pylint, Flake8	Отступы, именование, структура кода, распространённые ошибки
Java	Checkstyle, PMD	Стиль кодирования, цикломатическая сложность, потенциальные дефекты
C/C++	Clang-Tidy, Cppcheck	Утечки памяти, неопределённое поведение, стилевые нарушения

Также существует механика авторелизов, к примеру по модели Git Flow, это веточная стратегия, которая упорядочивает процесс разработки и выпуска версий. Некий методологический подход разбивки, включает в себя основные ветки:

main / master – стабильная версия (продакшен-код);
develop – основная ветка для текущей разработки;
feature – ветки для новых функций (фич);
release – подготовка релиза, тестирование, фиксы багов;
hotfix – срочные, «горячие» исправления.

Что такое GitHub Actions и GitLab CI?

Это инструменты, которые автоматизируют сборку, тестирование и деплой.

В репозитории лежит файл deploy.yml, описывающий шаги. При пуше GitHub/GitLab запускает виртуальную машину и выполняет шаги:

установка зависимостей (npm install);
запуск тестов (npm test);
деплой (scp на сервер или публикация в облако).

Также есть решения Jenkins и TeamCity, фактически выполняющие те же действия – Сборка → Тесты → Деплой. Но требуется администрировать сервер, да и настраивать можно через более дружелюбный интерфейс.

Всё вместе работает так:

Разработчик пишет код и пушит в Git;
Хук (pre-push) проверяет, что код проходит линтеры;
CI/CD запускает автотесты;
Если тесты OK – код мерджится в main;
Авторелиз деплоит новую версию на сервер.

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

Инструменты

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

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

1. Инфраструктура как код (Infrastructure as Code, IaC)

Традиционный подход к развёртыванию серверов и сетевых компонентов предполагал ручное взаимодействие с облачными консолями или физической инфраструктурой. Такой подход непрозрачен, подвержен ошибкам и не поддерживает воспроизводимость. В ответ на эти вызовы появился принцип Infrastructure as Code (IaC) — управление инфраструктурой через декларативное или императивное описание, выполненное в виде исполняемого кода.

Terraform

Terraform, разработанный компанией HashiCorp, представляет собой декларативный инструмент IaC, использующий собственный язык конфигурации HCL (HashiCorp Configuration Language). Он позволяет описывать желаемое состояние инфраструктуры: виртуальные машины, сети, балансировщики нагрузки, базы данных и т.п. — независимо от облачного провайдера.

При выполнении terraform apply система сравнивает текущее состояние ресурсов с декларированным и вносит необходимые изменения. Terraform поддерживает сотни провайдеров, включая AWS, Azure, Google Cloud, Cloudflare и даже локальные решения вроде Proxmox or VMware. Такой подход позволяет легко клонировать окружения, обеспечивать идемпотентность и аудит изменений через систему контроля версий.

Ansible

В отличие от Terraform, Ansible относится к классу инструментов конфигурационного управления. Он описывает не столько создание инфраструктуры, сколько её конфигурацию: установку пакетов, копирование файлов, запуск служб, управление пользователями. Конфигурации описываются в формате YAML в виде плейбуков (playbooks). Ansible не требует установки агентов на целевые серверы — он использует SSH (Linux) или WinRM (Windows).

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

2. CI/CD-системы: ядро автоматизации

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

GitLab CI

GitLab CI интегрирован непосредственно в платформу GitLab. Конфигурация пайплайна задаётся в файле .gitlab-ci.yml в корне репозитория. Этот файл описывает стадии (например, build, test, deploy) и джобы, выполняемые в изолированных контейнерах (runners). GitLab CI поддерживает кэширование зависимостей, артефакты сборки, условия запуска джобов и сложные сценарии с параллелизацией.

Преимущество GitLab CI — тесная интеграция с репозиторием, системой ревью, реестром контейнеров и даже мониторингом (через GitLab Observability). Это делает его удобным для организаций, стремящихся к единой платформе разработки и доставки.

GitHub Actions

GitHub Actions — аналог GitLab CI, но для платформы GitHub. Конфигурация размещается в директории .github/workflows в виде одного или нескольких YAML-файлов. Каждый файл описывает один workflow, который срабатывает по триггеру: push, pull_request, расписание и т.д.

GitHub Actions использует концепцию actions — переиспользуемых компонентов, которые могут быть написаны как на JavaScript, так и как Docker-контейнеры. Это позволяет легко интегрировать сторонние инструменты (например, Trivy, SonarQube) в пайплайн. Экосистема Actions активно развивается и включает как официальные, так и community-решения.

Jenkins

Jenkins — одна из старейших и наиболее гибких CI/CD-систем. Это веб-приложение, запускаемое на сервере (часто в контейнере или как Java-приложение под Tomcat). Jenkins использует плагины для расширения функциональности — их насчитывается более 1800. Конфигурация пайплайнов может осуществляться как через веб-интерфейс, так и в виде Jenkinsfile, описывающего Declarative или Scripted Pipeline.

Jenkins часто используется в организациях с унаследованной инфраструктурой: например, там, где исходный код хранится в Subversion (SVN), а сборка требует сложных кастомных шагов. Однако по сравнению с современными облачными решениями Jenkins требует более высоких затрат на сопровождение и масштабирование.

3. Контейнеризация и оркестрация

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

Docker позволяет создавать изолированные, переносимые среды выполнения, включающие приложение и все его зависимости. Благодаря Docker образ становится единицей доставки: его можно собирать в CI-процессе, проверять на уязвимости, публиковать в реестре и развёртывать в любом окружении.

Kubernetes (K8s) — система оркестрации контейнеров, обеспечивающая управление распределёнными кластерами. Kubernetes автоматически распределяет нагрузку, обеспечивает отказоустойчивость, позволяет масштабировать приложения в зависимости от метрик и управлять обновлениями без простоя (rolling updates). В CI/CD-контексте пайплайн часто завершается командой kubectl apply или использованием Helm-чартов для развёртывания в K8s.

4. Мониторинг, логирование и трассировка

После деплоя начинается фаза наблюдения за системой. Здесь применяются инструменты трёх типов: метрики, логи и трассировки — составляющие наблюдаемости (observability).

Prometheus

Prometheus — система сбора и хранения временных рядов (time series), ориентированная на динамические окружения. Она работает по модели pull: периодически опрашивает эндпоинты приложений (или экспортеры), собирая метрики в формате текста. Prometheus поддерживает мощный язык запросов PromQL, позволяет строить алерты и интегрируется с Kubernetes через ServiceMonitor и PodMonitor.

Grafana

Grafana — платформа визуализации, нейтральная к источникам данных. Она может подключаться к Prometheus, Elasticsearch, Loki, Mimir, MySQL и десяткам других систем. Grafana позволяет строить дашборды с графиками, таблицами и алертами, обеспечивая единое окно наблюдения за всей системой.

ELK-стек

Классическое решение для анализа логов — ELK-стек:

Elasticsearch — распределённая поисковая система, оптимизированная для полнотекстового поиска и агрегаций;
Logstash — конвейер обработки событий: приём, фильтрация, трансформация и отправка логов;
Kibana — веб-интерфейс для поиска, анализа и визуализации логов.

ELK требует значительных ресурсов и сложен в сопровождении, но остаётся популярным в enterprise-средах.

Loki, Tempo, Mimir

Альтернативный подход предлагает Grafana Labs через стек Grafana + Loki + Tempo + Mimir:

Loki — лог-агрегатор, индексирующий логи только по меткам (labels), что радикально снижает объём хранилища;
Tempo — система распределённой трассировки, поддерживающая OpenTelemetry, Jaeger и Zipkin;
Mimir — масштабируемая замена Prometheus для хранения метрик, поддерживающая мульти-тенантность и длительное хранение.

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

DBSExporter и WAL-G

Специализированные инструменты расширяют наблюдаемость и надёжность баз данных:

DBSExporter — экспортер метрик СУБД в формате Prometheus, позволяющий отслеживать количество соединений, время выполнения запросов, использование кэшей и т.п.;
WAL-G — утилита для резервного копирования PostgreSQL, MySQL и других СУБД с использованием Write-Ahead Logs (WAL) — журнала изменений, записываемого перед применением транзакций. Это позволяет выполнять инкрементальные бэкапы и восстановление до заданной точки (PITR).

5. Безопасность в CI/CD

Современные CI/CD-процессы включают этапы обеспечения безопасности на ранних стадиях — подход, известный как Shift Left Security.

WAF

Web Application Firewall (WAF) — проксирующий или встроенный компонент, анализирующий HTTP/HTTPS-трафик на предмет атак (SQLi, XSS, RCE и др.). Примеры: Cloudflare WAF, AWS WAF. WAF защищает приложение на границе сети, но не заменяет внутреннюю безопасность.

Сканирование уязвимостей

Инструменты вроде Trivy (для контейнеров и зависимостей) и OWASP ZAP (для динамического анализа веб-приложений) интегрируются в CI-пайплайн. Например, если Trivy обнаруживает критическую уязвимость в базовом образе Docker, пайплайн может быть прерван, и сборка — отклонена.

Управление хранилищами

Хотя Storage Resource Management (SRM) традиционно относится к инфраструктурному уровню, его компоненты всё чаще встраиваются в CI/CD-процессы через управление бэкапами и миграциями. Rclone — утилита командной строки для копирования и синхронизации данных между локальными и облачными хранилищами (S3, GCS, Azure Blob и др.) — используется для архивации артефактов, логов или WAL-файлов в надёжные места.

6. Интеграция в единый процесс

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

Типичный сценарий:

Разработчик отправляет изменения в Git-репозиторий.
GitLab CI (или GitHub Actions, Jenkins) запускает пайплайн:
- Собирает приложение.
- Запускает модульные и интеграционные тесты.
- Сканирует зависимости и Docker-образ на уязвимости (Trivy).
При успешном прохождении тестов Terraform применяет изменения в облачной инфраструктуре (если требуется новое окружение).
Ansible настраивает виртуальные машины или готовит хосты под контейнеры.
Docker собирает образ, который публикуется в registry.
Kubernetes применяет обновлённую конфигурацию и развёртывает новый образ.
Prometheus начинает собирать метрики с нового приложения.
Grafana отображает состояние системы в реальном времени.
WAF блокирует подозрительные запросы.
Loki и Tempo собирают логи и трассировки, позволяя быстро диагностировать проблемы.

7. Архитектура CI/CD-пайплайна: стадии, артефакты и идемпотентность

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

Checkout / Clone — извлечение исходного кода из системы контроля версий.
Build — компиляция кода, установка зависимостей, генерация исполняемых артефактов.
Test — запуск автоматизированных тестов: unit, integration, end-to-end.
Scan — статический анализ кода (SAST), сканирование зависимостей и образов на уязвимости.
Package — упаковка артефакта: JAR, Docker-образ, Helm-чарт и т.п.
Deploy (to staging) — развёртывание в тестовом или промежуточном окружении.
Validate — E2E-тестирование в staging, проверка работоспособности под нагрузкой или в интеграции.
Promote / Release — перенос артефакта в production или его публикация в реестре.
Deploy (to production) — безопасное развёртывание в рабочем окружении.
Notify / Observe — уведомление команды, запуск мониторинга, сбор метрик и логов.

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

использование версионируемых артефактов (например, Docker-образ с фиксированным SHA-хэшем);
изоляции окружений через контейнеры или виртуализацию;
отказа от побочных эффектов в стадиях сборки и тестирования.

Артефакты, созданные на ранних стадиях (например, Docker-образ), не пересобираются на последующих этапах — они лишь перемещаются между окружениями. Такой подход называется immutable infrastructure (неизменяемая инфраструктура) и минимизирует расхождения между staging и production.

8. Безопасность как неотъемлемая часть пайплайна

Модель DevSecOps предполагает встраивание практик безопасности на каждом этапе разработки, а не в виде финальной проверки. Это реализуется через следующие механизмы:

8.1. Статический анализ кода (SAST)

Инструменты вроде SonarQube, Semgrep или Checkmarx анализируют исходный код на наличие потенциальных уязвимостей: SQL-инъекции, небезопасная работа с памятью, раскрытие секретов. Такие проверки запускаются на стадии build или scan. Если обнаружена критическая проблема, пайплайн может быть остановлен, и pull request — заблокирован.

8.2. Сканирование зависимостей и образов (SCA & Container Scanning)

Software Composition Analysis (SCA) — анализ используемых библиотек на наличие известных уязвимостей (CVE). Инструменты: OWASP Dependency-Check, Snyk, Trivy.

Trivy, в частности, поддерживает сканирование не только контейнерных образов, но и файлов package-lock.json, requirements.txt, pom.xml и т.д. Его легко встроить в пайплайн как отдельную джобу:

scan-image:
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity CRITICAL my-registry/app:$CI_COMMIT_SHA

Если найдена уязвимость уровня CRITICAL, код возврата будет отличен от нуля, и пайплайн остановится.

8.3. Управление секретами

Хранение API-ключей, паролей и сертификатов непосредственно в коде недопустимо. CI/CD-системы предоставляют механизмы управления секретами:

GitLab CI: masked и protected variables, интеграция с HashiCorp Vault.
GitHub Actions: Encrypted Secrets в настройках репозитория.
Jenkins: Credentials Binding Plugin.

Секреты передаются в пайплайн только во время выполнения и недоступны в логах или артефактах.

9. Модели развёртывания в production

Одна из самых ответственных стадий CI/CD — доставка в production. Существует несколько стратегий, каждая из которых балансирует между скоростью, риском и сложностью:

9.1. Blue/Green Deployment

Создаются два идентичных окружения: blue (текущее) и green (новое). После развёртывания и валидации нового приложения трафик переключается с одного на другое мгновенно (через балансировщик). При проблеме — мгновенный откат.

Требует удвоения ресурсов, но обеспечивает нулевой downtime и полную воспроизводимость.

9.2. Canary Release

Новая версия развёртывается частично: например, 5% пользователей направляются на неё. Метрики (ошибки, latency, conversion) анализируются в реальном времени. При стабильности — трафик постепенно увеличивается до 100%.

Требует тонкой инструментации мониторинга и поддержки в маршрутизаторе (например, Istio в Kubernetes).

9.3. Rolling Update

Контейнеры или инстансы обновляются постепенно, по одному или группами. Kubernetes поддерживает эту модель «из коробки» через Deployment-контроллер. Минимизирует потребление ресурсов, но усложняет откат при частичном сбое.

Выбор модели зависит от требований к доступности, зрелости мониторинга и допустимого риска.

10. Ограничения и антипаттерны

Несмотря на мощь современных инструментов, CI/CD-системы подвержены типичным ошибкам:

Неидемпотентные джобы: например, генерация случайного имени базы данных на каждом запуске — приводит к непредсказуемости.
Отсутствие изоляции: использование общего кэша между ветками или проектами может привести к «заражению» артефактов.
Слишком длинные пайплайны: если полный цикл занимает часы, разработчики начинают обходить CI, что подрывает культуру качества.
Отсутствие мониторинга самого пайплайна: падение runner’ов, нехватка дискового пространства, утечки секретов — всё это требует алертинга.
Ручные вмешательства в production: если деплой возможен только через CLI команду отдельного инженера, автоматизация теряет смысл.

Зрелость CI/CD оценивается не по наличию инструментов, а по степени доверия команды к пайплайну: может ли разработчик смело нажать «merge», зная, что система сама всё проверит, соберёт, протестирует и безопасно доставит?

11. Роль DevOps-инженера в CI/CD-экосистеме

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

проектирует и поддерживает CI/CD-инфраструктуру;
обеспечивает соответствие практикам IaC и immutable infrastructure;
интегрирует инструменты мониторинга, логирования и безопасности;
автоматизирует рутинные операции (бэкапы, обновления, масштабирование);
обучает команду работе с пайплайнами и диагностике сбоев.

Важно: инженер не должен быть «шлюзом» для деплоя. Его задача — делегировать безопасность и надёжность системе, а не контролировать её вручную.

12. Сравнение инструментов: выбор в контексте задачи

Выбор того или иного инструмента редко бывает однозначным. Он определяется масштабом проекта, уровнем зрелости команды, требованиями к безопасности, наличием legacy-систем и предпочтениями в экосистеме. Ниже — аналитическое сравнение по ключевым параметрам.

12.1. Системы управления инфраструктурой

Критерий	Terraform	Pulumi	AWS CloudFormation
Язык описания	HCL (декларативный)	TypeScript/Python/Go/C# (императивный+декларативный)	YAML/JSON (декларативный)
Мультиоблачность	Да (через провайдеры)	Да	Только AWS
Управление состоянием	Требует backend (S3, Terraform Cloud и др.)	Опционально (локально или через Pulumi Service)	Управляется AWS
Обучаемость	Средняя	Высокая для разработчиков	Низкая (сложный синтаксис)
Идемпотентность	Гарантирована	Зависит от кода	Гарантирована

Вывод: Terraform остаётся стандартом де-факто для мультиоблачных IaC-проектов. Pulumi привлекателен для команд с сильными навыками программирования, но требует большей дисциплины.

12.2. CI/CD-платформы

Критерий	GitLab CI	GitHub Actions	Jenkins
Интеграция с VCS	Встроенная (GitLab)	Встроенная (GitHub)	Любой (через плагины)
Конфигурация	`.gitlab-ci.yml`	`.github/workflows/*.yml`	`Jenkinsfile` или UI
Масштабируемость	Высокая (через GitLab Runners)	Ограничена квотами (minutes/month)	Высокая (самостоятельное масштабирование)
Поддержка legacy	Ограничена	Минимальная	Высокая (SVN, Ant, Windows-агенты)
Self-hosted	Да	Только через Actions Runner	Да
Безопасность	Хорошая (protected branches, masked vars)	Хорошая	Требует ручной настройки

Вывод: Для новых проектов на GitHub предпочтителен GitHub Actions. GitLab CI — выбор при использовании GitLab как единой платформы. Jenkins оправдан только при наличии унаследованных процессов или сложных custom-сценариев, которые не умещаются в модель YAML-пайплайнов.

13. Пример: полный CI/CD-пайплайн в GitLab CI

Рассмотрим реалистичный .gitlab-ci.yml для веб-приложения на Python с развёртыванием в Kubernetes. Конфигурация включает сборку, тестирование, сканирование, упаковку и безопасный деплой.

stages:
  - build
  - test
  - scan
  - deploy

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  KUBE_NAMESPACE: production

# Сборка Docker-образа
build-image:
  stage: build
  image: docker:20.10.16
  services:
    - docker:20.10.16-dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $DOCKER_IMAGE .
    - docker push $DOCKER_IMAGE
  only:
    - main

# Запуск unit-тестов
run-tests:
  stage: test
  image: python:3.11
  before_script:
    - pip install -r requirements.txt
  script:
    - pytest tests/unit/

# Сканирование образа на уязвимости
security-scan:
  stage: scan
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity CRITICAL $DOCKER_IMAGE
  dependencies:
    - build-image
  only:
    - main

# Деплой в Kubernetes
deploy-to-k8s:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl config set-cluster k8s --server="$KUBE_URL" --insecure-skip-tls-verify=true
    - kubectl config set-credentials gitlab --token="$KUBE_TOKEN"
    - kubectl config set-context default --cluster=k8s --user=gitlab --namespace=$KUBE_NAMESPACE
    - kubectl config use-context default
    - sed "s|__IMAGE__|$DOCKER_IMAGE|g" k8s/deployment.yaml | kubectl apply -f -
  dependencies:
    - security-scan
  only:
    - main
  environment:
    name: production

Пояснения:

Образ собирается один раз и используется во всех последующих стадиях.
Сканирование запускается только после успешной сборки.
Деплой возможен только если сканирование пройдено.
Переменные KUBE_TOKEN, CI_REGISTRY_PASSWORD хранятся как protected masked variables.
Используется immutable tag ($CI_COMMIT_SHORT_SHA), что гарантирует воспроизводимость.

Такой пайплайн соответствует принципам GitOps: желаемое состояние системы описывается в коде, а изменения применяются через pull request и автоматизированный CI.

14. CI/CD в контексте архитектуры приложения

Подход к CI/CD существенно различается в зависимости от того, с какой архитектурой работает команда.

14.1. Монолит

Для монолита типичен единый пайплайн:

Один репозиторий → один образ → одно развёртывание.
Преимущество: простота оркестрации.
Недостаток: любое изменение требует полного деплоя, что увеличивает риски.

Рекомендация: вводить feature flags, чтобы отделять деплой от включения функции.

14.2. Микросервисы

Каждый сервис имеет собственный репозиторий и пайплайн. Это даёт независимость, но ставит новые задачи:

Совместимость API: необходимы контрактные тесты (consumer-driven contracts).
Синхронизация релизов: требуются механизмы отслеживания версий (например, через Git tags или специальные метки в registry).
Общие зависимости: базовые Docker-образы, библиотеки — должны управляться централизованно.

Рекомендация: использовать service mesh (Istio, Linkerd) для управления трафиком между версиями сервисов.

14.3. Serverless (FaaS)

В архитектурах на основе AWS Lambda, Azure Functions или Cloudflare Workers CI/CD упрощается в части оркестрации, но усложняется в части тестирования:

Нет прямого доступа к среде выполнения.
Требуется эмуляция триггеров (HTTP, очередь, таймер).
Развёртывание осуществляется через IaC (Terraform, SAM, Serverless Framework).

Пример: пайплайн для AWS Lambda может включать:

Сборку ZIP-артефакта.
Запуск локальных тестов с помощью sam local invoke.
Загрузку артефакта в S3.
Обновление функции через aws lambda update-function-code.

15. Дальнейшие направления развития CI/CD

Современные тенденции указывают на следующие векторы:

GitOps: управление инфраструктурой и развёртыванием исключительно через Git-репозиторий (FluxCD, Argo CD).
Policy as Code: проверка соответствия инфраструктуры политикам безопасности (Open Policy Agent, Sentinel).
Chaos Engineering в CI: запуск контролируемых сбоев в staging для проверки устойчивости.
AI-assisted CI: автоматическое предложение оптимизаций пайплайна на основе анализа истории выполнений.

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

Чем отличается DevOps от сисадмина?

Критерий	DevOps-инженер	Системный администратор
Основная задача	Автоматизация процессов разработки и доставки программного обеспечения	Поддержка и эксплуатация IT-инфраструктуры
Фокус	Скорость и надёжность выпуска ПО	Стабильность и безопасность серверов и систем
Работа с кодом	Написание скриптов, конфигурация инструментов в виде кода (Infrastructure as Code)	В основном использование графических интерфейсов; редкое применение скриптов
Инструменты	Docker, Kubernetes, CI/CD-системы (например, Jenkins, GitLab CI), Terraform	Active Directory, системы виртуализации (VMware, Hyper-V), Zabbix
Культура работы	Интеграция в команду разработки, практика непрерывной поставки	Часть отдела эксплуатации, реактивное обслуживание
Типичные задачи	Настройка CI/CD-пайплайнов; развёртывание и масштабирование микросервисов; мониторинг приложений и инфраструктуры	Установка операционных систем и программного обеспечения; резервное копирование данных; настройка сетевого и серверного оборудования
Ответственность	Обеспечение скорости доставки и безопасности процессов разработки	Обеспечение стабильности и доступности IT-сервисов

Автоматизация

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

В современных вычислительных средах, особенно в условиях облачной инфраструктуры, микросервисной архитектуры и циклов непрерывной поставки программного обеспечения (CI/CD), автоматизация перестала быть опциональной практикой — она стала неотъемлемым компонентом жизнеспособной и конкурентоспособной ИТ-системы. Автоматизация затрагивает такие области, как развёртывание инфраструктуры, конфигурация серверов, управление жизненным циклом приложений, мониторинг, логирование, резервное копирование и восстановление данных.

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

Системы автоматизации

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

По уровню абстракции: от низкоуровневых скриптов (Bash, PowerShell) до декларативных описаний инфраструктуры (Terraform, Pulumi).
По модели исполнения: push-модель (инициатор — управляющая система) и pull-модель (инициатор — целевой узел).
По сфере применения: конфигурационное управление, оркестрация развёртываний, управление инфраструктурой как кодом (IaC), автоматизация тестирования и т.д.

Ключевые характеристики зрелой системы автоматизации включают:

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

Ansible: автоматизация конфигурации и оркестрации

Ansible — это opensource-платформа для автоматизации конфигурации, развёртывания и оркестрации, разработанная Red Hat. Отличительной чертой Ansible является использование push-модели и отсутствие необходимости в установке агентов на управляемые узлы. Взаимодействие с узлами осуществляется по протоколу SSH (в Unix-средах) или WinRM (в Windows), что упрощает развёртывание и снижает операционные накладные расходы.

Ansible оперирует понятием плейбука (playbook) — файла в формате YAML, в котором декларативно описывается желаемое состояние системы. Плейбук состоит из одной или нескольких plays, каждая из которых определяет, на каких узлах (hosts) и какие задачи (tasks) должны быть выполнены с использованием модулей Ansible. Модули — это переиспользуемые компоненты, инкапсулирующие конкретные операции (установка пакета, запуск службы, копирование файла и т.п.).

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

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

Terraform: управление инфраструктурой как кодом

Terraform, разработанный компанией HashiCorp, представляет собой инструмент класса Infrastructure as Code (IaC), предназначенный для декларативного описания, планирования и управления жизненным циклом облачных и локальных ресурсов. В отличие от инструментов конфигурационного управления (таких как Ansible или Chef), Terraform фокусируется на создании и уничтожении ресурсов, а не на их последующей настройке.

Terraform использует собственный декларативный язык — HashiCorp Configuration Language (HCL) — для описания желаемого состояния инфраструктуры. Пользователь определяет, какие ресурсы должны существовать (виртуальные машины, сети, базы данных, балансировщики и т.д.), а Terraform вычисляет разницу между текущим и желаемым состоянием, формируя план применения (execution plan). Пользователь может проанализировать план до его применения, что значительно повышает безопасность и предсказуемость изменений.

Ключевые концепции Terraform:

Провайдеры (providers) — плагины, интегрирующие Terraform с конкретными платформами (AWS, Azure, Google Cloud, VMware и др.).
Состояние (state) — файл (обычно terraform.tfstate), в котором хранится информация о текущих ресурсах. Состояние позволяет Terraform отслеживать изменения и корректно управлять жизненным циклом.
Модули (modules) — способ инкапсуляции и повторного использования конфигураций, аналогичный ролям в Ansible, но применительно к инфраструктуре.

Terraform обеспечивает управляемую эволюцию инфраструктуры: изменения вносятся постепенно, с возможностью отката, а вся конфигурация подвергается версионному контролю, что соответствует принципам DevOps и GitOps.

Методологии DevOps и роль автоматизации

DevOps (сокращение от Development и Operations) — это совокупность практик, культурных норм и инструментов, направленных на сокращение цикла разработки программного обеспечения и повышение качества поставки. В основе DevOps лежит идея непрерывного сотрудничества между командами разработки и эксплуатации, а также автоматизация всех возможных этапов жизненного цикла приложения.

Автоматизация играет центральную роль в реализации ключевых DevOps-практик:

Непрерывная интеграция (CI): автоматическая сборка и тестирование кода при каждом коммите.
Непрерывная поставка/развёртывание (CD): автоматическое развёртывание приложения в тестовые и продакшн-среды.
Инфраструктура как код (IaC): управление средами с помощью версионируемых скриптов.
Мониторинг и обратная связь: автоматический сбор метрик и логов для быстрого выявления и устранения проблем.

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

Важно подчеркнуть, что успешное внедрение DevOps требует не только технической трансформации, но и культурных изменений: отказа от silo-менталитета, внедрения shared responsibility, прозрачности процессов и постоянного цикла улучшений (feedback loops).

Непрерывное архивирование и Point-in-Time Recovery (PITR)

В современных распределённых и высоконагруженных системах обеспечение целостности и доступности данных критически важно. Одним из ключевых механизмов, обеспечивающих надёжность хранения данных, является непрерывное архивирование (Continuous Archiving), которое тесно связано с методом восстановления на определённый момент времени (Point-in-Time Recovery, PITR). Эти подходы особенно актуальны для систем управления реляционными базами данных, таких как PostgreSQL, где они реализованы через архивирование журналов предзаписи (Write-Ahead Logging, WAL).

Принцип работы непрерывного архивирования

Непрерывное архивирование основывается на постоянном сохранении журналов транзакций — последовательных записей о всех изменениях, внесённых в базу данных. В PostgreSQL эти журналы представлены файлами WAL, которые создаются при каждом изменении состояния данных (вставка, обновление, удаление и т.п.). WAL-файлы не только обеспечивают целостность транзакций в рамках ACID, но и служат основой для репликации и восстановления.

Процесс непрерывного архивирования включает следующие этапы:

Генерация WAL: при выполнении транзакций СУБД записывает изменения в WAL-файлы на локальном диске. Это происходит до того, как данные фиксируются в основных таблицах, что гарантирует возможность восстановления даже при аварийном отключении.
Архивация WAL: настроенный механизм (например, скрипт archive_command в PostgreSQL) автоматически копирует завершённые WAL-файлы в надёжное внешнее хранилище — облачное (AWS S3, Azure Blob Storage, Google Cloud Storage) или локальное (MinIO, NFS).
Хранение и управление: архивные WAL-файлы сохраняются в иерархической или плоской структуре, часто с применением политик жизненного цикла (удаление старых файлов, шифрование, репликация).

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

Point-in-Time Recovery (PITR)

PITR — это метод восстановления базы данных до произвольного момента времени в прошлом, включая конкретную дату, метку транзакции или LSN (Log Sequence Number). Этот механизм позволяет откатить систему к состоянию, предшествующему ошибке (например, случайному удалению таблицы или некорректному обновлению данных).

Процесс PITR состоит из двух компонентов:

Базовый бэкап — полная или инкрементальная копия файлов данных СУБД, полученная с помощью утилит вроде pg_basebackup (PostgreSQL) или mysqldump/Percona XtraBackup (MySQL).
Журналы изменений — последовательность WAL-файлов (или аналогичных логов), начиная с момента создания базового бэкапа и до целевой точки восстановления.

Восстановление выполняется в два этапа:

Рестор базового бэкапа: файлы данных копируются в целевую директорию.
Воспроизведение WAL: СУБД последовательно применяет архивные WAL-файлы до заданного временного ограничения (например, recovery_target_time = '2025-11-05 14:30:00').

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

PITR является неотъемлемой частью стратегий disaster recovery и compliance-аудита, особенно в финансовых, медицинских и государственных системах, где требования к сохранности данных регламентированы на законодательном уровне.

Мониторинг в автоматизированных системах

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

Основные цели мониторинга

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

Виды мониторинга

Системный мониторинг — отслеживание состояния физических и виртуальных узлов: загрузка CPU, потребление памяти, использование дискового пространства, температура и т.п. Этот уровень обеспечивает представление о "здоровье" хоста.
Прикладной мониторинг — контроль работоспособности бизнес-логики: время отклика API, частота ошибок 5xx, успешность транзакций, состояние очередей сообщений. Здесь в центре внимания — пользовательский опыт.
Инфраструктурный мониторинг — наблюдение за компонентами, лежащими между приложением и хостом: базы данных, кэши (Redis, Memcached), брокеры сообщений (Kafka, RabbitMQ), DNS и сетевые сервисы.
Удалённый (synthetic) мониторинг — эмуляция действий пользователя из внешней точки (например, проверка доступности веб-страницы раз в минуту из разных географических регионов). Позволяет выявлять проблемы, невидимые изнутри системы.
Профилирование производительности — глубокий анализ поведения приложения на уровне вызовов функций, распределения памяти, блокировок. Инструменты: PerfView (для .NET), Java Flight Recorder, perf в Linux.

Ключевые метрики мониторинга

Категория	Примеры метрик
Процессор	CPU Load, Idle Time, Context Switches
Память	Memory Usage, Swap Usage, Page Faults
Диск	Disk I/O Operations, Read/Write Latency, Queue Depth
Сеть	Network Traffic, Packet Loss, TCP Retransmits
Приложение	Request Rate, Error Rate, Latency (p50, p95, p99)
Доступность	Uptime, Health Check Status

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

Инструменты мониторинга

Prometheus — система с открытым исходным кодом для сбора и хранения временных рядов (time-series). Использует pull-модель: периодически опрашивает эндпоинты метрик (обычно /metrics в формате текста). Поддерживает мощный язык запросов (PromQL) и интеграцию с десятками экспортеров (Node Exporter, PostgreSQL Exporter и др.).
Grafana — платформа для визуализации метрик из различных источников (Prometheus, InfluxDB, Elasticsearch и др.). Позволяет строить дашборды с графиками, гистограммами, тепловыми картами и алертами.
Zabbix — комплексное решение для мониторинга, сочетающее сбор метрик, логирование событий, сетевой мониторинг и управление алертами. Поддерживает как агентскую, так и агентлесс-модели.
Nagios — один из первых и наиболее известных инструментов для обнаружения сбоев. Ориентирован на проверку доступности сервисов и уведомление при выходе параметров за пороги.
Datadog — коммерческая облачная платформа, объединяющая мониторинг инфраструктуры, приложений, логов и трассировок в единой панели. Особенно популярен в средах с микросервисами и serverless-архитектурами.

Мониторинг в автоматизированной системе должен быть интегрирован с процессами управления инцидентами: алерты — не конечная цель, а триггер для автоматических или ручных действий. В зрелых системах алерты сопровождаются контекстом (связанные метрики, логи, трассировки), что сокращает время Mean Time To Acknowledge (MTTA) и Mean Time To Resolve (MTTR).

Логирование: основа наблюдаемости и диагностики

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

В условиях автоматизации логирование не ограничивается лишь записью в файл. Оно становится элементом распределённой системы наблюдаемости (observability), интегрированной с мониторингом, трассировкой и системами управления инцидентами. Эффективное логирование требует чёткой стратегии: определения типов логов, уровней детализации, форматов, механизмов маршрутизации и политик хранения.

Типы логов

В зависимости от источника и назначения, логи делятся на следующие категории:

Системные логи — генерируются ядром операционной системы или системными демонами. Содержат информацию о загрузке, аппаратных событиях, сетевых подключениях, ошибках драйверов. В Unix-подобных системах такие логи традиционно управляются через syslog или journald (в systemd).
Операционные логи — фиксируют действия пользователей и операторов: вход в систему, выполнение команд, изменение конфигураций. Такие логи критически важны для аудита безопасности и соответствия требованиям регуляторов (GDPR, PCI DSS, HIPAA).
Логи ошибок — содержат диагностическую информацию о сбоях, исключениях, недоступных ресурсах, таймаутах. Включают stack trace, коды ошибок, входные параметры операций. Цель — ускорение локализации и устранения дефектов.
Производственные (business) логи — отражают ключевые бизнес-события: оформление заказа, оплата, изменение статуса заявки. Используются не только для ИТ-диагностики, но и для аналитики, построения воронок конверсии и выявления мошенничества.

В распределённых системах также выделяют трассировочные логи (tracing logs), которые связывают операции, проходящие через несколько сервисов, с помощью уникальных идентификаторов (trace ID, span ID). Это позволяет восстановить полный путь запроса и выявить узкие места.

Уровни логирования

Уровни логирования определяют приоритет и назначение записи. Стандартизированные уровни (в порядке возрастания серьёзности):

DEBUG — детальная техническая информация, полезная исключительно в процессе разработки или глубокой диагностики. В продакшене обычно отключается из соображений производительности и безопасности.
INFO — подтверждение нормального течения процессов: запуск сервиса, обработка запроса, завершение фоновой задачи. Используется для понимания последовательности операций.
WARNING — индикация потенциально проблемной ситуации, не приводящей к сбою: использование устаревшего API, неоптимальный запрос, временное недоступность внешнего сервиса.
ERROR — фиксация ошибки, нарушающей выполнение конкретной операции, но не приводящей к остановке всего приложения (например, сбой валидации входных данных).
CRITICAL (или FATAL) — катастрофическая ошибка, делающая дальнейшую работу компонента невозможной: исчерпание памяти, потеря соединения с основной БД, фатальное исключение.

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

Способы использования логов

Логи служат нескольким ключевым целям:

Отладка и диагностика — восстановление последовательности событий, приведших к сбою, включая входные данные и состояние окружения.
Мониторинг состояния — на основе логов могут строиться метрики (например, частота ошибок 5xx) и триггеры (например, алерт при росте числа WARNING за минуту).
Анализ ошибок — агрегация и классификация исключений для выявления системных проблем, а не единичных сбоев.
Аудит и compliance — подтверждение выполнения операций уполномоченными субъектами, защита от репудиации.
Аналитика пользовательского поведения — при условии анонимизации и соблюдения политики конфиденциальности.

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

Механизмы сбора логов

Сбор логов зависит от платформы и архитектуры приложения:

В JVM-экосистеме используются фреймворки: Logback, Log4j 2, java.util.logging. Они поддерживают гибкую конфигурацию аппендеров (файл, сеть, syslog), фильтрацию по уровням и форматированию в JSON.
В Unix-системах традиционно применяется протокол Syslog (RFC 5424), позволяющий централизованно собирать логи с множества хостов. Современные реализации (rsyslog, syslog-ng) поддерживают TLS, фильтрацию и маршрутизацию.
В облачных средах (Azure, AWS, GCP) рекомендуется использовать нативные сервисы: Azure Application Insights, AWS CloudWatch Logs, Google Cloud Logging, которые интегрируются с другими компонентами платформы.
В контейнеризованных средах (Docker, Kubernetes) логи приложений выводятся в stdout/stderr и перехватываются агентами (Fluentd, Fluent Bit), которые пересылают их в центральное хранилище.

Инструменты хранения и анализа логов

Современные системы логирования строятся по принципу ELT (Extract, Load, Transform): сырые логи отправляются в хранилище, а обработка (парсинг, индексация, агрегация) происходит на стороне аналитической платформы.

Ключевые экосистемы и инструменты:

ELK Stack (Elasticsearch, Logstash, Kibana):
- Logstash — агент для приёма, преобразования и маршрутизации логов.
- Elasticsearch — распределённая поисковая система на основе Lucene, оптимизированная для индексации и поиска по текстовым данным.
- Kibana — веб-интерфейс для визуализации, поиска и построения дашбордов. В последнее время Logstash часто заменяют на Filebeat или Fluentd для снижения потребления ресурсов.
Graylog — альтернатива ELK с более простой архитектурой. Включает встроенный веб-интерфейс, поддержку алертов, управления пользователями и интеграцию с LDAP. Хранит данные в Elasticsearch, но упрощает развёртывание и конфигурацию.
Splunk — коммерческая платформа с мощными возможностями поиска, корреляции событий и машинного обучения. Широко используется в enterprise-средах благодаря гибкости и поддержке compliance.
Grafana Loki — лёгкая альтернатива, разработанная Grafana Labs. Не индексирует полное содержимое логов, а строит индекс только по меткам (labels), что снижает стоимость хранения. Интегрируется с Grafana и Prometheus, формируя единый стек наблюдаемости.
Prometheus + Grafana — хотя изначально предназначены для метрик, могут дополняться логами через экспортеры или интеграцию с Loki.

Выбор инструмента зависит от масштаба системы, требований к задержке, объёма данных, бюджета и необходимости соответствия нормативным актам.

Основы​

1.1. Как работает CI​

1.2. Как организовать CI​

2. Непрерывная доставка и непрерывное развёртывание (Continuous Delivery / Continuous Deployment)​

2.1. Как работает CD​

2.2. Как организовать CD​

3. Среды разработки и эксплуатации: локальная, тестовая, предпродакшен, продуктив​

3.1. Локальная разработка​

3.2. Тестовая среда (test/staging)​

3.3. Предпродакшен (pre-production)​

3.4. Продакшен (production)​

4. Варианты развёртывания: от физических серверов до контейнеров​

4.1. Физические серверы с прямым доступом​

4.2. Виртуальные машины (ВМ)​

4.3. Контейнеризация​

5. Откат и вывод из эксплуатации​

5.1. Откат (rollback)​

5.2. Вывод из эксплуатации (decommissioning)​

Gitflow​

Тонкости CI/CD​

Тонкости CI/CD: от автоматизации сборки до зрелой инженерной культуры доставки​

Эволюция платформ: от TFS к Azure DevOps и концепция ALM​

CI/CD как система проверок, а не просто автоматизация​

Предварительная валидация (pre-merge checks)​

Автоматическое тестирование​

Preflight-чеклист как формализация человеческого контроля​

Модели доставки: от полного ручного контроля к безопасному автоматическому деплою​

Инфраструктура как код (IaC): контроль, валидация и аудит изменений​

Инструменты и подходы​

Управление применением изменений​

Безопасность пайплайнов: от сканирования зависимостей до двойной аутентификации​

Анализ уязвимостей​

Защита рантайм-креденшилов​

Наблюдаемость как основа доверия к автоматизации​

Три столпа наблюдаемости​

Алертинг и действия​

Организационные и документационные практики​

Процесс CI/CD​

Планирование (Planning).​

Разработка (Development).​

Сборка (Build).​

Тестирование (Testing).​

Релиз (Release).​

Развёртывание (Deployment).​

Управление развертыванием (Orchestration & Infrastructure Management).​

Мониторинг и обратная связь (Monitoring & Observability).​

Azure Repos​

Git в работе DevOps​

Инструменты​

1. Инфраструктура как код (Infrastructure as Code, IaC)​

Terraform​

Ansible​

2. CI/CD-системы: ядро автоматизации​

GitLab CI​

GitHub Actions​

Jenkins​

3. Контейнеризация и оркестрация​

4. Мониторинг, логирование и трассировка​

Prometheus​

Grafana​

ELK-стек​

Loki, Tempo, Mimir​

DBSExporter и WAL-G​

5. Безопасность в CI/CD​

WAF​

Сканирование уязвимостей​

Управление хранилищами​

6. Интеграция в единый процесс​

7. Архитектура CI/CD-пайплайна: стадии, артефакты и идемпотентность​

8. Безопасность как неотъемлемая часть пайплайна​

8.1. Статический анализ кода (SAST)​

8.2. Сканирование зависимостей и образов (SCA & Container Scanning)​

8.3. Управление секретами​

9. Модели развёртывания в production​

9.1. Blue/Green Deployment​

9.2. Canary Release​

9.3. Rolling Update​

10. Ограничения и антипаттерны​

11. Роль DevOps-инженера в CI/CD-экосистеме​

12. Сравнение инструментов: выбор в контексте задачи​