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

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

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

Дополнительные сведения об установке или обновлении развертывания Azure DevOps Server см. в статье "Требования к серверу Azure DevOps". Чтобы скачать продукты 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 2019 до Azure DevOps Server 2020.

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

Файлы	Хэш SHA-256
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

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

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

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

Файлы	Хэш 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 г.

Файлы	Хэш 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

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

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

Файлы	Хэш SHA-256
Tasks20231103.zip	389BA66EEBC3262FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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 

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

Внимание

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

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

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

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

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

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

Внимание

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

Примечание.

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

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

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

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

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

Примечание.

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

Настройка TFX

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

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

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

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 

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

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

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

  Определите переменную на вкладке переменной в конвейере.

• Пример YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обновление 1.2 для Azure DevOps Server 2020 — это свертка исправлений ошибок. Вы можете напрямую установить 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, включающее исправления для следующих компонентов.

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

Этапы установки

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

Примечание.

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

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

ХЭШ SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Дата выпуска Azure DevOps Server 2020.1.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 г.

Обновление 1.1 для Azure DevOps Server 2020 — это свертка исправлений ошибок. Вы можете напрямую установить 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
• Заинтересованные лица теперь могут перемещать рабочие элементы по столбцам доски
• Повышение уровня безопасности выпуска за счет ограничения области маркеров доступа
• Расширенный интерфейс запроса на вытягивание
• Триггеры с несколькими репозиториями в конвейерах

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

• Таблицы
• Repos
• Конвейеры
• Артефакты

---

Boards

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

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

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

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

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

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

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

Это позволяет клиентам создавать пользовательские значения состояния и создавать поля "Активированная дата", "Активированная дата", "Разрешено по" и "Разрешенная дата" без необходимости использовать пользовательские правила.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из-за популярного запроса теперь можно добавить поле Parent как в дочерние, так и родительские карточки на доске задач.

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

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

"Задайте для параметра "Присвоенное значение", созданное при изменении состояния на "Разрешено"

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

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

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

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

Repos

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

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

Дополнительные сведения см. в разделе "Управление ветвями" и "Изменение ветвь по умолчанию".

Настройка уровня организации для ветви по умолчанию

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

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

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

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

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

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

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

• Ctrl-clicks on menu items

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

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

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

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

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

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

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

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

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

• Расширено пространство для папок и файлов с длинными именами на вкладке файлов запроса на вытягивание

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

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

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

• Сохранение позиции прокрутки при изменении размера панели для сравнения изменений на вкладке файлов PR

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

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

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

• Оптимизировано использование пространства для нового представления различий на вкладке файлов PR в мобильной версии

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

• Расширенные изображения в представлении сводки по PR

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

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

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

Pipelines

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

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

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

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

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    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 и т. д.) и активировать конвейеры.

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

1. Настройте веб-перехватчик во внешней службе. При создании веб-перехватчика необходимо указать следующие сведения:

   • Url-адрес запроса : "https://dev.azure.com/<Коллекция> ADO/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
   • Секрет — это необязательно. Если необходимо защитить полезные данные JSON, укажите значение Секрета.

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

   • Имя веб-перехватчика: имя веб-перехватчика должно соответствовать веб-перехватчику, созданному во внешней службе.
   • Заголовок HTTP — имя заголовка HTTP в запросе, который содержит хэш-значение полезных данных для проверки запроса. Например, в случае GitHub заголовок запроса будет "X-Hub-Signature"
   • Секрет — секрет используется для анализа хэша полезных данных, используемого для проверки входящего запроса (это необязательно). Если вы использовали секрет при создании веб-перехватчика, вам потребуется предоставить тот же секретный ключ.

   

3. В конвейерах 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}}

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

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

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

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

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

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

   

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

Можно указать несколько репозиториев в одном файле 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, чтобы 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Artifacts

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

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

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

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

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

Теперь для обновления версий пакетов Maven можно использовать REST API "Обновление версии пакета" Azure Artifacts. Ранее можно использовать 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

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

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

Имя	Тип	Description
просмотров	JsonPatchOperation	Представление, к которому будет добавлена версия пакета

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

Отзывы

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

---

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