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