Что такое Azure Artifacts?
В этом уроке представлен краткий обзор использования Azure Artifacts для безопасного создания и управления пакетами, применяемыми для приложений.
Давайте проверка обратно с командой, так как они решают, является ли Azure Artifacts подходящим способом размещения пакета .NET.
Мара: Мне кажется, что для нас было бы смысл разместить новый пакет моделей в Azure Artifacts. Мы все уже часть организации Microsoft Azure DevOps, поэтому проверка подлинности будет проще, чем попытка настроить ее в другом диспетчере пакетов.
Энди: Я посмотрел на это перед встречей, и это кажется простым для меня. Я согласен с Марой.
Амита: Что такое артефакты Azure?
Энди. Артефакты Azure — это репозиторий в организации Azure DevOps, где можно управлять зависимостями для базы кода. Azure Artifacts может хранить артефакты и двоичные файлы. Он предоставляет контейнер, который называется веб-канал для групп зависимостей. Разработчики, имеющие доступ к веб-каналу, могут легко использовать или публиковать пакеты.
Как создать пакет и использовать его в конвейере?
Тим. Если я правильно понимаю, код приложения уже использует пакеты из NuGet. Мы собираемся создать собственный пакет и разместить его в Azure Artifacts. Вы можете вырисовать куски и как они будут работать вместе? Мне сложно представить весь процесс.
Энди: Конечно. Давайте подробнее рассмотрим процесс создания пакета и его использования в нашем конвейере Azure DevOps.
Энди переходит на доску.
Создание пакета
Сначала необходимо создать проект в Azure Artifacts. 
Это можно сделать в Azure DevOps.
Затем мы создадим конвейер в Azure Pipelines, который подключается к репозиторию GitHub для кода пакета. Затем конвейер создает код, упаковывает его и отправляет пакет в артефакты Azure. 
Нам нужно обновить приложение, которое использует этот пакет, чтобы указать на созданный веб-канал Артефактов Azure. 
После этого мы обновим конвейер, который создает наше приложение. Это обновление позволяет использовать наш веб-канал артефактов Azure для извлечения новой зависимости пакета и сборки как обычно. 
Обновите пакет .
Тим: Что делать, если кто-то обновляет пакет?
Энди: при обновлении пакета с новым компонентом или исправлением ошибок и выполнением тестов, чтобы убедиться, что он работает правильно, сбой номера версии пакета. Затем зафиксируйте изменение. Конвейер пакета видит фиксацию и создает новый артефакт в Azure Artifacts с новым номером версии. Не волнуйтесь, старый пакет с более низким номером версии по-прежнему существует для приложений, которые зависят от этой версии. Поэтому обычно не следует указывать пакет.
Наше приложение может использовать эту более новую версию пакета. В этом случае мы обновим приложение, чтобы ссылаться на более новую версию и запускать тесты локально, чтобы убедиться, что эта новая версия работает с нашим приложением. Когда мы удовлетворены тем, что все работает, мы отправим приложение в конвейер. Он создает новую версию зависимости пакета.
Амита: Это звучит как хороший план, и это поможет другой команде тоже. Он также будет хранить код от смещения, как вы его поместите. Это упростит контроль качества.
Включение стратегии управления версиями в конвейер сборки
При использовании конвейера сборки пакеты нуждаются в версиях, прежде чем их можно будет использовать и протестировать. Однако только после того, как вы протестировали пакет, вы можете знать его качество. Так как версии пакетов никогда не должны быть изменены, становится сложно выбрать определенную версию заранее.
Артефакты Azure связывают уровень качества с каждым пакетом в веб-каналах и отличаются между предварительной версией и версиями выпуска. Артефакты Azure предлагают различные представления по списку пакетов и их версиям, которые разделяют их на основе их качества. Этот подход хорошо подходит для семантического управления версиями, что полезно для прогнозирования намерения конкретной версии. Azure Artifacts также использует дескриптор для включения дополнительных метаданных из веб-канала Артефактов Azure. Частое использование представлений заключается в совместном использовании версий пакетов, которые были протестированы, проверены или развернуты, но удерживайте пакеты на этапе разработки и не готовы к общедоступному использованию.
Веб-каналы в Azure Artifacts имеют три разных представления по умолчанию. Эти представления добавляются в момент создания нового веб-канала. Три представления:
- Выпуск: представление @release содержит все пакеты, которые считаются официальными выпусками.
- Предварительная версия: представление @prerelease содержит все пакеты с меткой в номере версии.
- Local: представление @local содержит все пакеты выпуска и предварительной версии и пакеты, скачанные из вышестоящий источников.
Вы можете использовать представления, чтобы помочь потребителям веб-канала пакетов фильтровать между выпущенными и неразреченными версиями пакетов. По сути, представления позволяют потребителю принимать сознательное решение выбирать из выпущенных пакетов или выбирать предварительные версии определенного уровня качества.
Безопасность пакетов в артефактах Azure
Обеспечение безопасности пакетов так же важно, как обеспечение безопасности остальной части кода. Одним из аспектов безопасности пакета является защита доступа к веб-каналам пакетов (где веб-канал в Azure Artifacts) — это место хранения пакетов. Настройка разрешений на веб-канал позволяет предоставлять общий доступ к пакетам с большим количеством или несколькими людьми, как требуется для вашего сценария.
Разрешения веб-канала
Веб-каналы имеют четыре уровня доступа: владельцы, участники, сотрудники и читатели. Каждый уровень доступа имеет определенный набор разрешений. Например, владельцы могут добавлять к любому уровню доступа любой тип удостоверения — отдельных лиц, команд и групп. По умолчанию служба сборки коллекции проектов является сотрудником, а ваша команда проекта — читателем.
Настройка конвейера для доступа к оценкам безопасности и лицензий
Существует несколько средств, доступных от сторонних производителей, которые помогут вам оценить рейтинг безопасности и лицензий используемых пакетов программного обеспечения.
Некоторые из этих инструментов сканируют пакеты по мере их включения в конвейер сборки или непрерывного развертывания. Во время процесса сборки средство сканирует пакеты и дает мгновенные отзывы. В процессе CD средство использует артефакты сборки и выполняет сканирование. Два примера таких инструментов: Mend Bolt и Black Duck. С помощью Azure DevOps вы используете задачи сборки для включения сканирования в конвейер.