Заметки о выпуске Azure DevOps Server 2020 Update 1

Сообщество разработчиковСистемные требованияУсловия лицензионного соглашенияБлог DevOpsSHA-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 2020.

Дата выпуска Azure DevOps Server 2020, обновления 1.2 и патча 15: 11 марта 2025 г.

Файлы	Хэш SHA-256
devops2020.1.2patch15.exe	66B6FDE4949C0B7A87B20F3BC8E0673774401929D8B75E37F599DFF8BA74ABE5

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

• Обновите задачи в связи с устареванием Edgio CDN. Ознакомьтесь с записью в блоге о переключении поставщиков CDN для получения дополнительных сведений.

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

Файлы	Хэш SHA-256
devops2020.1.2patch14.exe	89AF4B1FCA1E2BD813A42F0D3E568E68E64AB470E5FD0A2F87F9E4894B8CA361420

Мы выпустили патч 14 для Azure DevOps Server 2020 Обновление 1.2, чтобы исправить уязвимую зависимость.

Дата выпуска Azure DevOps Server 2020 Update 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 Update 1.2 Patch 11: 12 декабря 2023 г.

Файлы	Хэш SHA-256
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

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

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

Дата выпуска обновления 1.2 Patch 10 для Azure DevOps Server 2020: 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 

Дата выпуска пакета обновления 9 для 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 Patch 7 для Azure DevOps Server 2020: 8 августа 2023 г.

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

• 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 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы выпустили исправление для Azure DevOps Server 2020 Update 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. Если значение в реестре отсутствует, добавьте строковое значение и задайте Версия со значением 5.4.1 (Имя = Версия, Значение = 5.4.1).
3. Выполните команду обновления PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update, приведенную в файле README. Она может возвращать предупреждение вида Невозможно соединиться с удаленным сервером. Не закрывайте окно, поскольку обновление будет повторять попытки до завершения.

Примечание.

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

1. Обновите сервер с патчем 4.
2. Проверьте значение реестра по адресу HKLM:\Software\Elasticsearch\Version. Если значение в реестре отсутствует, добавьте строковое значение и задайте Версия в значение 5.4.1 (Имя = Версия, Значение = 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, которое исправляет следующее.

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

Дата выпуска 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
• Конвейеры
• Артефакты

---

Доски

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лимит на репозитории приложения GitHub для Azure Boards увеличен

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

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

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

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

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

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

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

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

Изменение состояния рабочего элемента при объединении pull request

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

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

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

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

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

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

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

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

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

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

Repos

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

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

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

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

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

Добавление новой области авторизации для написания комментариев к pull request'ам

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

Улучшения в работе с Pull Request

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

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

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

• Ctrl-клик по пунктам меню

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Трубопроводы

Дополнительная платформа агента: 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 (непрерывного развертывания) не активирован каким-либо другим источником, ресурсом или триггером запланированного выполнения.

Например, если у вас есть запланированный триггер для конвейера CI/CD, который требуется запустить только в том случае, если CI имеет тег процесса производства, теги в разделе триггеров обеспечивают, что конвейер 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, укажите значение Secret.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Артефакты

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

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

Теперь вы можете создавать каналы с областью действия организации через пользовательский интерфейс; для этого перейдите в раздел "Артефакты" — > "Создать канал" и выберите тип канала в разделе "Область".

Хотя мы рекомендуем использовать фиды в пределах проекта в соответствии с другими предложениями 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
идентификатор артефакта	путь	Правда	строка	Идентификатор артефакта пакета
лента	путь	ИСТИНА	строка	Имя или идентификатор веб-канала
идентификатор группы	путь	ПРАВДА	строка	Идентификатор группы пакета
коллекция	путь	ИСТИНА	строка	Имя коллекции Azure DevOps
версия	путь	ИСТИНА	строка	Версия пакета
проект	путь		строка	Идентификатор проекта или имя проекта
api-version	запрос	ИСТИНА	строка	Используемая версия API. Для использования этой версии API необходимо задать значение 5.1-preview.1.

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

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

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

Отзывы

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

---

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