Microsoft AZ-400: Управление пакетами и артефактами — Руководство по подготовке

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

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

Обзор

Управление пакетами — это основа для воспроизводимых сборок, надежных развертываний и безопасных цепочек поставок в Azure DevOps. Azure Artifacts централизует хранение пакетов и управление ими в различных экосистемах — NuGet, npm, Maven, Gradle и универсальные пакеты — обеспечивая при этом кеширование из вышестоящих публичных реестров и предоставляя гранулярный контроль для продвижения, хранения и разрешений. В сочетании с автоматизацией семантического версионирования и инструментами для обеспечения безопасности и соответствия требованиям, это позволяет стандартизировать процессы создания, обнаружения, утверждения и использования внутренних и внешних зависимостей в любом масштабе.

Основные концепции Azure Artifacts

Веб-канал (feed) — это единица хранения и контроля доступа для пакетов. Команды обычно организуют веб-каналы по продуктам, платформам или границам доверия (например, один веб-канал для всех публичных OSS-зависимостей через вышестоящие источники, один для общих внутренних библиотек и по одному на каждый продукт). Веб-каналы поддерживают несколько типов пакетов, каждый со своими клиентскими инструментами.

Представления (views) реализуют модель поэтапного продвижения в рамках одного веб-канала:

• local: здесь появляются все только что опубликованные пакеты
• prerelease: используется для предоставления бета-версий/ночных сборок ранним пользователям и конвейерам интеграции
• release: сюда продвигаются только утвержденные для продакшена пакеты для широкого использования Потребители указывают конкретное представление, чтобы автоматически избегать нестабильного контента. Продвигайте или понижайте версии в рамках вашего процесса релиза, чтобы контролировать область воздействия.

Вышестоящие источники (upstream sources) подключают веб-канал к публичным реестрам (NuGet.org, npmjs.com, Maven Central). Когда они включены, разработчики разрешают публичные зависимости через ваш веб-канал. Azure Artifacts прозрачно проксирует и кеширует точные версии, которые используются, повышая надежность, обеспечивая работу в изолированных сценариях и позволяя позже «заморозить» поставки, отключив загрузку новых версий из вышестоящих источников. Вы можете определять, какие вышестоящие источники включены для каждого веб-канала в соответствии с политиками.

Политики хранения (retention) применяются для снижения затрат на хранение, сохраняя при этом только важное. Определите политики для хранения последних N версий каждого пакета, сохранения только версий, продвинутых в представление release, и автоматического удаления старых предварительных версий. Закрепляйте (pin) определенные версии, чтобы исключить их из очистки (например, те, что встроены в долгоживущую ветку продукта). Согласуйте окна хранения с требованиями аудита и отката, чтобы сбалансировать отслеживаемость и затраты на хранение.

Разрешения веб-канала следуют принципу наименьших привилегий:

• Owner (Владелец): управляет настройками веб-канала, разрешениями, представлениями и политиками хранения
• Contributor (Участник): может публиковать, изымать из списка, объявлять устаревшими и продвигать пакеты; не может изменять настройки на уровне веб-канала
• Reader (Читатель): только восстановление/использование; не может изменять пакеты Примечание: «Collaborator» не является ролью в веб-каналах Azure Artifacts. Если вы встретите этот термин, сопоставьте его предполагаемые возможности (часто «может публиковать») с ролью Contributor в Azure Artifacts.

Управление экосистемами пакетов

NuGet (dotnet/C#)

• Версионирование: Предпочитайте SemVer 2.0.0 (например, 1.4.0, 1.4.1-alpha.3+build.45). Метки предварительных версий ограничивают распространение через представления; потребители представления release никогда не столкнутся с вариантами -alpha/-beta.
• Публикация:

undefined

или

undefined

, затем

undefined

или

undefined

в эндпоинт вашего веб-канала. Используйте задачи NuGet в Azure Pipelines и продвигайте в представления prerelease/release при прохождении контроля качества.

• Использование: настройте

undefined

, указав URI источника веб-канала (опционально с привязкой к представлению). Восстанавливайте через

undefined

или задачу NuGet Restore.

• Аутентифицированные веб-каналы: используйте Azure Artifacts Credential Provider (встроен в последние версии dotnet SDK) или задачу конвейера NuGet Authenticate. Для разработчиков — войдите через Visual Studio/Azure CLI; для CI — предоставьте сервисному принципалу сборки права Reader/Contributor по необходимости.

npm (JavaScript/TypeScript)

• Пакеты в области (scoped packages): публикуйте внутренние пакеты в области организации, например,

undefined

. Области естественным образом сопоставляются с разрешениями веб-канала и позволяют ограничивать использование между проектами.

• .npmrc: установите

undefined

,

undefined

и опционально

undefined

для конфигураций с несколькими реестрами. В CI используйте задачу npm Authenticate для внедрения временного токена аутентификации. Для локальной разработки —

undefined

с PAT.

• Приватный реестр: Azure Artifacts выступает в роли приватного npm-реестра с вышестоящим источником в npmjs.com. Используйте пакеты только из представления release, чтобы блокировать неутвержденные предварительные версии.

Maven и Gradle (Java/Kotlin)

• Публикация (Maven): определите

undefined

в

undefined

, указывающий на ваш веб-канал, и запись server в

undefined

с учетными данными (PAT или service connection). Используйте

undefined

или задачу Maven в Azure Pipelines.

• Публикация (Gradle): примените плагин

undefined

и настройте

undefined

, затем опубликуйте с помощью

undefined

.

• Разрешение зависимостей: добавьте эндпоинт вашего веб-канала (опционально с суффиксом представления) в секцию

undefined

в Gradle или

undefined

в

undefined

для Maven. Используйте

undefined

для сборок в разработке и продвигайте релизные версии в представление release для стабильных потребителей.

Универсальные пакеты (бинарные данные, скрипты, модели)

• Версионирование: следуйте стилю SemVer или используйте целочисленные версии; каждая публикация является неизменяемой. Используйте этот тип для артефактов, которые не вписываются в экосистемы конкретных языков.
• Задачи публикации/загрузки: используйте задачи Azure DevOps Universal Publish и Universal Download в конвейерах или Azure CLI (

undefined

). Аутентифицируйтесь через service connection Azure DevOps или вошедшего в систему пользователя.

• Сценарии использования: общие CLI, модули IaC, тестовые данные, ML-модели или межъязыковые ассеты, для которых вам нужны RBAC, политики хранения и продвижение, но не требуются специфичные для языка инструменты.

Контроль безопасности и соответствия требованиям

Сканирование на уязвимости должно выполняться при коммите и во время сборки. Интегрируйте инструменты, которые выявляют зависимости с известными уязвимостями и предоставляют рекомендации по их обновлению. Во многих средах Azure DevOps SonarQube используется как часть стратегии quality gate для выявления проблем, включая правила, обнаруживающие риски в зависимостях; его можно дополнить специализированными SCA-инструментами (например, Snyk, Mend/WhiteSource или Black Duck) для более полного охвата CVE в различных экосистемах. Для .NET дополнительные сигналы могут предоставить команды dotnet list package --vulnerable и для npm — npm audit; для Java в качестве шага сборки можно добавить OWASP Dependency-Check.

Соблюдение лицензионных требований обеспечивается путем сканирования SBOM или манифестов на соответствие утвержденному списку разрешенных лицензий. Black Duck часто добавляют в Azure Pipelines для блокировки сборок при обнаружении запрещенных лицензий. Храните отчеты о сканировании как артефакты конвейера и прикрепляйте их к релизам для возможности аудита.

Разрешенные/заблокированные пакеты лучше всего реализовывать через политики, а не через разовые исключения:

• Ограничьте потребителей представлением релиза (release view); продвигайте только проверенные версии.
• Отключайте загрузку новых пакетов из upstream-источников, когда требуется заморозка, чтобы были доступны только кэшированные версии.
• Используйте области (scopes) npm и разрешения на уровне фида для ограничения пространств имен.
• Добавьте в конвейер проверки, которые будут прерывать сборки при использовании запрещенных пакетов или лицензий, и используйте продвижение артефактов в качестве процесса утверждения.

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

Автоматизация версионирования и экономика хранения

Семантическое версионирование проще всего поддерживать с помощью автоматизации:

• GitVersion считывает вашу историю Git и соглашения об именовании веток для предсказуемого вычисления версий (например, main создает 1.4.0, feature/* создает 1.5.0-feature.3). Настройте режим (Mainline или Continuous Delivery), метки предварительных выпусков (pre-release labels) и источники тегов. Внедряйте вычисленную версию в свойство version файлов csproj, package.json или Gradle перед упаковкой.
• Автоматическое повышение версии может следовать семантике коммитов или меткам PR. Например, chore не повышает версию, feat повышает минорную, fix — патч; breaking-change повышает мажорную. Используйте шаг конвейера для установки buildNumber и передачи версии задачам упаковки/публикации (pack/publish).
• Метки предварительных выпусков должны отражать назначение ветки (например, -alpha для feature-веток, -rc для release-веток). Публикуйте предварительные выпуски в представление prerelease и продвигайте их в release после успешного развертывания на staging.

Управление хранением и затратами требует проактивной политики:

• Автоматическая очистка: настройте политику хранения для каждого фида, чтобы удалять старые, не продвинутые версии через N дней/версий. Увеличьте периоды для критически важных библиотек с длительным сроком поддержки.
• Закрепление (pinning): явно закрепляйте версии, встроенные в продукты с долгим жизненным циклом или используемые в срезах для соответствия требованиям, чтобы исключить их из удаления.
• Оптимизация хранения: предпочитайте кэширование из upstream-источников локальной публикации дубликатов публичных пакетов и по возможности объединяйте фиды для снижения накладных расходов.
• Отслеживайте рост хранилища фида и периодически корректируйте пороговые значения политик.

Особенности upstream-источников:

• NuGet: подключитесь к https://api.nuget.org/v3/index.json в качестве upstream-источника для проксирования и кэширования пакетов с NuGet.org.
• npm: подключитесь к https://registry.npmjs.com, чтобы кэшировать зависимости с npmjs.com через ваш фид с аутентификацией.
• Maven: подключитесь к Maven Central (например, https://repo.maven.apache.org/maven2), чтобы корпоративные потребители получали зависимости через ваш фид по единому URL.

### Сценарий практической задачи

Компании Adobe необходимо стандартизировать управление пакетами в нескольких облаках и для разных языков, одновременно снижая количество сбоев из-за нестабильности публичных реестров и обеспечивая соблюдение политик лицензирования. Команды публикуют внутренние артефакты NuGet, npm и Maven, а также используют общие кросс-языковые инструменты CLI.

1. Создание централизованных каналов и вышестоящих источников (upstreams)

• Действие: Создайте три канала Azure Artifacts: «oss-upstream» (с вышестоящими источниками NuGet.org, npmjs.com, Maven Central), «shared-libs» (внутренние библиотеки) и «productA» (пакеты уровня приложения). Включите представления (views) для всех каналов: local, prerelease, release.
• Обоснование: «oss-upstream» становится единой точкой входа и кэширования; «shared-libs» и «productA» разделяют границы доверия и рабочие процессы продвижения (promotion).

2. Настройка потребления клиентами через представления (views)

• Действие: Направьте nuget.config, .npmrc, репозитории в settings.xml/Gradle на представление release каждого канала для потребителей в среде выполнения (runtime) и на prerelease для конвейеров интеграционного тестирования.
• Обоснование: Представления гарантируют, что только продвинутые и проверенные пакеты попадают к потребителям в производственной среде без изменения конфигураций клиентов.

3. Внедрение публикации с семантическим версионированием

• Действие: Добавьте GitVersion в CI для библиотек и приложений. Настройте внедрение версий в команды dotnet pack, npm version (без тегирования в Git, так как это контролируется конвейером) и в поля версий Gradle/Maven. Публикуйте в представление local; продвигайте в prerelease после успешного CI; автоматически продвигайте в release после тестов в промежуточной среде (staging).
• Обоснование: Детерминированное версионирование, согласованное с Git flow, обеспечивает целостность меток предварительных версий и готовность к автоматизации процессов продвижения.

4. Обеспечение безопасности аутентифицированных каналов и удобства для разработчиков

• Действие: Используйте задачи NuGet Authenticate и npm Authenticate в конвейерах; включите Azure Artifacts Credential Provider на машинах разработчиков; настройте серверы в settings.xml для Maven с использованием PAT (Personal Access Tokens), ротируемых через группы переменных Azure DevOps.
• Обоснование: Бесшовная аутентификация на основе токенов предотвращает распространение учетных данных и поддерживает неинтерактивное восстановление пакетов в CI.

5. Применение политик по уязвимостям и лицензированию

• Действие: Добавьте качественные шлюзы (quality gates) SonarQube в сборки; интегрируйте Black Duck для принудительного использования разрешенных лицензий и блокировки сборок с запрещенными лицензиями или CVE высокой степени серьезности. Для npm и .NET выполняйте npm audit и dotnet list package --vulnerable; публикуйте SBOMs как артефакты сборки.
• Обоснование: Использование нескольких взаимодополняющих сканеров уменьшает «слепые зоны»; Black Duck обеспечивает соблюдение лицензионных требований в масштабе, а SonarQube и инструменты экосистемы помогают выявлять регрессии в безопасности на ранних этапах.

6. Контроль входящего трафика и его заморозка при необходимости

• Действие: Разрешите загрузку из вышестоящих источников только через «oss-upstream»; отключайте новые загрузки из upstreams во время реагирования на инциденты, чтобы заморозить цепочку поставок. Полагайтесь на кэшированные пакеты для поддержания сборок.
• Обоснование: Наличие единой точки контроля (choke point) позволяет быстро сдерживать угрозы в случае компрометации или нестабильности публичного реестра.

7. Применение политик хранения и закрепления (pinning)

• Действие: Храните последние 5 версий для shared-libs и productA; удаляйте не продвинутые версии старше 30 дней; закрепляйте версии, связанные с LTS-ветками и регуляторными базовыми конфигурациями.
• Обоснование: Автоматическая очистка снижает затраты на хранение, в то время как закрепление версий сохраняет возможность аудита и отката.

8. Делегирование доступа по принципу наименьших привилегий

• Действие: Назначьте роль Owners инженерам платформы; Contributors — сопровождающим библиотек, которые должны публиковать/объявлять пакеты устаревшими; Readers — командам продуктов, которые только потребляют артефакты из представления release.
• Обоснование: Согласовывает возможности с обязанностями; разработчики могут снимать пакеты с публикации или объявлять их устаревшими без широких административных прав.

9. Использование универсальных пакетов (Universal packages) для кросс-языковых инструментов

• Действие: Публикуйте внутренние CLI и модули IaC как универсальные пакеты с помощью задач Universal Publish/Download; версионируйте их семантически и продвигайте через представления.
• Обоснование: Обеспечивает RBAC, хранение и продвижение для активов, не привязанных к конкретному языку, с последовательной моделью потребления.

10. Измерение и итеративное улучшение

• Действие: Отслеживайте использование хранилища каналов, процент попаданий в кэш (cache hit rates) и время выполнения продвижения (promotion lead times); соответствующим образом корректируйте пороги хранения, политики для вышестоящих источников и критерии продвижения.
• Обоснование: Постоянная настройка поддерживает надежность, экономическую эффективность и соответствие требованиям по мере роста портфеля продуктов.

← Мониторинг · Все домены · Agile-планирование и управление работой →

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

Просмотреть Microsoft →