Microsoft AZ-400: Конвейеры CI/CD с Azure Pipelines — Руководство по подготовке

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Часть Microsoft DevOps Engineer Expert AZ-400 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Azure Pipelines предоставляет комплексное решение для CI/CD в формате «код» с помощью многоэтапных YAML-конвейеров, которые объединяют сборку, тестирование и выпуск, сохраняя при этом корпоративные механизмы контроля. Владение навыками создания YAML, триггерами, агентами, переменными, шаблонами, заданиями развёртывания, артефактами, кэшированием и подключениями к службам является ключевым для построения масштабируемых, безопасных и воспроизводимых систем доставки.

Создание конвейеров с помощью YAML и шаблонов

YAML-конвейер состоит из этапов (stages), заданий (jobs) и шагов (steps). Этапы моделируют границы жизненного цикла, такие как сборка (Build), тестирование (Test) и выпуск (Release); задания выполняются на агентах и могут работать параллельно; шаги — это задачи или скрипты, выполняемые в рамках задания. Зависимости явно определяются через dependsOn, что позволяет осуществлять тонкую оркестрацию и условное выполнение. Многоэтапные YAML-конвейеры объединяют CI и CD, поддерживают шаблоны «сборки/развёртки» (fan-in/fan-out) и привязывают утверждения к средам, а не к отдельной сущности выпуска.

Шаблоны обеспечивают композицию и повторное использование на разных уровнях детализации:

Шаблоны шагов (Step templates): инкапсулируют последовательность задач (например, настройка инструментов, восстановление, сборка, тестирование) для повторного использования в разных репозиториях.
Шаблоны заданий (Job templates): объединяют шаги с определённой спецификацией агента и стратегией (например, задание с матрицей тестов).
Шаблоны этапов (Stage templates): упаковывают целые этапы, включая утверждения, условия и нацеливание на среду, для обеспечения согласованных процессов продвижения.
Расширяющие шаблоны (Extends templates): обеспечивают наследование конвейеров. Конвейер верхнего уровня через extends ссылается на центральный шаблон, который предписывает обязательные этапы/задания/шаги и управление. Это мощный инструмент для политик на уровне всей организации, гарантирующий, что каждая команда наследует проверки безопасности, соответствия требованиям и соглашения об именовании.

Обработка шаблонов происходит во время компиляции, до выполнения конвейера. Используйте ${{ }} для выражений шаблонов, чтобы изменять структуру конвейера во время компиляции (например, включать определённые задания только для ветки main). Синтаксис макросов $(var) и выражения времени выполнения $[ ] разрешаются во время выполнения, что влияет на доступность секретов и групп переменных. Храните общие шаблоны в центральном репозитории и импортируйте их через resources: repositories; для детерминированных сборок закрепляйте их за определённой веткой или тегом.

Триггеры, агенты, переменные и выражения

Триггеры управляют точками входа для автоматизации:

CI-триггеры запускают конвейер при отправке кода в отслеживаемые ветки. Фильтры путей include и exclude уменьшают количество лишних запусков. Пакетный режим (batch) позволяет объединять несколько отправок кода в один запуск.
PR-триггеры проверяют запросы на слияние (pull requests). Настройте целевые ветки и фильтры путей, а также включите автоматическую отмену устаревших запусков.
Триггеры по расписанию (scheduled) запускаются на основе cron-выражений для поддержки ночных сборок или периодических проверок с контролем часового пояса.
Триггеры конвейеров (pipeline) срабатывают, когда вышестоящий конвейер публикует новый запуск или артефакт. Объявите ресурсы конвейера и добавьте trigger: true с фильтрами веток, чтобы связывать конвейеры между репозиториями или проектами.

Агенты и пулы агентов определяют, где выполняются задания:

Агенты, размещённые в Microsoft (Microsoft-hosted agents), предоставляют эфемерные виртуальные машины на образах ubuntu-latest, windows-latest или macOS с предустановленным набором инструментов. Они идеально подходят для эластичности и минимального обслуживания. Планируйте параллелизм, приобретая параллельные задания, и учитывайте ограничения на «прогрев» кэша.
Локальные агенты (Self-hosted agents) работают на вашей инфраструктуре для использования пользовательских наборов инструментов, доступа к частной сети и предсказуемой производительности. Укрепите безопасность хоста, при необходимости ограничьте исходящий трафик и ротируйте PAT-токен, используемый для регистрации агента. Используйте масштабируемые наборы или контейнеризированные агенты для эластичности.
Пулы агентов логически группируют агенты и используются для делегирования разрешений. Предоставляйте права «Использование» (Use) на пулы на уровне проекта и изолируйте чувствительные рабочие нагрузки с помощью выделенных пулов. Задания указывают пул и, опционально, требования (demands) для выбора агентов с необходимыми возможностями.

Переменные и параметры обеспечивают настраиваемость:

Переменные конвейера — это пары «ключ-значение», доступные задачам как переменные окружения и через макрос $(name). Секретные переменные маскируются в логах и никогда не раскрываются в выражениях шаблонов времени компиляции. Помечайте их как секретные в библиотеке (Library) или в конвейере.
Группы переменных централизуют общие значения и секреты в библиотеке (Library). Свяжите их с Azure Key Vault для получения секретов во время выполнения, что гарантирует, что значения не хранятся в конвейере. Управляйте разрешениями конвейеров, чтобы ограничить, какие из них могут использовать группу.
Параметры времени выполнения определяют строго типизированные входные данные во время постановки в очередь (string, number, boolean, object) и обрабатываются во время компиляции через ${{ parameters.* }} для формирования структуры конвейера (например, для включения/отключения этапов). Предпочитайте параметры, когда нужно изменять структуру конвейера; используйте переменные, когда нужны значения во время выполнения внутри шагов.
Выражения: используйте ${{ }} для логики шаблонов времени компиляции, $(var) для подстановки макросов и $[condition()] для условных операторов времени выполнения в свойствах. Устанавливайте переменные из задач с помощью команд логирования и передавайте выходные данные между заданиями, используя переменные с isOutput.

Развёртывания, среды, стратегии и шлюзы

Задания развёртывания (deployment jobs) предоставляют первоклассную семантику для CD. Задание развёртывания нацелено на среду (environment) и выполняется в соответствии со стратегией, которая управляет выкаткой и хуками жизненного цикла:

Среды (Environments) представляют собой цели развёртывания (например, dev, test, prod) и могут содержать ресурсы, такие как кластеры Kubernetes, виртуальные машины или общие ресурсы типа “none” для платформонезависимых развёртываний. Среды объединяют телеметрию, утверждения и проверки.
Утверждения (Approvals) и проверки (checks) привязываются к средам и подключениям к службам (service connections). Утверждения требуют согласия назначенных лиц перед продолжением развёртывания. Проверки действуют как шлюзы (gates), которые оценивают условия, такие как рабочие часы, наличие обязательных рабочих элементов, сигналы Azure Monitor, вызов REST API или Azure Functions и защита веток. Они предотвращают продвижение развёртывания, если базовые показатели производительности или требования соответствия не удовлетворены.
Стратегии определяют способ выкатки обновлений:
- runOnce применяет изменения одной волной, с хуками preDeploy и postDeploy.
- rolling развёртывает пакетно по экземплярам, с порогами maxParallel и сбоев для безопасного продвижения.
- canary постепенно переключает трафик по частям, с фазами routeTraffic и postRouteTraffic для валидации перед полной выкаткой.
- blue-green (также называется red/black) реализуется путём развёртывания в параллельную среду или слот и переключения трафика на уровне балансировщика нагрузки или через App Service slot swap. Хотя blue-green не является именованной стратегией в YAML, она реализуется через среды, маршрутизацию и задачи переключения (swap tasks) и обеспечивает быстрый откат путём возврата трафика.

Кодируйте логику развёртывания как задание развёртывания (deployment job) для каждого этапа-среды. Используйте проверки сред (environment checks) для создания надёжных шлюзов вместо нерегламентированного опроса через скрипты. Когда требуются секреты, извлекайте их из Azure Key Vault через подключение к службе (service connection), а не встраивайте их в переменные.

Артефакты, кэширование и подключения к службам

Артефакты и кэширование улучшают повторное использование и производительность:

Артефакты конвейера (Pipeline artifacts) — это нативный способ публикации и использования результатов сборки. Используйте PublishPipelineArtifact для публикации именованных артефактов и DownloadPipelineArtifact для их получения из текущего или конкретного запуска. Они оптимизированы для надёжности и обмена между этапами в YAML. При использовании артефактов из другого конвейера объявите ресурс конвейера (pipeline resource) и используйте имя его ресурса-артефакта для точного извлечения.
Универсальные пакеты (Universal packages) обеспечивают версионированное, неизменяемое распространение бинарных файлов через Azure Artifacts для активов, не привязанных к конкретному языку (например, утилиты CLI, файлы данных). Публикуйте и загружайте их с помощью задач Universal Packages, организуйте через представления каналов (feed views, например, prerelease и release) и управляйте хранением в каналах.
Кэширование конвейера (Pipeline caching) ускоряет восстановление зависимостей. Задача Cache использует ключ (key) и путь (path). Ключи должны хэшировать lock-файлы (package-lock.json, Pipfile.lock, packages.lock.json, go.sum), а также версии ОС и инструментов для точной инвалидации. Ключи восстановления (Restore keys) обеспечивают резервные совпадения для частичных попаданий в кэш. Избегайте встраивания секретов в пути кэша, соблюдайте ограничения на размер кэша и отключайте кэширование для временных инструментов, когда lock-файлы нестабильны. Отслеживайте cacheHitVar для ветвления поведения задач.

Подключения к службам (Service connections) определяют идентификационные данные, которые Azure Pipelines использует для доступа к внешним системам:

Типы включают Azure Resource Manager (для подписок и групп ресурсов Azure), GitHub (чтение/запись в репозиторий, отчёты о статусе) и Docker/Container Registry (Docker Hub, ACR). Существуют и другие для AWS, GCP, общих конечных точек служб (generic service endpoints) и реестров пакетов.
Федерация OIDC (workload identity federation) устраняет необходимость в долгоживущих секретах, устанавливая доверие между Azure DevOps и облачными провайдерами идентификации. Для ARM настройте приложение Entra ID с федеративными учётными данными (federated credential), привязанными к издателю Azure DevOps и утверждениям (claims) репозитория/конвейера. Во время выполнения Azure DevOps обменивает кратковременный токен на токен доступа к облаку, что исключает использование секретов субъекта-службы (service principal) и снижает риск утечки учётных данных.
Ограничение области действия и управление критически важны. Ограничивайте область действия подключений ARM принципом наименьших привилегий (в идеале — на уровне группы ресурсов с настраиваемым RBAC). Отключите опцию «Grant access permission to all pipelines» и вместо этого явно авторизуйте конвейеры. Привязывайте утверждения и проверки к подключениям к службам, чтобы требовать ручного рассмотрения или проверки политик перед их использованием.

Классические конвейеры и YAML: сравнение и миграция

В классических конвейерах используется визуальный конструктор с разделением на концепции сборки (Build) и выпуска (Release). Они предлагают создание на основе задач, управление переменными, среды выпуска и шлюзы. Конвейеры YAML предоставляют подход «конвейер как код» (pipeline-as-code), объединение в многоэтапные конвейеры, шаблоны и надёжное версионирование вместе с репозиторием. Функциональный паритет в основном достигнут: утверждения и проверки среды заменяют шлюзы выпуска; задания развертывания моделируют среды; артефакты конвейера заменяют артефакты сборки; а шаблоны и extends реализуют централизованное управление в масштабе. Оставшиеся различия обычно касаются ручных вмешательств через пользовательский интерфейс и некоторых нишевых функций конструктора выпусков, которые в YAML реализуются через задачи Manual Validation и проверки среды.

Прагматичный путь миграции:

Проведите инвентаризацию классических определений сборок и выпусков, задач, переменных, сред, утверждений и шлюзов.
Преобразуйте сборку в YAML с помощью ассистента или экспорта в YAML, затем проведите рефакторинг в шаблоны для повторного использования и удобства поддержки.
Смоделируйте каждую среду выпуска как этап (stage) YAML с заданием развертывания (deployment job), нацеленным на среду (environment). Преобразуйте шлюзы выпуска в утверждения и проверки среды (например, проверки запросов Azure Monitor, проверки запросов рабочих элементов).
Вынесите общие переменные в группы переменных и подключите Key Vault для секретов. Замените секреты субъектов-служб (service principal) на подключения служб (service connections) на основе OIDC.
Замените триггеры по артефактам выпуска на триггеры по ресурсам конвейера. Публикуйте артефакты конвейера на этапе CI и используйте их на этапах CD.
Проверьте паритет, временно запуская оба конвейера, затем переключитесь и выведите из эксплуатации классические определения, подготовив соответствующие планы отката.

Практический сценарий

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

Создание многоэтапного YAML с помощью шаблонов extends

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

Реализация триггеров CI, PR, по расписанию и по конвейеру

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

Использование смешанной стратегии агентов с пулами агентов

Подход: Задания сборки выполняются на агентах ubuntu-latest, размещенных у Microsoft, для эластичности; задания развертывания — на собственных (self-hosted) агентах внутри VNet Starbucks с доступом к внутренним кластерам. Изолировать агенты по пулам для каждой среды и ограничить использование пулов.
Обоснование: Размещенные агенты минимизируют обслуживание для CI; собственные агенты обеспечивают безопасный сетевой доступ для CD. Разделение по пулам обеспечивает принцип наименьших привилегий.

Управление переменными с помощью групп переменных и параметров времени выполнения

Подход: Разместить общие несекретные значения в группах переменных, извлекать секреты из Azure Key Vault через связанные группы переменных и предоставить булев параметр enablePerfGate для включения/отключения шлюзов производительности в ветках, не относящихся к production.
Обоснование: Централизованная конфигурация позволяет избежать дублирования; Key Vault защищает секреты; параметры управляют выбором структуры на этапе компиляции.

Определение заданий развертывания со средами, утверждениями и проверками

Подход: Смоделировать dev, staging и prod как среды. Добавить утверждения для staging и prod. Добавить проверки: рабочие часы для prod и проверку запроса Azure Monitor, которая блокирует продвижение, если задержка в staging превышает базовый уровень.
Обоснование: Утверждения и проверки на уровне среды реализуют контролируемое продвижение и обеспечивают соблюдение SLO перед развертыванием в production.

Применение стратегий canary, а затем blue-green

Подход: Использовать стратегию canary в staging для проверки инкрементов. В production развертывать в параллельный слот/среду и переключать трафик (blue-green/red-black) с возможностью мгновенного отката.
Обоснование: Canary снижает риск во время валидации; blue-green минимизирует время развертывания и обеспечивает самый быстрый откат.

Оптимизация с помощью артефактов конвейера и кэширования

Подход: Публиковать результаты сборки как артефакты конвейера; использовать их на этапах развертывания. Кэшировать восстановление зависимостей, используя ключи, хэшированные по lock-файлу, с restoreKeys для резервного варианта.
Обоснование: Артефакты обеспечивают неизменяемое, отслеживаемое продвижение; кэширование значительно сокращает время сборки без ущерба для корректности.

Защита подключений служб с помощью OIDC и ограниченных разрешений

Подход: Создать подключения служб ARM с использованием федерации удостоверений рабочей нагрузки (workload identity federation) с областью действия на уровне групп ресурсов. Требовать утверждения и проверки для подключений служб и отключить опцию «Grant access to all pipelines».
Обоснование: Устраняет долгоживущие секреты и обеспечивает принцип наименьших привилегий с аудируемыми утверждениями.

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

← Управление исходным кодом и репозиториями · Все домены · Инфраструктура как код и управление конфигурацией →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →