Заметки о выпуске Azure DevOps Server 2019 с обновлением 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 2019 с обновлением 1.2 с обновлением 9: 28 мая 2024 г.

Файлы	Хэш SHA-256
devops2019.1.2patch9.exe	4A3F41BBE00174DE9646787766EBF7F4D292526CBC1D85180B55D994B4D81

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

• Упрощение развертывания обновлений агента и задач из предыдущих исправлений (исправление 5 и 6).

Примечание.

Не обязательно выполнять действия в исправлениях 5 и 6; Эти исправления можно пропустить, и это исправление можно применить вместо этого.

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

Внимание

 Это исправление обновляет доступный агент конвейера, новая версия агента после установки исправления 9 будет 3.225.0.

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

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

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

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

• Пример YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

Файлы	Хэш SHA-256
devops2019.1.2patch8.exe	67E78EA7D67A09A6EE06309614F92E6D8495DEF52FF442E4E7C797924FAD20A

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

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

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

Файлы	Хэш SHA-256
devops2019.1.2patch7.exe	8C67C72A83C9215302BDEFB752A7C4E3F876D4D17FCFA63A02B955FCFB5455AA

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

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

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

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

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

Примечание.

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

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

Внимание

Мы выпустили обновления агента Azure Pipelines с исправлением 5, выпущенном 12 сентября 2023 г. Если вы не установили обновления агента, как описано в заметках о выпуске исправлений 5, рекомендуется установить эти обновления перед установкой исправлений 6. Новая версия агента после установки исправления 5 будет 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 2019 с обновлением 5: 12 сентября 2023 г.

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

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

Внимание

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

Примечание.

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

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

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

Обновление агента 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 2019: 8 августа 2023 г.

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

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

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

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

• Исправлена ошибка, которая препятствовала отправке пакетов при обновлении с 2018 или более ранней версии.

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

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

• Исправлены сбои в задании "Account Parallelism Sync Analytics".

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

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

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

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

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

Примечание.

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

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

• Отмените все личные маркеры доступа после отключения учетной записи Active Directory пользователя.

Дата выпуска Azure DevOps Server 2019 с обновлением 1.1 с обновлением 13: 26 января 2022 г.

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

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

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

1. Обновите сервер с помощью исправления 13.
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. Обновите сервер с помощью исправления 13.
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: DB762E391F9DF8E71E58D6FAA169CA44DFBE996AE6567B55F772CBA9E3DA2AB3

Дата выпуска azure DevOps Server 2019 с обновлением 1.1 с обновлением 12: 15 сентября 2021 г.

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

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

Дата выпуска azure DevOps Server 2019 с обновлением 1.1 с обновлением 11: 14 сентября 2021 г.

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

• Устраните проблему, сообщаемую в этом Сообщество разработчиков запросе обратной связи.

Дата выпуска azure DevOps Server 2019 с обновлением 1.1: 10 августа 2021 г.

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

• Исправлена проблема с заданиями доставки электронной почты для некоторых типов рабочих элементов.

Дата выпуска обновления 1.1 для Azure DevOps Server 2019 с обновлением 1.1: 15 июня 2021 г.

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

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

Дата выпуска обновления 1.1 для Azure DevOps Server 2019 с обновлением 1.1: 13 апреля 2021 г.

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

• CVE-2021-27067: раскрытие информации
• Устранение проблемы, сообщаемой в этом запросе на отзыв Сообщество разработчиков | Не удалось зарегистрировать сведения о итерации результатов теста в Azure DevOps Server 2019

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

Общая установка исправлений

Если у вас есть Azure DevOps Server 2019 с обновлением 1.1, необходимо установить Azure DevOps Server 2019 с обновлением 1.1 исправлений 8.

Проверка установки

• Вариант 1. Запуск devops2019.1.1patch8.exe CheckInstalldevops2019.1.1patch8.exe — это файл, скачанный из приведенной выше ссылки. Выходные данные команды либо говорят, что исправление установлено или не установлено.

• Вариант 2. Проверьте версию следующего файла: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll Azure DevOps Server 2019 устанавливается c:\Program Files\Azure DevOps Server 2019 по умолчанию. После установки Azure DevOps Server 2019.1.1 с исправлением 8 версия будет 17.153.31129.2.

Установка задачи AzureResourceGroupDeploymentV2

Примечание.

Все нижеперечисленные шаги нужно выполнять на компьютере с Windows.

Установка

1. Извлеките пакет AzureResourceGroupDeploymentV2.zip в новую папку на компьютере. Например: D:\tasks\AzureResourceGroupDeploymentV2.

2. Скачивание и установка Node.js 14.15.1 и npm (включенная в Node.js скачивания) в соответствии с вашим компьютером.

3. Откройте командную строку в режиме администратора и выполните следующую команду, чтобы установить tfx-cli.

npm install -g tfx-cli

4. Создайте личный маркер доступа с привилегиями Полного доступа и скопируйте его. Этот личный маркер доступа будет использоваться при выполнении команды tfx login.

5. В командной строке выполните следующую команду. При появлении запроса введите URL-адрес службы и личный маркер доступа.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Выполните следующую команду, чтобы отправить задачу на сервер. Используйте путь к извлеченному ZIP-файлу из шага 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Дата выпуска обновления 1.1 для Azure DevOps Server 2019 с обновлением 1.1: 12 января 2021 г.

Мы выпустили исправление для Azure DevOps Server 2019 с обновлением 1.1, которое исправляет следующее. Дополнительные сведения см. в записи блога.

• Сведения о тестовом запуске не отображают сведения о шаге теста для тестовых данных, перенесенных с помощью миграции OpsHub
• Исключение для инициализатора microsoft.TeamFoundation.TestManagement.Server.TCMLogger
• Незапланированные сборки немедленно удаляются после миграции в Azure DevOps Server 2020
• Исправление исключения поставщика данных

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

Мы выпустили исправление для Azure DevOps Server 2019 с обновлением 1.1, которое исправляет следующее. Дополнительные сведения см. в записи блога.

• CVE-2020-1325: уязвимость spoofing сервера Azure DevOps
• CVE-2020-17135: уязвимость spoofing сервера Azure DevOps
• CVE-2020-17145: уязвимость для спуфинга в Azure DevOps Server и службах Team Foundation Service
• Исправлена проблема с TFVC, не обрабатывающей все результаты

Внимание

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

Общая установка исправлений

Если у вас есть Azure DevOps Server 2019 с обновлением 1.1, необходимо установить Azure DevOps Server 2019 с обновлением 1.1 с исправлением 6.

Проверка установки

• Вариант 1. Запуск devops2019.1.1patch6.exe CheckInstalldevops2019.1.1patch6.exe — это файл, скачанный по ссылке выше. Выходные данные команды либо говорят, что исправление установлено или не установлено.

• Вариант 2. Проверьте версию следующего файла: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll Azure DevOps Server 2019 устанавливается c:\Program Files\Azure DevOps Server 2019 по умолчанию. После установки Azure DevOps Server 2019.1.1 с исправлением 6 версия будет 17.153.30723.5.

Установка задач AzurePowerShellV4

Примечание.

Все нижеперечисленные шаги нужно выполнять на компьютере с Windows.

Необходимые компоненты

1. Установите модуль Azure PowerShell Az Azure PowerShell на компьютере частного агента.

2. Создайте конвейер с задачей AzurePowerShellV4 . В задаче появится только одна ошибка " Сбой" в стандартной ошибке.

Установка

1. Извлеките пакет AzurePowerShellV4.zip в папку с именем AzurePowerShellV4.

2. Скачайте и установите Node.js 14.15.1 и npm (входит в состав загрузки Node.js), совместимые с вашим компьютером.

3. Откройте командную строку в режиме администратора и выполните следующую команду, чтобы установить tfx-cli.

npm install -g tfx-cli

4. Создайте личный маркер доступа с привилегиями Полного доступа и скопируйте его. Этот личный маркер доступа будет использоваться при выполнении команды tfx login.

5. В командной строке выполните следующую команду. При появлении запроса введите URL-адрес службы и личный маркер доступа.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Выполните следующую команду, чтобы отправить задачу на сервер. Путь извлеченного пакета будет D:\tasks\AzurePowerShellv4.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

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

Мы выпустили исправление для Azure DevOps Server 2019 с обновлением 1.1, которое исправляет следующее. Дополнительные сведения см. в записи блога.

• DTS 1713492 — непредвиденное поведение при добавлении групп AD в разрешения безопасности.

Дата выпуска обновления 1.1 для Azure DevOps Server 2019 с обновлением 4: 14 июля 2020 г.

Мы выпустили исправление для Azure DevOps Server 2019 с обновлением 1.1, которое исправляет следующее. Дополнительные сведения см. в записи блога.

• CVE-2020-1326: уязвимость межстранийного скрипта
• Конвейер сборки показывает неправильное подключение для несанкционированных пользователей при выборе другого источника Git.
• Исправлена ошибка при изменении наследования на "Вкл." или "Выкл." в определении сборки XAML.

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

Мы выпустили исправление для Azure DevOps Server 2019 с обновлением 1.1, которое исправляет следующее. Дополнительные сведения см. в записи блога.

• CVE-2020-1327: убедитесь, что сервер Azure DevOps санирует входные данные пользователей.

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

Мы выпустили исправление для Azure DevOps Server 2019 с обновлением 1.1, которое исправляет следующее. Дополнительные сведения см. в записи блога.

• Фиксации SVN не активируют конвейер

• Добавление поддержки SHA2 в SSH в Azure DevOps

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

Мы выпустили исправление безопасности для Azure DevOps Server 2019 с обновлением 1.1, которое исправляет следующие ошибки. Дополнительные сведения см. в записи блога.

• CVE-2020-0700: уязвимость для межсайтовых сценариев

• CVE-2020-0758: уязвимость к повышению привилегий

• CVE 2020-0815: уязвимость с повышением привилегий

---

Дата выпуска Обновления 1.1 RTW для Azure DevOps Server 2019: 10 декабря 2019 г.

Обновление 1.1 для Azure DevOps Server 2019 — это свод исправлений ошибок и обновлений системы безопасности. Он включает все исправления в ранее выпущенных исправлениях Для Azure DevOps Server 2019 с обновлением 1. Вы можете напрямую установить Azure DevOps Server 2019 с обновлением 1.1 или обновить с Azure DevOps Server 2019 или Team Foundation Server 2012 или более поздней версии.

Примечание.

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

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

Azure Boards

• При создании нового рабочего элемента из невыполненной работы продукта поле Title не инициализировано со значением по умолчанию в шаблоне процесса.
• Замедление и время ожидания при использовании Azure Boards.
• Измененное значение неверно для ссылок рабочего элемента.

Azure Pipelines

• В уведомлениях конвейеров поля, такие как Длительность, могут иметь значение NULL в некоторых языковых стандартах.
• Путь к шаблону может не указывать на допустимый JSON-файл в конвейере, который включает развертывание группы ресурсов Azure.
• Страница параметров хранения на уровне коллекции отображается на страницах параметров проекта.

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

• Поля редактирования в планах тестирования медленно.
• В тестовом случае при открытии из досок (в отличие от планов тестирования), общие сведения о шаге не открываются.

Общие

• Коллекции не отсортированы в алфавитном порядке.

Администрирование

• Высокая загрузка памяти.
• Серверы с конфигурациями подсистемы балансировки нагрузки должны были явно добавить их открытый источник в запись реестра AllowedOrigins.
• Клиенты, которые устанавливают в SQL Azure, не видят диалоговое окно "Полная пробная версия".
• Установка расширений дает ошибку "Сообщение об ошибке отсутствует вклад (ms.vss-dashboards-web.widget-sdk-version-2)".
• При настройке эластичного поиска возникает ошибка: "Пользователь неавторизован".
• Сбои индексирования и запросов в эластичном поиске при обновлении с TFS 2018 с обновлением 2 или более поздней версии.
• Шаг "Создать хранилище" завершается сбоем при настройке Azure DevOps Server.

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

• Поддержка SQL Server 2019.

---

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

Мы выпустили исправление безопасности для Azure DevOps Server 2019 с обновлением 1, которое исправляет следующую ошибку. Дополнительные сведения см. в записи блога.

• CVE-2019-1306: уязвимость удаленного выполнения кода в Вики-сайте

---

Дата выпуска Azure DevOps Server 2019 с обновлением 1: 20 августа 2019 г.

Примечание.

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

---

Дата выпуска RC2: 23 июля 2019 г.

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

---

Дата выпуска RC1: 2 июля 2019 г.

Сводка о новых возможностях Azure DevOps Server 2019 с обновлением 1

Azure DevOps Server 2019 с обновлением 1 содержит множество новых функций. Вот некоторые из них:

• Новый базовый процесс
• запрос рабочих элементов относительно начала дня, недели, месяца или года;
• принятие отчетов об ошибках и их решение в GitHub, планирование в Azure Boards;
• Повторное выполнение просроченной сборки для запросов на вытягивание автозаполнения
• новые типы слияния для завершения запросов на вытягивание.
• Активация конвейеров YAML с помощью тегов
• помощник по выполнению задач для редактирования файлов YAML;
• Веб-редактор с IntelliSense для конвейеров YAML
• Управление выпусками GitHub с помощью конвейеров
• Мини-приложение тренда результатов теста (дополнительно)
• Сведения о происхождении пакетов
• Поддержка пакетов Python
• вышестоящие источники для Maven.
• Внедрение запросов Azure Boards в вики-сайт
• Пермалинки для вики-страниц
• уведомления на вики-страницах.
• Расширение Аналитики больше не требуется для использования аналитики

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

• Общие сведения
• Таблицы
• Repos
• Конвейеры
• Тестовые планы
• Артефакты
• Вики
• Отчеты

---

Общие

Темная тема

Темная тема была популярной функцией в Azure DevOps Services и теперь доступна в Azure DevOps Server. Вы можете включить темную тему, выбрав тему в меню под аватаром в правом верхнем углу каждой страницы.

Boards

Новый базовый процесс

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

Новый базовый процесс предоставляет три типа рабочих элементов (Epics, Issues и Tasks) для планирования и отслеживания работы. Мы рекомендуем использовать проблемы для отслеживания таких проблем, как истории пользователей, ошибки и функции при использовании Epics для объединения проблем в более крупные единицы работы. По мере выполнения работы перемещайте элементы по простому рабочему процессу состояния Список дел, "Выполнение" и "Готово".

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

Порядок значений состояния в форме рабочего элемента

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

Включение компонентов больше не доступно

Клиентам потребуется вручную обновить XML-код для каждого проекта, чтобы включить новые функции после обновления коллекции.

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

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

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

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

README репозитория часто является домом, к которому обращается ваша команда проектов, чтобы получить сведения о том, как вносить свой вклад и использовать ваше решение. Теперь, как и вы можете с состоянием сборки или развертывания в Azure Pipelines, вы можете добавить в README значок для доски вашей команды в Azure Boards. Вы можете настроить эмблему, чтобы отобразить только столбцы "Ход выполнения" или все столбцы, а также сделать значок видимым общедоступным, если проект открытый код.

Если readME основан на Markdown, вы можете просто скопировать пример Markdown на странице параметров индикатора состояния и вставить его в файл.

запрос рабочих элементов относительно начала дня, недели, месяца или года;

Хотя команды часто сосредоточены на работе в контексте того, что происходит дальше или на основе итерации спринта, часто интересно взглянуть на работу через объектив календаря, чтобы сообщить обо всех работах, которые произошли в прошлом месяце или в первом квартале года. Теперь можно использовать следующий новый набор макросов @StartOf вместе с любым полем на основе дат для запроса на основе начала дня, недели, месяца или года:

• @StartOfYear
• @StartOfMonth
• @StartOfWeek
• @StartOfDay

Каждый из этих макросов также принимает новую строку модификатора, которая позволяет перемещать данные по разным единицам даты. Например, можно написать запрос, чтобы найти все рабочие элементы, завершенные в первом квартале этого года, запросить дату >изменения состояния = @StartOfYear и дату <изменения состояния = @StartOfYear("+3M"). Дополнительные сведения см. в документации по макросам запроса.

Изменение и удаление комментариев обсуждения

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

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

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

экспорт результатов запросов в CSV-файл.

Теперь вы можете экспортировать результаты запроса непосредственно в CSV-файл формата из Интернета.

переход к рабочим элементам Azure Boards непосредственно из упоминаний в любом комментарии GitHub;

Теперь, когда вы упоминание рабочий элемент в комментарии проблемы, запроса на вытягивание или фиксацию в GitHub с помощью AB#{work item ID} синтаксиса, эти упоминание становятся гиперссылками, которые можно щелкнуть, чтобы перейти непосредственно к упоминание рабочему элементу.

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

принятие отчетов об ошибках и их решение в GitHub, планирование в Azure Boards;

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

Тот же упоминание синтаксис, используемый командой для фиксаций и запросов на вытягивание, по-прежнему применяется и, конечно, можно связать вручную в Azure Boards с URL-адресом проблемы. Дополнительные сведения см. в документации по GitHub и Azure Boards .

быстрый просмотр связанных действий GitHub на канбан-доске;

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

Repos

Черновые запросы на вытягивание

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

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

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

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

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

Azure Repos теперь автоматически будет выполнять сборки с истекшим сроком действия очереди, которые были активированы политикой запроса на вытягивание. Это относится к запросам на вытягивание, которые прошли все остальные политики и настроены для автоматического завершения.

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

Примечание.

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

возможность просмотра только файла слева или справа в запросе на вытягивание.

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

новые типы слияния для завершения запросов на вытягивание.

Теперь у вас есть дополнительные параметры при слиянии изменений из запроса на вытягивание с целевой ветвью. Мы добавили поддержку двух наиболее запрошенных функций в Сообщество разработчиков: слияние fast-Forward и полулинейное слияние (также называемое "Перебаза и слияние").

Теперь вы увидите эти новые параметры, доступные в диалоговом окне "Полный запрос на вытягивание":

Обновленная страница администрирования политики позволяет администраторам контролировать, какие стратегии слияния разрешены в ветви или папке ветвей.

Примечание.

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

Существует несколько ситуаций, когда повторное выполнение запроса на вытягивание невозможно:

• Если политика в целевой ветви запрещает использование стратегий перебазирования, вам потребуется разрешение "Переопределить политики ветви".
• Если исходная ветвь запроса на вытягивание имеет политики, вы не сможете перебазировать ее. Перебазирование изменит исходную ветвь без прохождения процесса утверждения политики.
• Если вы использовали расширение конфликта слияния для разрешения конфликт слияния. Разрешения конфликтов, применяемые к трехсторонним слиянию, редко успешны (или даже допустимы) при повторной сортировке всех фиксаций в запросе на вытягивание по одному за раз.

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

Фильтрация по целевой ветви в запросах на вытягивание

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

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

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

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

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

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

Пример расширения, демонстрирующего эту функцию , можно найти здесь.

Кроме того, мы добавили поддержку выделения синтаксиса языка Kusto.

точка расширения для создания репозиториев;

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

улучшенная поддержка кодирования.

Ранее редактирование и сохранение файлов в Интернете сохранялось только в формате кодировки UTF-8, и при изменении кодирования файлов не было предложено. Теперь мы предоставим вам предупреждение при попытке сохранить файл, который не закодирован через Интернет (который поддерживает только кодировку UTF). Кроме того, мы добавили поддержку кодировки UTF-16 и UTF-32 через конечную точку отправки веб-уведомлений. Это означает, что мы сохраняем тип кодирования, поэтому их не нужно переписать как UTF-8.

На следующем снимка экрана показан и пример диалогового окна, которое вы увидите при вводе изменений в кодировке веб-push.

поддержка команды Go get в Azure Repos.

Go — это открытый код язык программирования, также называемый Голангом. В Go можно использовать команду get для скачивания и установки пакетов и зависимостей. В этом обновлении мы добавили поддержку go get в репозитории Azure DevOps. При этом go getвы сможете скачать пакеты со своими зависимостями, именуемыми путями импорта. Ключевое import слово можно использовать для указания пути импорта.

Pipelines

Веб-редактор с IntelliSense для конвейеров YAML

Если вы используете YAML для определения конвейеров, теперь вы можете воспользоваться новыми функциями редактора, представленными в этом выпуске. Независимо от того, создаете ли вы новый конвейер YAML или редактируете существующий конвейер YAML, вы сможете изменить файл YAML в веб-редакторе конвейера. При редактировании YAML-файла используйте поддержку CTRL+SPACE для IntelliSense. Вы увидите выделенные синтаксические ошибки, а также получите справку по исправлению этих ошибок.

помощник по выполнению задач для редактирования файлов YAML;

Мы продолжаем получать много отзывов с просьбой упростить редактирование файлов YAML для конвейеров, поэтому мы добавляем задачу помощник в редактор YAML. Благодаря этому вы получите тот же знакомый интерфейс для добавления новой задачи в ФАЙЛ YAML, что и в классическом редакторе. Эта новая помощник поддерживает большинство распространенных типов входных данных задач, таких как списки выбора и подключения служб. Чтобы использовать новую задачу помощник, выберите "Изменить" в конвейере на основе YAML и выберите помощник задачи.

Активация конвейеров YAML с помощью тегов

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

Можно указать, какие теги следует включить и исключить. Например:

trigger:
  tags:
    include:
    - releases/*
    exclude:
    - releases/old*

Объявление ресурсов контейнера с помощью встроенного синтаксиса

Ранее необходимо объявить ресурсы контейнера в конвейерах YAML, а затем ссылаться на них по имени. Теперь мы предлагаем встроенный синтаксис для случаев, когда вы не собираетесь ссылаться на контейнер несколько раз.

jobs:
- job: my-container-job
  container:
    image: microsoft/dotnet:latest

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

По умолчанию конвейеры, активированные запросами на вытягивание (PR), будут отменены, если новая фиксация отправляется в тот же PR. Это желательно в большинстве случаев, так как обычно не требуется продолжать работу конвейера в устаревшем коде. Если это поведение не требуется, можно добавить autoCancel: false в триггер PR.

pr:
  branches:
    include:
    - main
    - releases/*
  autoCancel: false

выбор каталога извлеченного кода в конвейерах YAML;

Ранее мы проверка репозиторий в s каталоге в разделе $(Agent.BuildDirectory). Теперь можно выбрать каталог, в котором репозиторий Git будет проверка для использования с конвейерами YAML.

path Используйте ключевое слово checkout и вы будете контролировать структуру папок. Ниже приведен пример кода YAML, который можно использовать для указания каталога.

steps:
- checkout: self
  path: my-great-repo

В этом примере код будет проверка в my-great-repo каталог в рабочей области агента. Если вы не укажете путь, репозиторий будет продолжать проверка в каталог с именемs.

Новые задачи службы приложение Azure, оптимизированные для YAML

Теперь мы поддерживаем четыре новых задачи, которые обеспечивают простой и эффективный способ развертывания служб приложение Azure с учетом современных разработчиков. Эти задачи имеют оптимизированный синтаксис YAML, упрощающий и интуитивно понятный способ разработки развертываний для приложение Azure Services, включая WebApps, FunctionApps, WebApps для контейнеров и FunctionApp для контейнеров на платформах Windows и Linux.

Мы также поддерживаем новую задачу служебной программы для преобразования файлов и подстановки переменных для форматов XML и JSON.

Изменены разрешения по умолчанию для новых проектов

До сих пор участник проекта не удалось создать конвейеры, если только они явно не предоставлены разрешения "Создать определение сборки". Для новых проектов участники команды могут легко создавать и обновлять конвейеры. Это изменение приведет к снижению трения для новых клиентов, которые подключены к Azure Pipelines. Вы всегда можете обновить разрешения по умолчанию для группы участников и ограничить их доступ.

Управление выпусками GitHub с помощью конвейеров

Выпуски GitHub — это отличный способ упаковки и предоставления пользователям программного обеспечения. Мы рады сообщить, что теперь вы можете автоматизировать его с помощью задачи выпуска GitHub в Azure Pipelines. С помощью задачи можно создать новый выпуск, изменить существующие черновики или опубликованные выпуски или отключить карта старые. Она поддерживает такие функции, как отправка нескольких ресурсов, маркировка выпуска как предварительная версия, сохранение выпуска в виде черновика и многое другое. Эта задача также помогает создавать заметки о выпуске. Он также может автоматически вычислить изменения (фиксации и связанные проблемы), внесенные в этом выпуске, и добавить их в заметки о выпуске в понятном формате.

Ниже приведен простой YAML для задачи:

task: GithubRelease@0 
displayName: 'Create GitHub Release'      
inputs:
  githubConnection: zenithworks
  repositoryName: zenithworks/pipelines-java
  assets: $(build.artifactstagingdirectory)/*.jar

Пример выпуска GitHub, созданный с помощью этой задачи:

Ссылки на определенные строки в журнале сборки

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

улучшения авторизации ресурсов;

Необходимо обеспечить безопасность защищенных ресурсов (например, подключений служб, групп переменных, пулов агентов, защищенных файлов) при ссылке на ФАЙЛ YAML. В то же время мы хотели упростить настройку и использование конвейеров, использующих эти типы ресурсов для нерабочих сценариев. Ранее мы добавили параметр, чтобы пометить ресурс как "авторизованный для использования во всех конвейерах".

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

новые точки создания расширений на вкладке тестов в службе Pipelines.

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

Два пункта вклада:

1. Кнопка настраиваемого действия на панели инструментов

   Иногда может потребоваться выполнить действие, например обновить данные API или запустить пользовательские средства с помощью метаданных из результатов теста. С помощью этой точки вклада можно создать расширения, которые используют немедленный контекст выбранного результата теста, чтобы добавить настраиваемое действие на кнопку *Custom Action- (Настраиваемое действие).

   

2. Вкладка "Настраиваемые сведения" в области сведений

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

однократный запуск агента;

Если вы используете инфраструктуру, например Экземпляры контейнеров Azure для запуска эластичных частных агентов, часто необходимо, чтобы каждый агент принял только одно задание, прежде чем уйти. До сих пор это было не легко, так как вам пришлось завершить агент (возможно, причиняя неудачу) или принять риск того, что агент может получить другое задание, прежде чем вы сможете завершить работу. При этом обновлении мы добавили флаг --один раз в конфигурацию агента. При настройке агента таким образом он будет принимать только одно задание, а затем завершить работу.

обновление пользовательского интерфейса пула агентов;

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

Развертывание для неудачных целевых объектов в группе развертывания

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

Автоматическое повторное развертывание в случае сбоя

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

Перехватчик события для заметок Grafana

Теперь мы поддерживаем новый перехватчик службы, который позволяет добавлять заметки Grafana для событий завершения развертывания на панель мониторинга Grafana. Это позволяет сопоставлять развертывания с изменениями метрик приложения или инфраструктуры, визуализируемых на панели мониторинга Grafana.

Задачи запроса оповещений Azure Monitor

Предыдущая версия задачи "Запрос Azure Monitors" поддерживает оповещения о запросах только в классическом интерфейсе мониторинга. С помощью этой новой версии задачи вы можете запрашивать оповещения об унифицированном мониторинге, недавно появившиеся в Azure Monitor.

Добавление встроенного файла спецификаций в задаче "Развертывание в Kubernetes"

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

Задача установщика Docker CLI

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

восстановление удаленных конвейеров выпуска;

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

уведомления при сбое запроса на создание выпуска;

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

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

планирование выпусков при изменении источника или конвейера;

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

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

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

публикация в очередях сеансов служебной шины Azure;

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

новый вариант подписки Azure в подключении службы Kubernetes;

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

В этом обновлении мы добавили параметр проверки подлинности в форму подключения службы Kubernetes. Теперь вы можете выбрать подписку Azure для проверки подлинности подключения. Это упрощает развертывание в определенных пространствах имен путем настройки подключений Kubernetes с именем подписки и кластера Azure.

Для кластера с поддержкой управления доступом на основе ролей (RBAC) объекты ServiceAccount и RoleBinding создаются в выбранном пространстве имен. Объект RoleBinding ограничивает операции созданной учетной записи службы только выбранному пространству имен. Для отключенного кластера RBAC учетная запись службы имеет разрешения на уровне кластера в пространствах имен.

Реестр контейнеров Azure в подключении службы реестра Docker

Теперь можно создать подключение службы реестра Docker на странице параметров проекта. Чтобы создать подключение, выберите реестр контейнеров Azure в одной из подписок, связанных с удостоверением Azure Active Directory (AAD). Все задачи, требующие подключения служб к реестрам контейнеров, таким как Docker@2 и KubernetesManifest@0 , поддерживают единый способ указания подключения.

поиск по имени папки в определениях выпусков;

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

задание установщика Duffle в конвейерах сборки и выпуска;

Duffle — это средство командной строки, позволяющее устанавливать и управлять пакетами собственных приложений облака (CNAB). С помощью CNABs можно упаковыть, установить и управлять приложениями на основе контейнеров и их службами.

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

Задачи с манифестом Kubernetes

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

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

• Стабильность манифеста. Состояние развертывания проверка для объектов Kubernetes, развернутых для включения проверка стабильности при вычислении состояния задачи как успешной или неудачной.

• Заметки о трассировке. Заметки добавляются в развернутые объекты Kubernetes для создания сведений о трассировке организации, проекта, конвейера и запуска.

• Выпекание манифеста. Действие выпечки задачи позволяет создавать диаграммы Helm в файлы манифестов Kubernetes, чтобы их можно было применить к кластеру.

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

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

обновления задачи Docker;

Мы обновили задачу Docker, чтобы упростить процесс разработки конвейера. Теперь команда buildAndPush может использоваться для создания нескольких тегов для определенного репозитория контейнеров и отправки его в несколько реестров контейнеров на одном шаге. Задача может использовать подключения службы реестра Docker для входа в реестры контейнеров. Метаданные трассировки о исходном репозитории, фиксации и прованансе сборки добавляются в виде меток для образов, созданных с помощью этой задачи.

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Установщик средств Kubectl

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

улучшения интеграции ServiceNow;

Ключевая возможность для совместной работы между командами — позволить каждой команде использовать службу по своему выбору и обеспечить эффективную сквозную доставку. Благодаря этому обновлению мы улучшили интеграцию ServiceNow для поддержки всех типов изменений (обычные, стандартные и экстренные ситуации). Кроме того, теперь можно указать шлюз, используемый для создания нового запроса на изменение с помощью существующего шаблона, как показано в процессе ITSM в организации. Наконец, вы также можете включить выпуски на основе существующих запросов на изменение. Это позволяет внедрять cd без необходимости изменять процесс, рекомендуемый ИТ-командами.

поддержка Red Hat Enterprise Linux 6.

В этом обновлении мы добавили поддержку агента для Red Hat Enterprise Linux 6. Теперь можно настроить агенты, предназначенные для платформы Red Hat Enterprise Linux 6 для выполнения заданий сборки и выпуска.

поддержка модуля Az для Azure PowerShell;

Azure PowerShell предоставляет набор командлетов, которые можно использовать для управления ресурсами Azure из командной строки. В декабре прошлого года модуль Azure PowerShell Az стал доступным и теперь предназначен для управления ресурсами Azure.

Ранее мы не предоставили поддержку модуля Azure PowerShell Az в размещенных агентах. С новой задачей Azure PowerShell версии 4.* в конвейерах сборки и выпуска мы добавили поддержку нового модуля Az для всех платформ. Задача Azure PowerShell версии 3.* продолжит поддерживать модуль AzureRM. Однако для обновления последних служб и функций Azure рекомендуется перейти на задачу Azure PowerShell версии 4.* как можно скорее.

Модуль Az имеет режим совместимости, помогающий использовать существующие скрипты при обновлении их для использования нового синтаксиса. Чтобы включить совместимость модуля Az, используйте Enable-AzureRmAlias команду. Псевдонимы позволяют использовать старые имена командлетов с модулем Az. Дополнительные сведения о миграции из модуля Azure RM в модуль Azure PowerShell Az см. здесь.

Примечание.

Если вы используете частные агенты, необходимо установить модуль Az на компьютере агента.

Дополнительные сведения о модуле Azure PowerShell Az см . здесь.

Поддержка проверки подлинности Azure Active Directory (AD) для задачи SQL Azure

Задача SQL Azure была расширена для поддержки подключения к базе данных с помощью Azure AD (интегрированный и пароль) и строка подключения в дополнение к существующей поддержке проверки подлинности SQL Server.

публикация артефактов сборки с длинными путями к файлам;

До сих пор было ограничение, запрещающее отправку артефактов сборки с путями дольше 233 символов. Это может препятствовать отправке результатов покрытия кода из сборок Linux и macOS с путями к файлам дольше предела. Ограничение было обновлено для поддержки длинных путей.

пропуск непрерывной интеграции (CI) для фиксации;

Теперь можно сообщить Azure Pipelines игнорировать фиксацию и пропустить запуск конвейера, который обычно активируется фиксацией. Просто включите [skip ci] в сообщение фиксации HEAD, а Azure Pipelines пропустит CI. Вы также можете использовать любой из вариантов, перечисленных ниже. Это поддерживается для фиксаций в Azure Repos Git и GitHub Enterprise Server.

• [skip ci] или [ci skip]
• skip-checks: true или skip-checks:true
• [skip azurepipelines] или [azurepipelines skip]
• [skip azpipelines] или [azpipelines skip]
• [skip azp] или [azp skip]
• ***NO_CI***

Test Plans

Мини-приложение тренда результатов теста (дополнительно)

Мини-приложение "Тенденция результатов теста" (Дополнительно) обеспечивает практически в реальном времени видимость тестовых данных для нескольких сборок и выпусков. Мини-приложение "Тенденция результатов теста" (Дополнительно) отображает тенденцию результатов теста для конвейеров или между конвейерами. Его можно использовать для отслеживания ежедневного количества тестов, скорости передачи и длительности тестирования. Отслеживание качества теста с течением времени и улучшение тестового обеспечения является ключом к поддержанию работоспособного конвейера DevOps.

Мини-приложение "Тенденция результатов теста" (Дополнительно) помогает найти выпадающие в результатах теста и ответить на такие вопросы, как: тесты занимают больше времени для выполнения, чем обычно? Какой тестовый файл или конвейер влияет на общую скорость передачи? Что такое длительные тесты?

Чтобы ответить на эти вопросы, мини-приложение предоставляет следующие функции:

• Отображает тенденцию скорости передачи и количество результатов теста или продолжительности теста
• Представляет результаты теста на основе нескольких конвейеров сборки или конвейеров выпуска
• Использует объединенные параметры диаграммы для отображения двух метрик по одной и той же тенденции
• Фильтрует количество тестов с течением времени по результатам теста
• Фильтрует все результаты теста по ветви или тесту
• Стек метрик по атрибутам теста, таким как приоритет или среда
• Группируйте данные в тестовых файлах, владельцах или конвейерах

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

Предоставление общего доступа к результатам выполнения теста с помощью URL-адреса

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

Уровни общего доступа включают:

• Уровень выполнения
• Уровень результатов
• Отдельная вкладка, выбранная в тестовом запуске
• Общий доступ также совместим с любыми вкладками расширений, настроенными

При совместном использовании URL-адреса зрители увидят результаты тестового выполнения в полноэкранном представлении.

Artifacts

Пакеты NuGet с номерами версий SemVer 2.0.0

Ранее azure Artifacts не поддерживали пакеты NuGet с номерами версий SemVer 2.0.0 (как правило, номера версий, содержащие часть метаданных сборки версии, которая обозначается параметром +). Теперь можно сохранить пакеты из nuget.org, которые содержат метаданные сборки и отправлять собственные пакеты с метаданными сборки. В спецификации SemVer и политике NuGet.org метаданные сборки нельзя использовать для заказа пакетов. Таким образом, нельзя публиковать 1.0.0+build1 и 1.0.0+build2 в Azure Artifacts (или nuget.org), так как эти версии будут считаться эквивалентными и, таким образом, подвержены ограничениям неизменяемости.

Сведения о происхождении пакетов

С помощью этого обновления мы немного облегчили понимание происхождения пакетов: кто или что опубликовал их, а также какие фиксации исходного кода они были получены. Эти сведения заполняются автоматически для всех пакетов, опубликованных с помощью задач NuGet, npm, Maven и Twine Authenticate (для Python) в Azure Pipelines.

Статистика использования пакетов

До сих пор Артефакты Azure не предоставляют способ оценить использование или популярность пакетов. В этом обновлении мы добавили количество скачивание и пользователей в список пакетов и страницы сведений о пакете. Статистика отображается справа от любой страницы.

Поддержка пакетов Python

Теперь артефакты Azure могут размещать пакеты Python: оба пакета создаются самостоятельно и вышестоящий пакеты, сохраненные из общедоступного PyPI. Дополнительные сведения см. в записи блога объявлений и документах.

Теперь вы можете разместить все пакеты NuGet, npm, Maven и Python в одном канале.

вышестоящие источники для Maven.

Теперь источники вышестоящего потока доступны для веб-каналов Maven. Это включает в себя основной репозиторий Maven Central и веб-каналы Артефактов Azure. Чтобы добавить maven вышестоящий в существующий веб-канал, перейдите к параметрам канала, выберите сводную таблицу источников вышестоящего канала, а затем нажмите кнопку "Добавить вышестоящий источник".

поддержка прокси-серверов в задачах, связанных с артефактами;

До сих пор многие задачи сборки, связанные с Артефактами, не обеспечивают полную поддержку прокси-инфраструктуры Azure Pipelines, что привело к проблемам с использованием задач из локальных агентов. В этом обновлении мы добавили поддержку прокси-серверов в следующие задачи:

• Npm@1 ('npm' в конструкторе)
• NuGetCommand@2 (NuGet в конструкторе): восстановление и отправка команд только
• DotNetCoreCLI@2 ('.NET Core' в конструкторе): только команды восстановления и отправки nuget
• NpmAuthenticate@0, PipAuthenticate@0 и TwineAuthenticate@0 ("[тип] Проверка подлинности" в конструкторе): эти задачи поддерживают прокси-серверы во время приобретения маркеров проверки подлинности, но для использования прокси-сервера все равно необходимо настроить все последующие задачи/ скрипты и средства. Другими способами эти задачи не настраивают прокси-сервер для базового инструмента (npm, pip, twine).
• NuGetToolInstaller@0, NodeTool@0, DotNetCoreInstaller@0 ('[тип] Установщик в конструкторе)

поддержка всех типов пакетов Artifacts в выпусках;

До сих пор в выпусках Pipelines поддерживаются только пакеты NuGet в типе артефактов Azure Artifacts. При этом обновлении поддерживаются все типы пакетов Azure Artifacts — Maven, npm и Python.

поддержка представлений Artifacts в выпусках;

Ранее тип артефактов Azure Artifacts мог активироваться только при публикации новых версий пакетов в веб-канале. Теперь мы также добавили поддержку представлений, поэтому вы можете активировать выпуски, когда пакеты уже в веб-канале повышены до представления.

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

До сих пор веб-каналы Azure Artifacts предложили основные политики хранения, которые начнут удалять старые версии пакетов, когда достигнуто "максимальное количество версий на пакет". В этом обновлении мы добавили возможность пропускать недавно загруженные пакеты при выполнении этой очистки. Чтобы включить, измените веб-канал и проверка скачанные недавно пакеты skip проверка box.

делегирование прав управления веб-каналами.

В Azure Artifacts коллекция проектов Администратор istrator ( PCAs) всегда была в состоянии администрировать все веб-каналы на сервере Azure DevOps. С помощью этого обновления ЦС также может предоставить этому возможность другим пользователям и группам, что позволяет делегировать возможность управления любым веб-каналом.

Вики

Шаблоны Markdown для формул и видео

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

Внедрение запросов Azure Boards в вики-сайт

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

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

1. Нажмите кнопку "Результаты запроса" на панели инструментов редактирования.

2. Выберите необходимый запрос и нажмите кнопку "Вставить".

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

Шрифт Monospaced для редактора Wiki Markdown

С введением монопространствированных шрифтов для редактора wiki Markdown возможность чтения больше не является проблемой. Источник Markdown выглядит чистым и простым для чтения. Эта функция была назначена приоритетом на основе этого запроса предложения.

Пермалинки для вики-страниц

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

Эта функция была приоритетна на основе этого запроса предложения.

Отображение состояния рабочего элемента на вики-страницах

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

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

@mention пользователи и группы

Теперь пользователи и группы можно использовать @mention на вики-странице. Это делает документы, такие как страница контактов группы, документы руководства и документы знаний более богаты. На рисунке ниже показан пример ретроспективного спринта с задачами и ответственным лицом.

@упоминание пользователей и групп». />

Кроме того, вы также можете выбрать пользователя или группу из автозаполнения, введя "@" на странице вики-редактирования. Пользователь, упоминание которого также получит уведомление по почте.

@упоминание". />

Наконец, вы также можете щелкнуть @mentioned пользователя, чтобы просмотреть сведения о профиле карта. Эта функция была назначена приоритетом на основе этого предложения функции.

уведомления на вики-страницах.

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

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

Поддержка HTML-тегов

Теперь вы можете создать более подробное содержимое в вики-сайте с помощью HTML-тегов. Ознакомьтесь с тем, что можно сделать с html-тегами ниже.

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

   

   Дополнительные сведения о теге сведений см. в документации.

   Это было приоритетом на основе этого запроса предложения.

   Примечание.

   Этот тег не поддерживается в браузерах Edge и Internet Обозреватель.

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

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

1. Создание таблицы из сетки

   Вам больше не нужно запоминать синтаксис таблицы Markdown. Теперь вы можете легко создать таблицу markdown, выбрав из сетки 15 X 15. Просто выберите необходимое количество столбцов и строк для вставки таблицы одним щелчком мыши.

   

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

   • Представление таблицы для вики-сайта
   • Упрощение вставки таблиц в вики-сайт

2. Улучшена удобочитаемость таблицы

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

   

3. Автоматическое заполнение таблиц markdown

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

   

   Для форматирования таблиц можно также использовать сочетание клавиш CTRL+SHIFT+F .

Отчетность

Расширение Аналитики больше не требуется для использования аналитики

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

Для обновления 1 мы рады сообщить, что клиентам больше не нужен расширение Analytics для использования Аналитики. Теперь клиенты могут включить аналитику в Параметры коллекции проектов. Это простой процесс, который находится прямо в продукте.

Вот как клиенты могут включить аналитику:

1. Перейдите к коллекции проектов Параметры:

2. Нажмите кнопку "Включить аналитику "

Вот и все! Возможности аналитики будут включены для коллекции.

Новые коллекции, созданные в коллекциях с обновлением 1 и Azure DevOps Server 2019 с установленным расширением Analytics, которые были обновлены, будут включены по умолчанию для аналитики.

Дополнительные сведения об аналитике и возможностях, которые он включает:

• Дополнительные сведения о включении Аналитики.
• Ознакомьтесь с документацией по аналитике.
• Ознакомьтесь с ключевыми функциями: мини-приложения аналитики, основные тестовые отчеты, интеграция Power BI и конечная точка OData.
• Просмотрите это видео канала 9 в Azure DevOps Analytics.

---

Отзывы

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

---

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