Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом спринте мы развертываем новую конечную точку API, которая позволяет получить завершенный текст YAML. Мы также рады сообщить о том, что мы добавим возможность настроить вышестоящий источник для универсальных пакетов с этим выпуском.
Дополнительные сведения см. в списке компонентов ниже.
Функции
Azure Boards
- Системные типы рабочих элементов в невыполненных работах и досках
- Событие ведения журнала аудита
- Ограничение репозитория приложений GitHub для Azure Boards (частная предварительная версия)
- Настройка состояния рабочего элемента при слиянии пулл-реквеста (приватное тестирование)
Azure Pipelines (система конвейеров Azure)
- Объявления о изображениях конвейеров
- Улучшена загрузка журналов агентов
- Опционально подключите тома контейнера в режиме только для чтения
- Точное управление запуском и остановкой контейнера
- Распакуйте пакеты задач для каждого шага
- Улучшение безопасности релиза путем ограничения области действия токенов доступа
- Усовершенствования API предварительной версии YAML
Azure Artifacts
- Настройка входящих источников для универсальных пакетов
- Обновление REST API версии пакета теперь доступно для пакетов Maven
Azure Boards
Системные типы рабочих элементов в журналах задач и на досках
Мы запустили закрытый предварительный просмотр функции, которая позволяет добавить тип системного рабочего элемента на выбранный уровень бэклога. Исторически эти типы рабочих элементов доступны только из запросов.
| Процедура | Тип рабочего элемента |
|---|---|
| Гибкий | Проблема |
| Scrum | Препятствие |
| CMMI | Запрос на изменение |
| Проблема | |
| Отзыв | |
| Риск |
Мы рады сообщить о том, что эта функция теперь недоступна для предварительной версии и общедоступна для всех организаций. Добавление типа системного рабочего элемента на уровень невыполненной работы просто. Просто перейдите в пользовательский процесс и перейдите на вкладку "Уровни невыполненной работы". Выберите выбранный уровень невыполненной работы (например, "Невыполненные требования") и выберите вариант редактирования. Затем добавьте тип рабочего элемента.
Событие ведения журнала аудита
Мы добавили новое событие в журналы аудита, чтобы помочь клиентам лучше отслеживать связанные изменения. Событие регистрируется всякий раз, когда значения в списке выбора изменяются. Изменения полей списка выбора обычно являются наиболее распространенными изменениями, внесенными в процесс. С помощью этого нового события администраторы организации могут лучше отслеживать, когда и кто внесли изменения в эти поля.
Лимит репозиториев для приложения GitHub в Azure Boards увеличен (частная предварительная версия)
Если вы используете приложение Azure Boards из GitHub Marketplace, вы можете подключиться к репозиториям GitHub не более 100. Это становится блокировщиком для крупных организаций, которые могут иметь более 100 репозиториев. В этом спринте мы изменили способ подключения Azure Boards к репозиторию GitHub для поддержки более 100. Если вы в настоящее время достигли ограничения на 100 репозиториев, сообщите нам об этом, и мы можем активировать функцию для увеличения этого ограничения и снятия блокировки. Отправьте нам письмо напрямую с именем вашей организации (dev.azure.com/{организация}).
Настройка состояния рабочего элемента при слиянии пулл-реквеста (частная предварительная версия)
Не все рабочие процессы одинаковы. Некоторые заказчики хотят закрыть связанные рабочие элементы при завершении пулл-реквеста. Другие пользователи хотят установить рабочие элементы на другое состояние, которое необходимо проверить перед закрытием. Мы должны предусмотреть оба варианта.
Начиная со спринта 174, у нас есть новая функция, которая позволяет задать рабочие элементы в желаемое состояние, когда pull request объединен и завершен. Для этого мы сканируем описание pull-реквеста и ищем значение состояния, за которым следует упоминание рабочих элементов. В этом примере мы устанавливаем две истории пользователей на "Разрешено" и закрываем две задачи.
Мы долго ждали эту функцию и рады узнать, что вы думаете. Сначала мы просто сканируем описание запроса на вытягивание, не включая в него изменения пользовательского интерфейса. Мы хотели сначала получить свой отзыв, прежде чем инвестировать дальше.
Если вы заинтересованы в участии в частной предварительной версии , отправьте нам письмо напрямую. Не забудьте включить свою организацию (dev.azure.com/{organization}).
Azure Pipelines (система конвейеров Azure)
Объявления об изображениях конвейеров
Замечание
Образы Azure Pipelines постоянно обновляются в целях предоставления пользователям наилучшего опыта. Эти стандартные обновления преимущественно предназначены для решения ошибок или устаревшего программного обеспечения. Они часто не влияют на конвейеры, однако это не всегда так. Ваш конвейер может пострадать, если он зависит от программного обеспечения, которое было удалено или обновлено в образе системы.
Дополнительные сведения о предстоящих обновлениях на образах Windows, Linux и macOS см. в следующих объявлениях:
Чтобы просмотреть заметки о выпуске для предстоящих (предварительных) и внедренных изменений, не забудьте подписаться на следующие заметки о выпуске.
Улучшена загрузка журналов агента
Когда агент перестает взаимодействовать с сервером Azure Pipelines, задание, выполняемое им, перестает работать. Если вы смотрели на журналы потоковых логов консоли, возможно, вы узнали о том, что делал агент прямо перед тем, как он перестал отвечать. Но если вы не были, или если вы обновили страницу, эти журналы консоли исчезли. В этом выпуске, если агент перестает отвечать перед отправкой полных логов, мы будем хранить логи консоли как следующий лучший вариант. Журналы консоли ограничены 1000 символами на строку и иногда могут быть неполными, но они гораздо более полезны, чем отображение ничего! Изучение этих журналов может помочь вам устранить неполадки с собственными конвейерами, и это, безусловно, поможет нашим инженерам поддержки, когда они помогают устранить неполадки.
Опционально подключать тома контейнеров в режиме только для чтения
При запуске задания контейнера в Azure Pipelines несколько томов, содержащих рабочую область, задачи и другие материалы, сопоставляются как тома. Эти тома по умолчанию доступны для чтения и записи. Для повышения безопасности можно подключить тома в режиме только для чтения, изменив спецификацию контейнера в YAML. Каждый ключ в разделе mountReadOnly можно задать как true, чтобы разрешить только чтение (по умолчанию — false).
resources:
containers:
- container: example
image: ubuntu:18.04
mountReadOnly:
externals: true
tasks: true
tools: true
work: false
Детализированный контроль над запуском и остановкой контейнеров
Как правило, мы рекомендуем разрешить Azure Pipelines управлять жизненным циклом ваших заданий и контейнеров служб. Однако в некоторых редких ситуациях вы можете начать и остановить их самостоятельно. В этом выпуске мы встроили эту возможность в задачу Docker.
Ниже приведен пример конвейера с помощью новой возможности:
resources:
containers:
- container: builder
image: ubuntu:18.04
steps:
- script: echo "I can run inside the container (it starts by default)"
target:
container: builder
- task: Docker@2
inputs:
command: stop
container: builder
# if any step tried to run in the container here, it would fail
Кроме того, мы добавим список контейнеров в переменную Agent.ContainerMappingконвейера. Это можно использовать, если вы хотите проверить список контейнеров в скрипте, например. Он содержит строковое сопоставление объекта JSON с именем ресурса ("builder" из приведенного выше примера) с идентификатором контейнера, которым управляет агент.
Распаковка рабочих пакетов для каждого шага
При запуске задания агент сначала скачивает все пакеты задач, необходимые для выполнения задания. Как правило, в целях повышения производительности он разархивирует задачи один раз на задание, даже если задача используется на нескольких этапах. Если у вас возникли опасения, что ненадежный код может изменять распакованное содержимое, вы можете пожертвовать небольшой частью производительности, поручив агенту распаковывать задачу при каждом использовании. Чтобы включить этот режим, передайте --alwaysextracttask при настройке агента.
Повышение безопасности релиза за счет ограничения области токенов доступа
Продолжая развивать нашу инициативу по усилению настроек безопасности для Azure Pipelines, теперь мы поддерживаем ограничение области действия токенов доступа для выпусков.
Каждое задание, выполняемое в релизах, получает маркер доступа. Токен доступа используется задачами и вашими скриптами для выполнения обратных вызовов в Azure DevOps. Например, мы используем маркер доступа для получения исходного кода, скачивания артефактов, отправки журналов, результатов тестирования или выполнения вызовов REST в Azure DevOps. Новый маркер доступа создается для каждого задания и истекает после завершения задания.
С этим обновлением мы продолжаем усиливать безопасность конвейера, ограничивая область действия маркеров доступа, и применяем эти меры также к классическим выпускам.
Эта функция будет включена по умолчанию для новых проектов и организаций. Для существующих организаций его необходимо включить в параметрах конвейеров >> параметров организации. > Ограничить область авторизации задания текущим проектом для конвейеров выпуска. Подробнее см. здесь.
Улучшения API для предварительной версии YAML
Несколько спринтов назад мы представили возможность предварительного просмотра полного YAML конвейера без его запуска. С помощью этого обновления мы создали выделенный URL-адрес для возможности предварительной версии. Теперь можно отправить POST на https://dev.azure.com/{org}/{project}/_apis/pipelines/{pipelineId}/preview, чтобы получить финализированное тело YAML. Этот новый API принимает те же параметры, что и очередь выполнения, но больше не требует разрешения "Очередь сборок".
Azure Artifacts
Настройка вышестоящих источников для Universal Packages
Теперь вы можете настроить веб-каналы Azure Artifacts для автоматического скачивания универсальных пакетов из вышестоящих источников по запросу.
Ранее можно настроить вышестоящий источник в веб-канале для пакетов NuGet, Python, Maven и npm, но не для универсальных пакетов. Это связано с разницей в технологии хранения, используемой для универсальных пакетов, которая поддерживает гораздо больше пакетов, чем другие поддерживаемые типы пакетов.
Теперь можно настроить вышестоящие источники для Universal Packages так же, как и для других типов пакетов; откройте настройки канала, щелкните Вышестоящие источники ->Добавить вышестоящий источник -> и выберите подходящий для вас тип источника. В следующем представлении вы увидите универсальные пакеты (UPack) как новый вариант (см. рисунок ниже). Дополнительные сведения см. в документации по конфигурации вышестоящих источников.
Обратите внимание, что универсальные пакеты в исходных источниках поддерживаются только между каналами в организации DevOps.
Обновление версии пакета через REST API теперь доступно для пакетов Maven
Теперь для обновления версий пакетов Maven можно использовать REST API "Обновление версии пакета" Azure Artifacts. Ранее можно использовать REST API для обновления версий пакетов для NuGet, Maven, npm и универсальных пакетов, но не для пакетов Maven.
Чтобы обновить пакеты Maven, используйте следующую команду HTTP PATCH.
PATCH
https://pkgs.dev.azure.com/{organization}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1
Можно задать следующее:
Параметры URI
| Имя | В | Required | Тип | Описание |
|---|---|---|---|---|
| artifactId | путь | TRUE | струна | Идентификатор артефакта пакета |
| корм | путь | TRUE | струна | Имя или идентификатор канала |
| groupId | путь | TRUE | струна | Идентификатор группы пакета |
| организация | путь | TRUE | струна | Имя организации Azure DevOps |
| version | путь | TRUE | струна | Версия пакета |
| project | путь | струна | Идентификатор проекта или имя проекта | |
| версия API | query | TRUE | струна | Используемая версия API. Для использования этой версии API необходимо задать значение 5.1-preview.1. |
Текст запроса
| Имя | Тип | Описание |
|---|---|---|
| views | JsonPatchOperation | Представление, к которому будет добавлена версия пакета |
Дополнительную информацию см. в документации по REST API, которая обновляется.
Дальнейшие шаги
Замечание
Эти функции будут развернуты в течение следующих двух-трех недель.
Перейдите к Azure DevOps и посмотрите.
Как предоставить отзыв
Мы хотели бы услышать то, что вы думаете об этих функциях. Используйте меню справки, чтобы сообщить о проблеме или указать предложение.
Вы также можете получить советы и ответы на ваши вопросы от сообщества на Stack Overflow.
Спасибо,
Аарон Холлберг