Заметки о выпуске Azure DevOpsServer 2020 с обновлением 1

Статья
03/12/2024

| Сообщество разработчиков Системные требования | Условия лицензии DevOps | Блог | SHA-1 Хэши SHA-1

В этой статье вы найдете сведения о новейшем выпуске для Azure DevOps Server.

Дополнительные сведения об установке или обновлении развертывания Azure DevOps Server см. в разделе Требования Azure DevOps Server. Чтобы скачать продукты Azure DevOps, перейдите на страницу загрузки Azure DevOps Server.

Прямое обновление до Azure DevOps Server 2020 поддерживается с Azure DevOps Server 2019 года или Team Foundation Server 2015 или более поздней версии. Если развертывание TFS находится в TFS 2010 или более ранней версии, необходимо выполнить некоторые промежуточные действия перед обновлением до Azure DevOps Server 2019. Дополнительные сведения см. в статье Установка и настройка Azure DevOps в локальной среде.

Безопасное обновление с Azure DevOps Server 2019 до Azure DevOps Server 2020 г.

Azure DevOps Server 2020 г. вводит новую модель хранения запуска конвейера (сборки), которая работает на основе параметров уровня проекта.

Azure DevOps Server 2020 года обрабатывает хранение сборки по-разному в зависимости от политик хранения на уровне конвейера. Некоторые конфигурации политики приводят к удалению запусков конвейера после обновления. Запуски конвейера, которые были сохранены вручную или сохранены в выпуске, не будут удалены после обновления.

Дополнительные сведения о безопасном обновлении с Azure DevOps Server 2019 года до Azure DevOps Server 2020 годах см. в нашей записи блога.

Azure DevOps Server 2020 г. обновление 1.2. Обновление 13 Дата выпуска: 12 марта 2024 г.

File	Хэш SHA-256
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

Мы выпустили исправление 13 для Azure DevOps Server 2020 с обновлением 1.2, которое включает исправления для следующих компонентов:

Устранена проблема, из-за которой прокси-сервер переставал работать после установки исправления 12.

Azure DevOps Server 2020 г. обновление 1.2. Обновление 12 Дата выпуска: 13 февраля 2024 г.

File	Хэш SHA-256
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

Мы выпустили исправление 12 для Azure DevOps Server 2020 с обновлением 1.2, которое содержит исправления для следующих компонентов:

Исправлена ошибка, из-за которой дисковое пространство, используемое папкой кэша прокси-сервера, вычислялось неправильно, а папка не была очищена должным образом.
CVE-2024-20667: Azure DevOps Server уязвимость к удаленному выполнению кода.

Azure DevOps Server 2020 г. обновление 1.2. Обновление 11 Дата выпуска: 12 декабря 2023 г.

File	Хэш SHA-256
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

Мы выпустили исправление 11 для Azure DevOps Server 2020 с обновлением 1.2, которое содержит исправления для следующих компонентов:

Исправлена ошибка, из-за которой наследование безопасности перед утверждением развертывания не работало на этапах конвейеров.

Azure DevOps Server 2020 г. обновление 1.2. Обновление 10 Дата выпуска: 14 ноября 2023 г.

Мы выпустили исправление для Azure DevOps Server 2020 с обновлением 1.2, включающее исправления для следующих компонентов.

Расширен список разрешенных символов задач PowerShell для проверки параметров Аргументы задач оболочки.

Примечание

Чтобы реализовать исправления для этого исправления, необходимо выполнить ряд действий по обновлению задач вручную.

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

Важно!

Мы выпустили обновления для агента Azure Pipelines с исправлением 8, выпущенным 12 сентября 2023 г. Если вы не установили обновления агента, как описано в заметках о выпуске для исправления 8, мы рекомендуем установить эти обновления перед установкой исправления 10. Новая версия агента после установки исправления 8 будет 3.225.0.

Настройка TFX

Выполните действия, описанные в документации по отправке задач в коллекцию проектов , чтобы установить и войти с помощью tfx-cli.

Обновление задач с помощью TFX

File	Хэш SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

Скачайте и извлеките Tasks20231103.zip.
Измените каталог на извлеченные файлы.
Выполните следующие команды, чтобы отправить задачи:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip

Требования к конвейеру

Чтобы использовать новое поведение, переменная AZP_75787_ENABLE_NEW_LOGIC = true должна быть задана в конвейерах, использующих затронутые задачи.

В классической версии:

Определите переменную на вкладке переменных в конвейере.
Пример YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true

Azure DevOps Server 2020 г. обновление 1.2. Обновление 9 Дата выпуска: 10 октября 2023 г.

Важно!

Мы выпустили обновления для агента Azure Pipelines с исправлением 8, выпущенным 12 сентября 2023 г. Если вы не установили обновления агента, как описано в заметках о выпуске для исправления 8, рекомендуется установить эти обновления перед установкой исправления 9. Новая версия агента после установки исправления 8 будет 3.225.0.

Мы выпустили исправление. для Azure DevOps Server 2020 обновление 1.2, включающее исправления для следующих компонентов.

Исправлена ошибка, из-за которой удостоверение "Владелец анализа" отображалось как неактивное удостоверение на компьютерах с обновлением исправлений.

Azure DevOps Server 2020 г. обновление 1.2. Обновление 8 Дата выпуска: 12 сентября 2023 г.

CVE-2023-33136: Azure DevOps Server уязвимость к удаленному выполнению кода.
CVE-2023-38155: уязвимость Azure DevOps Server и Team Foundation Server, связанная с повышением привилегий.

Важно!

Перед применением исправления в рабочей среде разверните исправление в тестовой среде и убедитесь, что конвейеры среды работают должным образом.

Примечание

Чтобы реализовать исправления для этого исправления, необходимо выполнить ряд действий по обновлению агента и задач вручную.

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

Скачайте и установите Azure DevOps Server 2020 с обновлением 1.2 с обновлением 8.

Обновление агента Azure Pipelines

Скачайте агент по ссылке — https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 Agent_20230825.zip
Выполните действия, описанные в документации по локальным агентам Windows , чтобы развернуть агент.

Примечание

Для AZP_AGENT_DOWNGRADE_DISABLED должно быть задано значение true, чтобы предотвратить понижение уровня агента. В Windows следующую команду можно использовать в командной строке администрирования, за которой следует перезагрузка. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Настройка TFX

Выполните действия, описанные в документации по отправке задач в коллекцию проектов , чтобы установить и войти с помощью tfx-cli.

Обновление задач с помощью TFX

Скачайте и извлеките Tasks_20230825.zip.
Измените каталог на извлеченные файлы.
Выполните следующие команды, чтобы отправить задачи:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip

Требования к конвейеру

В классической версии:

Определите переменную на вкладке переменных в конвейере.
Пример YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true

Azure DevOps Server 2020 г. обновление 1.2. Обновление 7 Дата выпуска: 8 августа 2023 г.

CVE-2023-36869: уязвимость Azure DevOps Server спуфингом.
Обновите службу SSH для поддержки SHA2-256 и SHA2-512. Если у вас есть SSH-файлы конфигурации, жестко закодированные для использования RSA, следует выполнить обновление до SHA2 или удалить запись.
Устранена проблема, из-за того что относительные ссылки не работали в файлах Markdown.
Исправлена ошибка с навигацией по комментариям на странице фиксации.
Исправлена ошибка, при которой удостоверение владельца анализа отображается как неактивное удостоверение.
Исправлена ошибка бесконечного цикла в CronScheduleJobExtension.

Azure DevOps Server 2020 г., обновление 1.2, обновление 6 Дата выпуска: 13 июня 2023 г.

CVE-2023-21565: уязвимость Azure DevOps Server спуфингом.
CVE-2023-21569: уязвимость Azure DevOps Server спуфингом.
Исправлена ошибка, которая мешала отправке пакетов при обновлении с версии 2018 или более ранней версии.
Исправлена ошибка, из-за которой сбой отсоединения или присоединения коллекции сообщала о следующей ошибке: "TF246018: операция базы данных превысила ограничение времени ожидания и была отменена.

Azure DevOps Server 2020 г. Обновление 1.2. Дата выпуска обновления 5: 14 февраля 2023 г.

CVE-2023-21553: уязвимость Azure DevOps Server удаленного выполнения кода
Исправлена проблема со специальными возможностями наборов полок через веб-интерфейс
Клиентам необходимо перезапустить службу tfsjobagent и Azure DevOps Server пул приложений после обновления параметра, связанного с SMTP, в консоли управления Azure DevOps Server.

Azure DevOps Server 2020 г. Обновление 1.2. Обновление 4 Дата выпуска: 13 декабря 2022 г.

Исправлено отображение специальных символов в IdentityPicker.

GIF для демонстрации специальных символов в IndetityPicker.

Тестовые данные не удаляются, что приводит к росту базы данных. С помощью этого исправления мы обновили хранение сборки, чтобы предотвратить создание новых потерянных тестовых данных.

Azure DevOps Server 2020 г. Обновление 1.2. Дата выпуска обновления 3: 18 октября 2022 г.

Устранена проблема, связанная с тем, что добавленные удостоверения AD не отображаются в средстве выбора удостоверений в диалоговом окне безопасности.
Исправлена проблема с фильтром Запрошено участником группы в параметрах веб-перехватчика.
Исправлена ошибка сборки с проверка шлюзом, когда в параметрах организации для конвейера область авторизации задания задано значение Ограничить авторизацию задания область текущим проектом для конвейеров, не относящихся к выпуску.
Исправление получения маркера доступа из Azure при установке подключения к службе за прокси-сервером, прошедшим проверку подлинности.

Azure DevOps Server 2020 г. Обновление 1.2 Дата выпуска обновления 2: 9 августа 2022 г.

Исправлена ошибка значения удостоверения при назначении рабочего элемента удостоверению, которое отображается в разных доменах.

Azure DevOps Server 2020 г. Обновление 1.2 Дата выпуска обновления 1: 12 июля 2022 г.

В API тестовых запусков возвращаемый маркер продолжения был больше указанного значения maxLastUpdatedDate.

Azure DevOps Server 2020 с обновлением 1.2 Дата выпуска: 17 мая 2022 г.

Azure DevOps Server 2020 с обновлением 1.2 — это сводка исправлений ошибок. Вы можете напрямую установить Azure DevOps Server 2020 с обновлением 1.2 или с Azure DevOps Server 2020 или Team Foundation Server 2013 или более поздней версии.

Примечание

Средство переноса данных будет доступно для Azure DevOps Server 2020 с обновлением 1.2 примерно через три недели после этого выпуска. Список поддерживаемых сейчас версий для импорта см. здесь.

Этот выпуск включает в себя исправления для следующих компонентов:

Azure DevOps Server 2020.1.2 отключает новую модель хранения (появилась в Azure DevOps Server 2020 г.), чтобы предотвратить потерю выполнения конвейера (сборки). Это означает, что система будет:
- Создание аренды для последних 3 сборок, созданных при запуске Server 2020
- Для конвейеров YAML и классических конвейеров без политик хранения для каждого конвейера сборки будут храниться в соответствии с максимальными параметрами хранения на уровне коллекции.
- Для классических конвейеров с настраиваемыми политиками хранения для каждого конвейера сборки будут храниться в соответствии с политикой хранения для конкретного конвейера.
- Сборки с арендой не учитываются в минимальном значении для сохранения.
Ссылки на комментарии к набору изменений и набору локлок не были перенаправлены должным образом. При добавлении комментариев к файлам в наборах изменений или наборе параметров при выборе этих комментариев не происходит перенаправление в нужное место в представлении файлов.
Не удается пропустить очередь сборки с помощью кнопки "Выполнить далее". Ранее кнопка "Выполнить далее" была включена только для администраторов коллекции проектов.
Отмените все личные маркеры доступа после отключения учетной записи Пользователя Active Directory.

Azure DevOps Server 2020.1.1 Дата выпуска исправления 4: 26 января 2022 г.

Мы выпустили исправление для Azure DevOps Server 2020.1.1, включающее исправления для следующих компонентов.

Email уведомления не были отправлены при использовании @mention элемента управления в рабочем элементе.
В профиле пользователя не обновлялся предпочитаемый адрес электронной почты. Вследствие этого сообщения отправлялись на предыдущий адрес.
Заголовок не отображается на странице Сводка проекта. Заголовок отображался в течение нескольких миллисекунд, а затем исчез.
Улучшение синхронизации пользователей Active Directory.
Устранена уязвимость Elasticsearch за счет удаления класса JndiLookup из двоичных файлов Log4j.

Шаги установки

Обновите сервер с помощью исправления 4.
Проверьте значение реестра по адресу HKLM:\Software\Elasticsearch\Version. Если оно отсутствует, добавьте строковое значение и задайте Version со значением 5.4.1 (Имя = Version, Значение = 5.4.1).
Выполните команду обновления PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update, приведенную в файле сведений. Она может возвращать предупреждение вида Невозможно соединиться с удаленным сервером. Не закрывайте окно, так как обновление будет повторять попытку, пока не сработает.

Примечание

Если Azure DevOps Server и Elasticsearch установлены на разных компьютерах, выполните описанные ниже действия.

Обновите сервер с помощью исправления 4.
Проверьте значение реестра по адресу HKLM:\Software\Elasticsearch\Version. Если оно отсутствует, добавьте строковое значение и задайте Version со значением 5.4.1 (Имя = Version, Значение = 5.4.1).
Скопируйте содержимое папки с именем ZIP, расположенной в C:\Program Files\{TFS Version Folder}\Search\zip папке удаленных файлов Elasticsearch.
Запустите Configure-TFSSearch.ps1 -Operation update на компьютере сервера Elasticsearch.

Хэш SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 Дата выпуска исправления 3: 15 декабря 2021 г.

Исправление 3 для Azure DevOps Server 2020.1.1 включает исправления для следующих компонентов.

Исправлен макрос рабочего элемента для запросов с параметром "Содержит слова". Ранее запросы возвращали неверные результаты для значений, содержащих разрыв строки.
Увеличьте ограничения на длину символов версии пакета Maven.
Проблема локализации для состояний макета пользовательских рабочих элементов.
Проблема локализации в шаблоне уведомлений по электронной почте.
Проблема с оценкой правил NOTSAMEAS, когда для поля было определено несколько правил NOTSAMEAS.

Azure DevOps Server 2020.1.1 Дата выпуска исправления 2: 26 октября 2021 г.

Исправление 2 для Azure DevOps Server 2020.1.1 включает исправления для следующих компонентов.

Ранее Azure DevOps Server могли создавать подключения только к GitHub Enterprise Server. С помощью этого исправления администраторы проекта могут создавать подключения между Azure DevOps Server и репозиториями на GitHub.com. Этот параметр можно найти на странице подключений GitHub в разделе Параметры проекта.
Устранение проблемы с мини-приложением "План тестирования". В отчете о выполнении теста отображался неправильный пользователь в результатах.
Исправлена проблема с ней при загрузке страницы сводки "Обзор проекта".
Исправлена проблема, из-за которой сообщения электронной почты не отправлялись для подтверждения обновления продукта.

Azure DevOps Server 2020.1.1 Дата выпуска исправления 1: 14 сентября 2021 г.

Исправление 1 для Azure DevOps Server 2020.1.1 включает исправления для следующих компонентов.

Исправлена ошибка загрузки и отправки артефактов.
Устранение проблемы с несогласованными данными результатов тестирования.

Azure DevOps Server 2020 г. обновление 1.1 Дата выпуска: 17 августа 2021 г.

Azure DevOps Server 2020 обновление 1.1 — это сводный пакет исправлений ошибок. Вы можете напрямую установить Azure DevOps Server 2020 с обновлением 1.1 или с Azure DevOps Server 2020 или Team Foundation Server 2013 или более поздней версии.

Примечание

Средство миграции данных будет доступно для Azure DevOps Server 2020 с обновлением 1.1 примерно через три недели после этого выпуска. Список поддерживаемых сейчас версий для импорта см. здесь.

Этот выпуск включает в себя следующие исправления.

Azure Boards

Гиперссылка "Просмотр рабочего элемента" в уведомлениях электронной почты не использует общедоступный URL-адрес.

Azure Repos

Исправлены флажки наследования ограниченных типов слияния, позволяющие включить изменение типов слияния с ограничением после настройки политик перекрестной репозитории.

Azure Pipelines

При изменении параметра Обновления агента параметры не распространялись на другие уровни приложений в среде.

Общее

Исправлена орфография в мастере настройки сервера.
Увеличение размера пакета расширения и изменение размера в реестре.

Планы тестирования Azure

Не удается вернуться к результатам теста после перехода из журнала на страницу сводки.

Azure DevOps Server 2020.1. Обновление 2 Дата выпуска: 10 августа 2021 г.

Мы выпустили исправление для Azure DevOps Server 2020.1, которое исправляет следующее.

Исправлена ошибка пользовательского интерфейса определения сборки.
Изменен журнал браузера для отображения файлов вместо корневого репозитория.

Azure DevOps Server 2020.1. Обновление 1 Дата выпуска: 15 июня 2021 г.

Мы выпустили исправление для Azure DevOps Server 2020.1, которое исправляет следующее.

Безопасные файлы cookie, используемые в потоках авторизации, которые утверждают SameSite=None.
Устранение проблемы с пакетом SDK для уведомлений. Ранее подписки на уведомления, использующие фильтр "Путь к области", анализировались неправильно.

Azure DevOps Server 2020.1 RTW Дата выпуска: 25 мая 2021 г.

Сводка о новых возможностях в Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW представляет собой свод исправлений ошибок. Он включает все функции из ранее выпущенного Azure DevOps Server 2020.1 RC2. Azure DevOps Server 2020.1 RTW представляет собой свод исправлений ошибок. Вы можете напрямую установить Azure DevOps Server 2020.1 или обновить Azure DevOps Server 2020, 2019 или Team Foundation Server 2015 или более поздней версии.

Примечание

Средство миграции данных будет доступно в Azure DevOps Server 2020 с обновлением 1 примерно через три недели после этого выпуска. Список поддерживаемых сейчас версий для импорта см. здесь.

Azure DevOps Server 2020.1 RC2 Дата выпуска: 13 апреля 2021 г.

Сводка о новых возможностях в Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC2 — это свод исправлений ошибок. Он включает все функции из ранее выпущенного Azure DevOps Server 2020.1 RC1.

Azure DevOps Server 2020.1 RC1 Дата выпуска: 23 марта 2021 г.

Сводка о новых возможностях в Azure DevOps Server 2020.1 RC1

Azure DevOps Server 2020.1 RC1 предоставляет множество новых функций. Вот некоторые из них:

Правила ограничения перехода состояния в Boards
Заинтересованные лица теперь могут перемещать рабочие элементы по столбцам доски
Повышение безопасности выпуска путем ограничения область маркеров доступа
Расширенный интерфейс запроса на вытягивание
Триггеры с несколькими репозиториями в конвейерах

Вы также можете перейти к отдельным разделам, чтобы просмотреть все новые функции для каждой службы:

Boards
Repos
Конвейеры
Артефакты

Boards

Правила ограничения перехода состояния

Мы по-прежнему закрываем разрыв четности признаков между размещенным XML и наследуемой моделью процесса. Это новое правило типа рабочих элементов позволяет ограничить перемещение рабочих элементов из одного состояния в другое. Например, вы можете ограничить переход ошибок с "Создать" на "Устранено". Вместо этого они должны перейти из раздела Создать —> Активный —> Разрешено.

Можно также создать правило для ограничения переходов состояния по членству в группах. Например, только пользователи в группе "Утверждающие" могут перемещать пользовательские истории из "Создать -> Утверждено".

Копирование рабочего элемента для копирования дочерних элементов

Одной из наиболее востребованных функций для Azure Boards является возможность копирования рабочего элемента, который также копирует дочерние рабочие элементы. Мы добавили новый параметр "Включить дочерние рабочие элементы" в диалоговое окно копирования рабочего элемента. Если этот параметр установлен, будет скопирован рабочий элемент и все дочерние рабочие элементы (до 100).

На этой странице показан новый параметр в Azure Boards включить дочерние рабочие элементы в скопированный рабочий элемент.

Улучшенные правила для активированных и разрешенных полей

До сих пор правила для активированных by, даты активации, разрешенных и разрешенных дат были загадкой. Они задаются только для системных типов рабочих элементов и зависят от значений состояния "Активный" и "Разрешено". Мы изменили логику, чтобы эти правила больше не были предназначены для определенного состояния. Вместо этого они активируются категорией (категорией состояния), в которой находится состояние. Например, предположим, что у вас есть пользовательское состояние "Требуется тестирование" в категории Разрешено. При изменении рабочего элемента с "Активный" на "Требуется тестирование", активируются правила разрешеннойдаты и даты разрешения.

Это позволяет клиентам создавать любые пользовательские значения состояния и по-прежнему создавать поля Активировано, Дата активации, Разрешенная дата и Дата разрешения без использования настраиваемых правил.

Заинтересованные лица могут перемещать рабочие элементы по столбцам доски

Заинтересованные лица всегда могли изменить состояние рабочих элементов. Но когда они переходят к канбан-доске, они не могут перемещать рабочие элементы из одного столбца в другой. Вместо этого заинтересованным лицам придется открывать каждый рабочий элемент по одному и обновлять значение состояния. Это уже давно является болезненным моментом для клиентов, и мы рады сообщить, что теперь вы можете перемещать рабочие элементы по столбцам доски.

Системные типы рабочих элементов на невыполненных работах и досках

Теперь можно добавить системный тип рабочего элемента на выбранный уровень невыполненной работы. Исторически эти типы рабочих элементов были доступны только в запросах.

Процесс	Тип рабочего элемента
Гибкая методика	Проблема
Scrum	Препятствие
CMMI	Запрос на изменение
	Проблема
	Просмотр
	Риск

Добавить системный тип рабочего элемента на уровень невыполненной работы очень просто. Просто перейдите в пользовательский процесс и откройте вкладку Уровни невыполненной работы. Выберите выбранный уровень невыполненной работы (например, "Невыполненная работа по требованиям") и выберите вариант редактирования. Затем добавьте тип рабочего элемента.

Azure Boards увеличенное ограничение репозитория приложений GitHub

Ограничение репозитория для приложения Azure Boards в GitHub Marketplace увеличено с 100 до 250.

Настройка состояния рабочего элемента при слиянии запроса на вытягивание

Не все рабочие процессы одинаковы. Некоторые клиенты хотят закрыть связанные рабочие элементы после завершения запроса на вытягивание. Другие хотят задать для рабочих элементов другое состояние для проверки перед закрытием. Мы должны позволить и то, и другое.

У нас появилась новая функция, которая позволяет задать для рабочих элементов требуемое состояние при слиянии и завершении запроса на вытягивание. Для этого мы сканируем описание запроса на вытягивание и ищем значение состояния, за которым следует #упоминание рабочих элементов. В этом примере мы устанавливаем для двух пользовательских историй значение Разрешено и закрываем две задачи.

Связывание рабочего элемента со сборками в другом проекте

Теперь вы можете легко отслеживать зависимости сборки в проекте, просто связав рабочий элемент со сборкой, найденной в сборке или интегрированной в сборке.

связывание рабочих элементов

Изменение описания (текста справки) в системных полях

Вы всегда могли изменить описание настраиваемых полей. Но для системных полей, таких как приоритет, серьезность и активность, описание было невозможно изменить. Это был разрыв между размещенным XML и унаследованным, который не позволял некоторым клиентам переходить на наследуемую модель. Теперь вы можете изменить описание в системных полях. Измененное значение влияет только на это поле в процессе и для этого типа рабочего элемента. Это обеспечивает гибкость при наличии разных описаний для одного поля для разных типов рабочих элементов.

изменить описание

Настройка состояния рабочего элемента при слиянии запроса на вытягивание

Запросы на вытягивание часто относятся к нескольким рабочим элементам. При создании или обновлении запроса на вытягивание может потребоваться закрыть некоторые из них, разрешить некоторые из них и сохранить остальные открытыми. Теперь для этого можно использовать комментарии, как показано на рисунке ниже. Дополнительные сведения см. в документации.

Родительское поле на доске задач

В связи с популярным запросом теперь можно добавить поле Родитель в карточки дочернего и родительского элементов на доске задач.

Удаление правила "Назначено" для типа рабочего элемента ошибки

Существует несколько скрытых системных правил для всех типов рабочих элементов в Agile, Scrum и CMMI. Эти правила существуют уже более десяти лет и, как правило, работают нормально без каких-либо жалоб. Тем не менее, есть несколько правил, которые иссякли их приветствия. Одно правило, в частности, вызвало много боли для новых и существующих клиентов, и мы решили, что пора удалить его. Это правило существует для типа рабочего элемента Ошибка в гибком процессе.

"Задайте для параметра Назначенное значение Created By, если состояние изменено на Resolved"

Мы получили много ваших отзывов об этом правиле. В ответ мы удалили это правило из типа рабочего элемента Ошибка в гибком процессе. Это изменение повлияет на каждый проект, использующий унаследованную Agile или настраиваемый унаследованный процесс Agile. Для тех клиентов, которым нравится текущее правило и которые зависят от этого правила, ознакомьтесь с нашей записью блога о действиях, которые можно предпринять для повторного добавления правила с помощью пользовательских правил.

Удаленные элементы на странице "Рабочие элементы"

Страница Рабочие элементы — это отличное место для быстрого поиска элементов, созданных вами или назначенных вам, помимо прочего. Он предоставляет несколько персонализированных сводных данных и фильтров. Одна из основных жалоб для сводки "Назначено мне" заключается в том, что в ней отображаются удаленные рабочие элементы (то есть рабочие элементы в состоянии "Удалено"). И мы согласны! Удаленные элементы — это работа, которая больше не имеет значения и поэтому была удалена из невыполненной работы, поэтому включать их в это представление не рекомендуется.

Теперь вы можете скрыть все удаленные элементы из сводки Назначено мне на странице Рабочие элементы.

Repos

Выбор имени ветви по умолчанию

Azure Repos теперь предлагает настраиваемое имя ветвь по умолчанию для Git. В параметрах репозитория можно выбрать любое юридическое имя ветви, которое будет использоваться при инициализации репозитория. Azure Repos всегда поддерживало изменение имени ветвь по умолчанию для существующего репозитория. Дополнительные сведения см. в статье Управление ветвями .

default-branch-name

Примечание. Если вы не включите эту функцию, репозитории будут инициализированы именем Azure Repos по умолчанию. Сейчас по умолчанию master. Чтобы выполнить обязательства корпорации Майкрософт и запросы клиентов на инклюзивный язык, мы присоединимся к отраслевым коллегам в изменении этого значения по умолчанию на main. Это изменение произойдет позднее этим летом. Если вы хотите продолжать использовать master, включите эту функцию и установите для нее значение master.

Параметр на уровне организации для ветвь по умолчанию

Теперь существует параметр уровня коллекции для предпочитаемого имени начальной ветви для новых репозиториев. Если проект не выбрал начальное имя ветви, будет использоваться этот параметр уровня организации. Если вы не указали имя начальной ветви в параметрах организации или проекта, то новые репозитории будут использовать azure DevOps, определенное по умолчанию.

Добавление нового область проверки подлинности для добавления комментариев на вытягивание

В этом выпуске добавлен новый область OAuth для чтения и записи комментариев к запросу на вытягивание. Если у вас есть бот или автоматизация, которые должны взаимодействовать только с комментариями, вы можете предоставить ему pat с помощью только этого область. Этот процесс уменьшает радиус взрыва, если в автоматизации есть ошибка или маркер был скомпрометирован.

Улучшения взаимодействия с запросами на вытягивание

Новый интерфейс запроса на вытягивание был улучшен следующим образом:

Сделайте необязательные проверки более видимыми

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

отображение необязательных проверок

Щелкает элементы меню, удерживая клавиши CTRL

Меню вкладок в запросе на вытягивание не поддерживали нажатие клавиш CTRL. Пользователи часто открывают новые вкладки браузера при проверке запроса на вытягивание. Эта ошибка исправлена.

Расположение заметки [+]

В древовидном списке файлов в запросе на вытягивание отображается заметка [+], чтобы помочь авторам и рецензентам определить новые файлы. Так как заметка была после многоточия, она часто не отображалась для более длинных имен файлов.

отображение расположений заметок

Раскрывающийся список обновлений для запроса на вытягивание сведений о времени восстановления

Раскрывающийся список для выбора обновления и сравнения файлов в запросе на вытягивание потерял важный элемент в интерфейсе предварительной версии. Он не отображается, когда было сделано это обновление. Эта ошибка исправлена.

В раскрывающемся списке обновлений на вытягивание отсутствуют сведения о времени

**Улучшен макет фильтра комментариев **

При фильтрации комментариев на странице сводки запроса на вытягивание раскрывающийся список находился справа, но текст выровнен по левому краю. Эта ошибка исправлена.

Улучшенный макет фильтра комментариев

Переход к родительским фиксациям

На странице Фиксации можно сравнить изменения, внесенные в определенную фиксацию, с родительской фиксацией. Однако вы можете перейти к родительской фиксации и понять, чем эта фиксация отличается от собственной родительской фиксации. Это часто требуется, если вы хотите понять все изменения в выпуске. Мы добавили родительские карта в фиксацию, чтобы помочь вам достичь этого.

Переход к родительским фиксациям

Больше места для папок и файлов с длинными именами на вкладке "Файлы запроса на вытягивание"

Папки и файлы с длинными именами были обрезаны из-за отсутствия горизонтальных интервалов в дереве файлов. Мы восстановили дополнительное пространство в дереве, изменив отступ дерева в соответствии с корневым узлом и спрятав кнопку с многоточием на странице, за исключением при наведении указателя мыши.

Изображение нового дерева файлов:

Больше места для папок и файлов

Изображение дерева файлов при наведении указателя мыши на каталог:

Отображение имени

Сохранение позиции прокрутки при изменении размера области diff на вкладке "Файлы запроса на вытягивание"

При изменении размера параллельной области diff на вкладке PR-файлы расположение прокрутки пользователя будет потеряно. Эта проблема устранена; расположение прокрутки пользователя теперь сохраняется при изменении размера области diff.

Поиск фиксации на мобильном устройстве

При просмотре страницы Фиксации на мобильном устройстве в новом интерфейсе отсутствует поле поиска. В результате вам трудно найти фиксацию по его хэшу и открыть ее. Сейчас это исправлено.

Поиск фиксации на мобильном устройстве

Улучшенное использование пространства для нового PR-файла diff мобильном представлении

Мы обновили эту страницу, чтобы лучше использовать пространство, чтобы пользователи могли видеть больше файлов в мобильных представлениях, а не 40 % экрана, занятого заголовком.

Улучшенное использование пространства для нового имени pr-файла

Улучшенные изображения в представлении сводки запроса на вытягивание

Изображения, измененные в запросе на вытягивание, не отображались в представлении сводки запроса на вытягивание, но правильно отображались в представлении pr-файлов. Эта проблема устранена.

Улучшенный интерфейс филиала при создании нового запроса на вытягивание

До этого обновления этот интерфейс не был идеальным, так как он сравнивал изменения с ветвь по умолчанию репозитория, а не с ветвь сравнения.

Расширение возможностей филиала

Pipelines

Дополнительная платформа агента: ARM64

Мы добавили Linux/ARM64 в список поддерживаемых платформ для агента Azure Pipelines. Хотя изменения в коде были минимальными, в первую очередь пришлось выполнить много закулисных работ, и мы рады объявить о его выпуске!

Поддержка фильтра тегов для ресурсов конвейера

Теперь мы добавили теги в конвейеры YAML. С помощью тегов можно настроить запуск конвейера CI или время автоматического запуска.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

В приведенном выше фрагменте кода показано, что теги можно использовать для определения версии конвейера CI (непрерывной интеграции) по умолчанию, которая будет выполняться, если выполнение конвейера CD (непрерывное развертывание) не активируется каким-либо другим источником или ресурсом или триггером запланированного запуска.

Например, если у вас есть запланированный триггер для конвейера CD, который требуется запустить только при наличии рабочего тега CI, теги в разделе триггеров гарантируют, что конвейер CD активируется только в том случае, если условие добавления тегов выполняется событием завершения CI.

Управление разрешенными задачами в конвейерах

Теперь вы можете отключить задачи Marketplace. Некоторые из вас могут разрешить расширения Marketplace, но не связанные с ними задачи конвейеров. Для еще большего контроля мы также позволяем вам независимо отключать все встроенные задачи (за исключением оформления заказа, которое является специальным действием). Если оба этих параметра включены, единственными задачами, которые разрешено выполнять в конвейере, будут задачи, отправленные с помощью tfx. Чтобы https://dev.azure.com/<your_org>/_settings/pipelinessettings приступить к работе, перейдите к разделу "Ограничения задач".

Политика монопольной блокировки развертывания

С помощью этого обновления можно гарантировать, что в среде одновременно развертывается только один запуск. Выбрав проверка "Монопольная блокировка" в среде, продолжится только один запуск. Последующие запуски, которые нужно развернуть в этой среде, будут приостановлены. После завершения выполнения с монопольной блокировкой будет продолжено последнее выполнение. Все промежуточные запуски будут отменены.

На странице Добавление проверка выберите Монопольная блокировка, чтобы обеспечить одновременное развертывание только одного запуска в среде.

Фильтры этапов для триггеров ресурсов конвейера

Мы добавили поддержку "этапов" в качестве фильтра для ресурсов конвейера в YAML. С помощью этого фильтра вам не нужно ждать завершения всего конвейера CI для активации конвейера CD. Теперь вы можете активировать конвейер CD после завершения определенного этапа в конвейере CI.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Когда этапы, указанные в фильтре триггеров, успешно завершены в конвейере CI, для конвейера CD автоматически активируется новый запуск.

Универсальные триггеры на основе веб-перехватчика для конвейеров YAML

Сегодня у нас есть различные ресурсы (например, конвейеры, контейнеры, сборка и пакеты), с помощью которых можно использовать артефакты и включить автоматические триггеры. Однако до сих пор вы не могли автоматизировать процесс развертывания на основе других внешних событий или служб. В этом выпуске мы представляем поддержку триггеров веб-перехватчика в конвейерах YAML, чтобы обеспечить интеграцию автоматизации конвейеров с любой внешней службой. Вы можете подписаться на любые внешние события с помощью веб-перехватчиков (Github, Github Enterprise, Nexus, Aritfactory и т. д.) и активировать конвейеры.

Ниже приведены шаги по настройке триггеров веб-перехватчика.

Настройка веб-перехватчика во внешней службе. При создании веб-перехватчика необходимо указать следующие сведения:
- URL-адрес запроса — "https://dev.azure.com/<ADO collection>/_apis/public/distributedtask/webhooks/<Имя >веб-перехватчика?api-version=6.0-preview"
- Секрет — это необязательный параметр. Если необходимо защитить полезные данные JSON, укажите значение секрета .
Создайте новое подключение к службе "Входящий веб-перехватчик". Это новый тип подключения службы, который позволит определить три важных элемента информации:
- Имя веб-перехватчика. Имя веб-перехватчика должно совпадать с именем веб-перехватчика, созданного во внешней службе.
- Заголовок HTTP — имя заголовка HTTP в запросе, который содержит хэш-значение полезных данных для проверки запроса. Например, в случае с GitHub заголовок запроса будет "X-Hub-Signature".
- Секрет — секрет используется для анализа хэша полезных данных, используемого для проверки входящего запроса (это необязательно). Если вы использовали секрет при создании веб-перехватчика, необходимо указать тот же секретный ключ.
В конвейерах YAML появился новый тип ресурса с именем webhooks . Для подписки на событие веб-перехватчика необходимо определить ресурс веб-перехватчика в конвейере и указать для него подключение службы входящего веб-перехватчика. Вы также можете определить дополнительные фильтры для ресурса веб-перехватчика на основе полезных данных JSON, чтобы дополнительно настроить триггеры для каждого конвейера и использовать данные полезных данных в виде переменных в заданиях.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

Всякий раз, когда подключение службы входящих веб-перехватчиков получает событие веб-перехватчика, для всех конвейеров, подписанных на событие веб-перехватчика, активируется новый запуск.

Проблемы с поддержкой и трассировки триггера ресурсов YAML

Это может запутать, когда триггеры конвейера не выполняются должным образом. Чтобы лучше понять это, мы добавили новый пункт меню на странице определения конвейера под названием "Проблемы с триггерами", где отображаются сведения о том, почему триггеры не выполняются.

Триггеры ресурсов могут не выполняться по двум причинам.

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

Триггеры с несколькими репозиториями

Можно указать несколько репозиториев в одном файле YAML и вызвать запуск конвейера путем обновления любого из репозиториев. Эта функция полезна, например, в следующих сценариях:

Вы используете средство или библиотеку из другого репозитория. Вы хотите выполнять тесты для приложения при каждом обновлении средства или библиотеки.
Файл YAML хранится в отдельном репозитории из кода приложения. Вы хотите активировать конвейер при каждой отправке обновления в репозиторий приложения.

В этом обновлении триггеры с несколькими репозиториями будут работать только для репозиториев Git в Azure Repos. Они не работают с ресурсами репозитория GitHub или BitBucket.

Ниже приведен пример определения нескольких ресурсов репозитория в конвейере и настройки триггеров для всех из них.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

Конвейер в этом примере будет активирован при наличии каких-либо обновлений для:

main ветвь в репозитории self , содержав файл YAML
main ветви или release в tools репозитории

Дополнительные сведения см. в разделе Несколько репозиториев в конвейере.

Улучшена отправка журналов агента

Когда агент перестает взаимодействовать с сервером 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 to , https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview чтобы получить завершенный текст YAML. Этот новый API принимает те же параметры, что и постановка в очередь при выполнении, но больше не требует разрешения "Сборки очередей".

Выполните следующее задание.

У вас когда-нибудь было исправление ошибок, которое необходимо было развернуть прямо в эту минуту , но приходилось ждать за заданиями CI и PR? В этом выпуске теперь можно увеличить приоритет задания в очереди. Пользователи с разрешением "Управление" в пуле (как правило, администраторы пула) увидят новую кнопку "Выполнить далее" на странице сведений о задании. При нажатии кнопки задание будет запущено как можно скорее. (Конечно, вам по-прежнему потребуется доступный параллелизм и подходящий агент.)

Выражения шаблонов, разрешенные в блоке YAML `resources`

Ранее выражения времени компиляции (${{ }}) не допускались в resources разделе YAML-файла Azure Pipelines. В этом выпуске мы сняли это ограничение для контейнеров. Это позволяет использовать содержимое параметров среды выполнения внутри ресурсов, например для выбора контейнера во время очереди. Со временем мы планируем распространить эту поддержку на другие ресурсы.

Управление автоматическим обновлением задач из Marketplace

При написании конвейера YAML обычно указывается только основной номер версии включенных задач. Это позволяет конвейерам автоматически принимать последние дополнения функций и исправления ошибок. Иногда может потребоваться выполнить откат к предыдущему выпуску задачи, и в этом обновлении мы добавили возможность сделать это. Теперь вы можете указать полную версию задачи major.minor.patch в конвейерах YAML.

Мы не рекомендуем делать это регулярно и использовать его только в качестве временного решения, когда вы обнаружите, что новая задача нарушает конвейеры. Кроме того, это не приведет к установке более старой версии задачи из Marketplace. Он должен уже существовать в коллекции, иначе конвейер завершится ошибкой.

Пример

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Поддержка Node 10 в агентах и задачах

Так как узел 6 больше не поддерживается, мы переносим задачи для работы с узлом 10. Для этого обновления мы перенесли почти 50 % встроенных задач на Узел 10. Теперь агент может выполнять задачи Node 6 и Node 10. В будущем обновлении мы полностью удалим Node 6 из агента. Чтобы подготовиться к удалению узла 6 из агента, мы просим вас обновить внутренние расширения и пользовательские задачи, чтобы также использовать Узел 10 в ближайшее время. Чтобы использовать Узел 10 для вашей задачи, в разделе executionобновите task.jsonс Node до Node10.

Улучшение преобразования YAML в классическом конструкторе сборок

В этом выпуске мы представляем новую функцию экспорта в YAML для конвейеров сборки конструктора. Сохраните определение конвейера, а затем найдите ... в меню "Экспорт в YAML".

Новая функция экспорта заменяет функцию "Просмотреть как YAML", которая ранее была найдена в классическом конструкторе сборок. Эта функция была неполной, так как она могла проверять только то, что пользовательский веб-интерфейс знал о сборке, что иногда приводило к неправильному созданию YAML. Новая функция экспорта учитывает, как именно будет обрабатываться конвейер, и создает YAML с полной точностью к конвейеру конструктора.

Преобразование новой веб-платформы — параметры репозитория

Мы преобразовали две страницы параметров репозитория в единый интерфейс, который был обновлен до новой веб-платформы. Это обновление не только ускоряет и модернизирует работу, но и предоставляет единую точку входа для всех политик от уровня проекта до уровня ветви.

Преобразование новой веб-платформы.

Благодаря этому новому интерфейсу навигация по проектам со значительным количеством репозиториев стала проще благодаря более быстрому времени загрузки и добавлению фильтра поиска. Вы также можете просмотреть политики уровня проекта и список политик между репозиторием на вкладке Политики.

Просмотрите политики между репозиториями на вкладке Политики.

Щелкнув репозиторий, можно просмотреть политики и разрешения, заданные на уровне репозитория. На вкладке политики можно просмотреть список всех ветвей, в которую настроена политика. Теперь щелкните ветвь, чтобы просмотреть все политики, не покидая страницу параметров репозитория.

Выберите ветвь, чтобы просмотреть политики.

Теперь, когда политики наследуются от более высокого область, чем то, с которыми вы работаете, мы показываем, откуда политика была унаследована рядом с каждой отдельной политикой. Вы также можете перейти на страницу, на которой была задана политика более высокого уровня, щелкнув имя область.

Показать, от чего была унаследована политика.

Сама страница политики также была обновлена до новой веб-платформы с свертываемыми разделами! Чтобы улучшить поиск определенной политики проверки сборки, проверки состояния или автоматического рецензента, мы добавили фильтры поиска для каждого раздела.

Фильтры поиска для каждого раздела.

Интеграция управления изменениями ServiceNow с конвейерами YAML

Приложение Azure Pipelines для ServiceNow помогает интегрировать Azure Pipelines и ServiceNow Change Management. В этом обновлении мы переходим к тому, чтобы в Azure Pipelines были осведомлены о процессе управления изменениями, управляемом в ServiceNow, в конвейерах YAML.

Настроив проверка "Управление изменениями ServiceNow" для ресурса, вы можете приостановить утверждение изменения перед развертыванием сборки в этом ресурсе. Вы можете автоматически создать новое изменение для этапа или дождаться существующего запроса на изменение.

Интеграция управления изменениями ServiceNow

Вы также можете добавить UpdateServiceNowChangeRequest задачу в задание сервера, чтобы обновить запрос на изменение с помощью состояния развертывания, примечаний и т. д.

Artifacts

Возможность создавать веб-каналы с областью организации из пользовательского интерфейса

Мы возвращаем возможность для клиентов создавать веб-каналы с областью сбора и управлять ими с помощью пользовательского веб-интерфейса как для локальных, так и для размещенных служб.

Теперь вы можете создавать веб-каналы с областью организации через пользовательский интерфейс, выбрав Артефакты —> создание веб-канала и выбрав тип веб-канала в области.

Создайте веб-каналы с областью коллекции, выбрав Артефакты, затем Создать веб-канал и выбрав тип веб-канала в области Область.

Хотя мы рекомендуем использовать веб-каналы с областью проекта в соответствии с остальными предложениями Azure DevOps, вы снова можете создавать веб-каналы, управлять ими и использовать их с помощью пользовательского интерфейса и различных ИНТЕРФЕЙСов REST API. Дополнительные сведения см. в документации по нашим веб-каналам.

REST API версии пакета обновления теперь доступен для пакетов Maven

Теперь вы можете использовать REST API Azure Artifacts "Update Package Version" (Обновление версии пакета) для обновления версий пакетов Maven. Ранее можно было использовать REST API для обновления версий пакетов для NuGet, Maven, npm и универсальных пакетов, но не для пакетов Maven.

Чтобы обновить пакеты Maven, используйте команду HTTP PATCH, как показано ниже.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Можно задать следующие параметры:

Параметры URI

имя;	Где	Обязательно	Тип	Описание
artifactId	path	TRUE	строка	Идентификатор артефакта пакета
feed	path	TRUE	строка	Имя или идентификатор веб-канала
groupId	path	TRUE	строка	Идентификатор группы пакета
коллекция	path	TRUE	строка	Имя коллекции Azure DevOps
version	path	TRUE	строка	Версия пакета
проект	path		строка	Идентификатор проекта или имя проекта
api-version	query	TRUE	строка	Используемая версия API. Для использования этой версии API необходимо задать значение 5.1-preview.1.

Текст запроса

имя;	Тип	Описание
узел "Представления"	JsonPatchOperation	Представление, в которое будет добавлена версия пакета

Дополнительные сведения см. в документации по REST API по мере ее обновления.

Отзывы

Мы будем рады узнать ваше мнение! Вы можете сообщить о проблеме или предоставить идею и отслеживать ее с помощью Сообщество разработчиков и получить советы по Stack Overflow.

К началу страницы

Заметки о выпуске Azure DevOpsServer 2020 с обновлением 1

Безопасное обновление с Azure DevOps Server 2019 до Azure DevOps Server 2020 г.

Azure DevOps Server 2020 г. обновление 1.2. Обновление 13 Дата выпуска: 12 марта 2024 г.

Azure DevOps Server 2020 г. обновление 1.2. Обновление 12 Дата выпуска: 13 февраля 2024 г.

Azure DevOps Server 2020 г. обновление 1.2. Обновление 11 Дата выпуска: 12 декабря 2023 г.

Azure DevOps Server 2020 г. обновление 1.2. Обновление 10 Дата выпуска: 14 ноября 2023 г.

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

Настройка TFX

Обновление задач с помощью TFX

Требования к конвейеру

Azure DevOps Server 2020 г. обновление 1.2. Обновление 9 Дата выпуска: 10 октября 2023 г.

Azure DevOps Server 2020 г. обновление 1.2. Обновление 8 Дата выпуска: 12 сентября 2023 г.

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

Обновление агента Azure Pipelines

Настройка TFX

Обновление задач с помощью TFX

Требования к конвейеру

Azure DevOps Server 2020 г. обновление 1.2. Обновление 7 Дата выпуска: 8 августа 2023 г.

Azure DevOps Server 2020 г., обновление 1.2, обновление 6 Дата выпуска: 13 июня 2023 г.

Azure DevOps Server 2020 г. Обновление 1.2. Дата выпуска обновления 5: 14 февраля 2023 г.

Azure DevOps Server 2020 г. Обновление 1.2. Обновление 4 Дата выпуска: 13 декабря 2022 г.

Azure DevOps Server 2020 г. Обновление 1.2. Дата выпуска обновления 3: 18 октября 2022 г.

Azure DevOps Server 2020 г. Обновление 1.2 Дата выпуска обновления 2: 9 августа 2022 г.

Azure DevOps Server 2020 г. Обновление 1.2 Дата выпуска обновления 1: 12 июля 2022 г.

Azure DevOps Server 2020 с обновлением 1.2 Дата выпуска: 17 мая 2022 г.

Azure DevOps Server 2020.1.1 Дата выпуска исправления 4: 26 января 2022 г.

Шаги установки

Azure DevOps Server 2020.1.1 Дата выпуска исправления 3: 15 декабря 2021 г.

Azure DevOps Server 2020.1.1 Дата выпуска исправления 2: 26 октября 2021 г.

Azure DevOps Server 2020.1.1 Дата выпуска исправления 1: 14 сентября 2021 г.

Azure DevOps Server 2020 г. обновление 1.1 Дата выпуска: 17 августа 2021 г.

Azure Boards

Azure Repos

Azure Pipelines

Общее

Планы тестирования Azure

Azure DevOps Server 2020.1. Обновление 2 Дата выпуска: 10 августа 2021 г.

Azure DevOps Server 2020.1. Обновление 1 Дата выпуска: 15 июня 2021 г.

Azure DevOps Server 2020.1 RTW Дата выпуска: 25 мая 2021 г.

Сводка о новых возможностях в Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RC2 Дата выпуска: 13 апреля 2021 г.

Сводка о новых возможностях в Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC1 Дата выпуска: 23 марта 2021 г.

Сводка о новых возможностях в Azure DevOps Server 2020.1 RC1

Boards

Правила ограничения перехода состояния

Копирование рабочего элемента для копирования дочерних элементов

Улучшенные правила для активированных и разрешенных полей

Заинтересованные лица могут перемещать рабочие элементы по столбцам доски

Системные типы рабочих элементов на невыполненных работах и досках

Azure Boards увеличенное ограничение репозитория приложений GitHub

Настройка состояния рабочего элемента при слиянии запроса на вытягивание

Связывание рабочего элемента со сборками в другом проекте

Изменение описания (текста справки) в системных полях

Настройка состояния рабочего элемента при слиянии запроса на вытягивание

Родительское поле на доске задач

Удаление правила "Назначено" для типа рабочего элемента ошибки

Удаленные элементы на странице "Рабочие элементы"

Repos

Выбор имени ветви по умолчанию

Параметр на уровне организации для ветвь по умолчанию

Добавление нового область проверки подлинности для добавления комментариев на вытягивание

Улучшения взаимодействия с запросами на вытягивание

Pipelines

Дополнительная платформа агента: ARM64

Поддержка фильтра тегов для ресурсов конвейера

Управление разрешенными задачами в конвейерах

Политика монопольной блокировки развертывания

Фильтры этапов для триггеров ресурсов конвейера

Универсальные триггеры на основе веб-перехватчика для конвейеров YAML

Проблемы с поддержкой и трассировки триггера ресурсов YAML

Триггеры с несколькими репозиториями

Улучшена отправка журналов агента

При необходимости подключите тома контейнера только для чтения

Детальный контроль над запуском и остановкой контейнера

Распакуйте пакеты задач для каждого шага

Повышение безопасности выпуска путем ограничения область маркеров доступа

Усовершенствования API предварительной версии YAML

Выполните следующее задание.

Выражения шаблонов, разрешенные в блоке YAML resources

Выражения шаблонов, разрешенные в блоке YAML `resources`