Заметки о выпуске Azure DevOps Server 2019, обновление 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 2019 с обновлением 1.2 Patch 10: 11 марта 2025 г.

Файл	Хэш SHA-256
devops2019.1.2patch10.exe	EDCE91E3F92A2E60FB9BA9BE6977B47BC794817A13766C728B97D4B83039B789

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

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

Дата выпуска Azure DevOps Server 2019 Обновление 1.2 Патч 9: 28 мая 2024 г.

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

Мы выпустили исправление 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 2019: 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	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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.  

Замечание

Чтобы предотвратить понижение агента, параметр AZP_AGENT_DOWNGRADE_DISABLED должен быть установлен в значение true. В 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.
• Обновите службу SSH для поддержки SHA2-256 и SHA2-512. Если файлы конфигурации SSH жестко закодированы для использования RSA, необходимо обновить до SHA2 или удалить запись.
• Исправлена ошибка бесконечного цикла в CronScheduleJobExtension.

Дата выпуска Patch 3 для Azure DevOps Server 2019, обновление 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 Update 1.1 Patch 13: 26 января 2022 г.

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

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

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

1. Обновите сервер, установив Patch 13.
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. Обновите сервер исправлением 13.
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: 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 Patch 10: 10 августа 2021 г.

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

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

Дата выхода патча 9 для Azure DevOps Server 2019 Update 1.1: 15 июня 2021 г.

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

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

Дата выпуска пакета обновления 8 для Azure DevOps Server 2019 Update 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 CheckInstall devops2019.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 Patch 7 для Azure DevOps Server 2019: 12 января 2021 г.

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

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

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

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

• CVE-2020-1325: уязвимость подмены в сервере Azure DevOps
• CVE-2020-17135: уязвимость подмены сервера 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 CheckInstall, devops2019.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: 8 сентября 2020 г.

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

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

Дата выхода Azure DevOps Server 2019 Update 1.1 Patch 4: 14 июля 2020 г.

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

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

Дата выпуска Azure DevOps Server 2019, обновление 1.1, патч 3: 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

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

Azure Pipelines (система конвейеров Azure)

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

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

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

Общая информация

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

Администрация

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

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

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

---

Дата выпуска патча 1 для Azure DevOps Server 2019 Update 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 в вики-сайт
• Пермалинки для вики-страниц
• Уведомления на вики-страницах
• Расширение Аналитики больше не требуется для использования аналитики

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

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

---

Общая информация

Темная тема

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

Советы

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

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

Новый базовый процесс предоставляет три типа рабочих элементов (Эпики, Проблемы и Задачи) для планирования и отслеживания работы. Мы рекомендуем использовать проблемы для отслеживания таких проблем, как истории пользователей, ошибки и функции при использовании 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, теперь вы можете.

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

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

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

Репозитории

Черновые пулл-реквесты

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

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

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

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

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

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

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

Замечание

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

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

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

Новые типы слияния для завершения пулл-реквестов.

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

Теперь вы увидите эти новые параметры, доступные в диалоговом окне «Полный pull request».

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

Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поддержка команды 'go get' в Azure Repos.

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

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

Веб-редактор с 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, включая 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 Service Bus.

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

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

• Стратегия развертывания — выбор канареечной стратегии с действием развертывания приводит к созданию требуемого процента рабочих нагрузок с суффиксами -baseline и -canary для их сравнения во время 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) для задачи Azure SQL

Задача Azure SQL была обновлена для поддержки подключения к базе данных с помощью 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***

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

Виджет тренда результатов теста (расширенный)

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

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

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

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

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

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

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

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

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

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

Артефакты

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

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

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

С помощью этого обновления мы немного облегчили понимание происхождения пакетов: кто или что их опубликовал, а также из каких коммитов исходного кода они происходят. Эти сведения заполняются автоматически для всех пакетов, опубликованных с помощью задач 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' в конструкторе): только команды restore и nuget push
• 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.

Поддержка представлений артефактов в релизах.

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

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

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

Делегат, который может управлять лентами.

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

Вики

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

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

Встраивание результатов запросов Azure Boards в Вики

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

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

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

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

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

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

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

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

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

Приоритет этой функции был основан на этом предложении/тикете.

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

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

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

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

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

@mention пользователей и групп". />

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

@mention". />

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

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

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

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

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

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

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

   

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

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

   Замечание

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

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

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

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

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

   

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

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

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

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

   

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

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

   

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

Отчётность

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

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

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

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

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

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

Вот и все! Аналитически управляемые функции будут включены для коллекции.

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

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

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

---

Отзывы

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

---

Вверх страницы