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

| Сообщество разработчиков Условий лицензионного соглашения | | 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.0.1 с исправлением 16: 14 ноября 2023 г.

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

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

Примечание.

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

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

Внимание

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

Дата выпуска Azure DevOps Server 2019.0.1 с исправлением 15: 12 сентября 2023 г.

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

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

Внимание

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

Примечание.

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

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

1. Скачайте и установите Azure DevOps Server 2019.0.1 с исправлением 15.

Обновление агента 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 

Дата выпуска Azure DevOps Server 2019.0.1 с исправлением 14: 8 августа 2022 г.

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

• CVE-2023-36869: уязвимость сервера Azure DevOps Server Spoofing.

Дата выпуска Azure DevOps Server 2019.0.1 с исправлением 13: 17 мая 2022 г.

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

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

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

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

• Устранена уязвимость Elasticsearch за счет удаления класса JndiLookup из двоичных файлов Log4j.

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

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

Дата выпуска Azure DevOps Server 2019.0.1 с исправлением 11: 10 августа 2021 г.

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

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

Дата выпуска Azure DevOps Server 2019.0.1 с исправлением 10: 13 апреля 2021 г.

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

• CVE-2021-27067: раскрытие информации

Чтобы применить исправление AzureResourceGroupDeploymentV2 10, необходимо установить задачу.

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

Примечание.

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

Установка

1. Извлеките пакет AzureResourceGroupDeploymentV2.zip в новую папку на компьютере. Например: 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>*

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

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

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

Внимание

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

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

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

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

• Вариант 1. Запуск devops2019.0.1patch9.exe CheckInstalldevops2019.0.1patch9.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.0.1 Patch 9 версия будет 17.143.30723.4.

Установка задач 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 (1)\AzurePowerShellv4.

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

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

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

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

Дата выпуска Azure DevOps Server 2019.0.1 с исправлением 7: 14 июля 2020 г.

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

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

Дата выпуска Azure DevOps Server 2019.0.1 с исправлением 6: 10 июня 2020 г.

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

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

Дата выпуска Azure DevOps Server 2019.0.1 с исправлением 5: 10 марта 2020 г.

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

• CVE-2020-0700: уязвимость для межсайтовых сценариев
• CVE-2020-0758: уязвимость к повышению привилегий
• CVE 2020-0815: уязвимость с повышением привилегий

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

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

• CVE-2019-1305: уязвимость межсайтовых сценариев (XSS) в Репозитории
• CVE-2019-1306: уязвимость удаленного выполнения кода в Вики-сайте

---

Дата выпуска Azure DevOps Server 2019.0.1 с исправлением 2: 13 августа 2019 г.

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

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

---

Дата выпуска Azure DevOps Server 2019.0.1 с исправлением 1: 9 июля 2019 г.

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

• CVE-2019-1072: уязвимость удаленного выполнения кода в отслеживании рабочих элементов
• CVE-2019-1076: уязвимость межсайтовых сценариев (XSS) в запросах на вытягивание

---

Дата выпуска Azure DevOps Server 2019.0.1: 21 мая 2019 г.

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

Примечание.

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

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

Azure Boards

• "Критерии поля для этого плана имеют ошибку". При настройке плана. Сообщается через Сообщество разработчиков.
• apiwitcontroller.executequery создает исключение, если запрос имеет один и тот же столбец несколько раз.
• В клиентской объектной модели с помощью области oauth vso.work_full сбой WorkItemServer.DownloadFile().
• Копирование внедренного изображения из поля рабочего элемента в другое поле рабочего элемента в другом проекте может создать сломанное изображение.

Azure Repos

• "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

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

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

• Фильтр на 1 час в TestRuns и TestResults CompletedDate слишком детализирован.
• В типе рабочего элемента Test Case тип "Тестовый случай" не должен быть локализован.
• Тестовые случаи не отображаются в MTM или браузере.
• "Проверка этапа: у вас нет разрешения на активацию выпусков в связанном конвейере выпуска" при выполнении автоматических тестов из плана тестирования. Сообщается через Сообщество разработчиков.
• С помощью API тестового случая удаления тестовые случаи можно удалить из других проектов. Сообщается через Сообщество разработчиков.
• Щелкнув ссылку на рабочий элемент в тестовом runner, откроется URL-адрес рабочего элемента внутри тестового модуля Runner вместо браузера по умолчанию.
• Состояние тестового случая не обновляется для пользователей, которые выходят из тестового runner.
• Имя пользователя и адрес электронной почты не отображаются в раскрывающемся списке пользователя в тестовом runner.

Azure Artifacts

• Перемещение вверх и перемещение вниз не локализованы в вышестоящих потоках.

Аналитика

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

Общие

• Элементы навигации слева сжимаются в IE, если недостаточно места.

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

• Дополнительное ведение журнала, добавленное в обновление коллекции, чтобы помочь отладить проблемы.
• Если TfsConfig offlineDetach завершается сбоем, сообщение об ошибке невозможно выполнить.
• Служба TfsJobAgent завершает работу.
• Расширение поиска не устанавливается после завершения настройки.
• Консоль администрирования не отвечает при повреждении базы данных конфигурации.
• Перехватчики служб могут неправильно обрабатывать уведомления.
• Индексирование поиска кода не начинается после настройки поиска.
• В результатах страниц поиска есть нелокализованные строки.

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

Поддержка Visual Studio 2019 (VS2019) в задаче тестирования Visual Studio

Мы добавили поддержку Visual Studio 2019 в задачу Тестирования Visual Studio в конвейерах. Чтобы выполнить тесты с помощью тестовой платформы для Visual Studio 2019, выберите параметры последней версии или Visual Studio 2019 в раскрывающемся списке версии платформы тестирования.

---

Дата выпуска Azure DevOps Server 2019 с исправлением 2: 14 мая 2019 г.

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

• CVE-2019-0872: уязвимость межсайтовых сценариев (XSS) в планах тестирования
• CVE-2019-0971: уязвимость раскрытия информации в API Repos
• CVE-2019-0979: уязвимость межсайтовых сценариев (XSS) в центре пользователей

---

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

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

• CVE-2019-0857: уязвимость spoofing в вики-сайте
• CVE-2019-0866: уязвимость удаленного выполнения кода в конвейерах
• CVE-2019-0867: уязвимость межсайтовых сценариев (XSS) в конвейерах
• CVE-2019-0868: уязвимость межсайтовых сценариев (XSS) в конвейерах
• CVE-2019-0869: уязвимость внедрения HTML в конвейерах
• CVE-2019-0870: уязвимость межсайтовых сценариев (XSS) в конвейерах
• CVE-2019-0871: уязвимость межсайтовых сценариев (XSS) в конвейерах
• CVE-2019-0874: уязвимость межсайтовых сценариев (XSS) в конвейерах
• CVE-2019-0875: уязвимость с повышением привилегий в Boards

---

Дата выпуска Azure DevOps Server 2019: 5 марта 2019 г.

Примечание.

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

---

Дата выпуска RC2: 22 января 2019 г.

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

Мы добавили следующие функции в RC2:

• Связывание фиксаций GitHub Enterprise и запросов на вытягивание рабочих элементов Azure Boards
• Настройка сборок с помощью YAML
• Заметки к карточкам включают ошибки и типы настраиваемых рабочих элементов
• Улучшенное средство выбора ветвей
• Изменения в лицензировании конвейера развертывания артефактов и управления выпусками

---

Дата выпуска RC1: 19 ноября 2018 г.

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

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

• Новый интерфейс навигации
• Теперь доступно расширение Marketplace аналитики для создания отчетов
• Поддержка База данных SQL Azure
• Наследование процессов в новых коллекциях
• Центр новых рабочих элементов
• Новые советы, невыполненные работы и центры Sprints
• Новый центр запросов
• Стандартизация описания запросов на вытягивание с помощью шаблонов
• Изменение целевой ветви запроса на вытягивание
• Управление конвейерами сборки с помощью новой страницы "Сборки"
• Управление конвейерами выпуска с помощью новой страницы выпусков
• Визуализация хода выполнения выпуска
• Локальное обновление агента
• Постепенное предоставление и поэтапное развертывание с помощью шлюзов выпуска
• Источники вышестоящего потока
• Создание оглавление для вики-страниц

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

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

---

Общие

Объявление о сервере Azure DevOps

10 сентября мы объявили Azure DevOps в качестве эволюции Visual Studio Team Services и Team Foundation Server. Azure DevOps Server 2019 — это наш первый локальный выпуск с новым брендом. Дополнительные сведения см. в записи блога.

Новый интерфейс навигации

Мы представляем новую навигацию для модернизации пользовательского интерфейса. Эта новая навигация развернута в службе Azure DevOps и теперь доступна в Azure DevOps Server 2019. Дополнительные сведения см . в нашем блоге .

Изменения в лицензировании конвейера развертывания артефактов и управления выпусками

На основе отзывов пользователей мы делаем два ключевых изменения в наших лицензиях с помощью Azure DevOps Server 2019. Во-первых, клиентам больше не потребуется приобрести расширение Artifact для использования артефактов. Теперь использование лицензии артефактов будет включено в базовую лицензию. Теперь все пользователи, которым назначена базовая лицензия, смогут использовать артефакты. Во-вторых, клиентам больше не потребуется приобрести конвейеры развертывания управления выпусками. Как и конвейеры сборки, конвейеры развертывания выпуска теперь включены в Azure DevOps Server 2019.

Поддержка База данных SQL Azure

Чтобы упростить работу Azure DevOps 2019 в Azure, мы включили поддержку База данных SQL Azure (S3 общего назначения и выше). Это позволит использовать обширные функции резервного копирования и параметры масштабирования в соответствии с вашими потребностями, уменьшая административные расходы на выполнение службы. Обратите внимание, что виртуальная машина узла должна находиться в том же регионе Azure, что и база данных, чтобы обеспечить низкую задержку. Дополнительные сведения см. в документации.

Рабочие элементы и тестируйте API-интерфейсы SOAP клиентской объектной модели в будущих версиях

Azure DevOps Server 2019 продолжает поддерживать API отслеживания рабочих элементов SOAP и клиентской объектной модели. Однако она будет помечена как нерекомендуемая в будущих версиях Azure DevOps Server. Дополнительные сведения см. в нашей документации.

Наследование процессов в новых коллекциях

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

Расширенное окно поиска

Мы понимаем важность поиска и возвращаем развернутое поле поиска в заголовке продукта. Кроме того, теперь можно вызвать поле поиска, просто щелкнув "/" на любой странице службы в Azure DevOps.

Ниже приведено поле поиска по умолчанию:

После ввода "/" появится развернутое поле поиска:

Всплывающий элемент "Моя работа"

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

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

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

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

Boards

Связывание фиксаций GitHub Enterprise и запросов на вытягивание рабочих элементов Azure Boards

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

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

AB#{work item ID}

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

Adds support for deleting connections. Fixes AB#20.

Это создаст ссылку из рабочего элемента #20 на фиксацию в GitHub, которая появится в разделе разработки рабочего элемента. ​

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

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

Центр новых рабочих элементов

Центр рабочих элементов — это наш новый центр, который будет служить домом ваших рабочих элементов! Здесь у вас есть множество различных представлений списка рабочих элементов, которые находятся в области. Вы можете просмотреть назначенные мне рабочие элементы, чтобы быстро просмотреть всю работу, назначенную вам или недавно обновленную, которая показывает все рабочие элементы в проекте, которые были недавно обновлены. Ниже приведены все параметры списка:

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

Новые советы, невыполненные работы и центры Sprints

Центр невыполненных работ был разделен на три разных центра, чтобы улучшить взаимодействие с пользователем. Хотя мощный, старый центр Невыполненных работ был домом для слишком много функций. Это часто затрудняет поиск функции или возможностей пользователей. Чтобы устранить эту проблему, мы разбили центр невыполненных работ на:

• Центр невыполненных работ теперь является домом только невыполненных работ для проекта. Невыполненная работа — это приоритетный список работ для команды. Невыполненные работы предоставляют такие средства планирования, как иерархия рабочих элементов, прогнозирование и новый интерфейс планирования спринта.
• Новый центр Boards является домом для всех Kanban Boards для проекта. Доски используются для обмена данными о состоянии и потоке. Карточки (рабочие элементы) перемещаются слева направо через столбцы, определенные командой.
• Новый центр Sprints является домом для функций, используемых для планирования и выполнения добавок работы. Каждый спринт содержит невыполненную работу по спринту, доску задач и представление для управления и задания емкости для команды.

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

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

• Страницы каталогов с последней измененной информацией и возможность поиска запросов
• Поиск с уникальными URL-адресами для папок для закладки важных групп запросов
• Быстрый доступ к избранным запросам на странице результатов

Узнайте больше об этих захватывающих обновлениях в нашем блоге DevOps.

Перемещение рабочих элементов в другой проект и изменение типа рабочего элемента

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

Функции планирования спринта

Новые функции планирования спринта помогают ускорить и улучшить процесс планирования спринта.

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

Новые страницы каталога

Все новые центры, включая невыполненные работы, Boards и Sprints, теперь имеют новые страницы каталогов, организованные со следующими разделами:

• Продолжить, где вы оставили этот новый раздел, предоставляет быструю ссылку непосредственно на последнюю (Board | Невыполненная работа | Спринт) вы были на.
• Избранное всех избранных досок, спринтов и невыполненных работ во всех командах.
• Мои все доски, невыполненные работы и спринты для команд, к которому вы принадлежите.
• Полный список всех ваших досок, невыполненных работ и спринтов.

Меню "Новые параметры представления"

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

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

Заметки к карточкам включают ошибки и типы настраиваемых рабочих элементов

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

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

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

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

Перемещение работы с помощью предлагаемых областей и итераций

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

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

Выполнение запросов по расписанию итерации с помощью +/- @CurrentIteration

Макрос @CurrentIteration , помогающий команде отслеживать работу на основе расписания итерации, теперь поддерживает смещение целых чисел. Легко держать вкладки на работе, которая не была закрыта с @CurrentIteration - 1, или посмотрите на работу, запланированную для будущих итерации с @CurrentIteration + 1. Дополнительные сведения см. в записи @CurrentIteration блога Microsoft DevOps.

Уточнение расписаний итерации запросов с помощью @CurrentIteration параметра Team

Если вы использовали @CurrentIteration макрос в запросах в прошлом, возможно, вы заметили, что результаты могут отличаться, если контекст команды изменяется в Teams с различными расписаниями итерации. Теперь при создании или изменении запроса с @CurrentIteration помощью макроса вам потребуется также выбрать команду с расписанием итерации, соответствующим запросу. С помощью параметра Team можно использовать @CurrentIteration макрос в одном запросе, но в разных командах. Одним из примеров может быть запрос на рабочие элементы в двух разных командных проектах с использованием разных имен итерации и даже расписаний. Это означает, что больше не нужно обновлять запросы по мере изменения спринтов! Дополнительные сведения см. в записи @CurrentIteration блога Microsoft DevOps.

Запрос работает в пути к области команды с новым @TeamAreas макросом

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

Запрос пустых полей форматированного текста

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

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

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

Открытие рабочих элементов со страницы поиска.

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

Repos

Улучшенное средство выбора ветвей

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

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

Для команд, использующих запросы на вытягивание (PR) и политики ветви, могут возникнуть случаи, когда людям нужно переопределить и обойти эти политики, например при развертывании исправления в рабочей проблеме в середине ночи. Имеет смысл доверять разработчикам делать правильные вещи и использовать переопределение возможностей смешно. В то же время командам необходимо убедиться, что эти переопределения политики используются в правильных ситуациях. Для поддержки этого мы добавили новый фильтр уведомлений, позволяющий пользователям и командам получать оповещения электронной почты в любое время обхода политики. Начните с создания или обновления шаблона запроса на вытягивание и выберите "Обход политики" из списка фильтров. Выбор политик был обходить как значение, и вы будете получать уведомления в любое время завершения pr и политики обходятся.

Разрешить обход политик ветвей без отказа от принудительной защиты

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

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

1. Обход политик при выполнении запросов на вытягивание. Пользователи с этим разрешением смогут использовать интерфейс Override для запросов на вытягивание.
2. Обход политик при отправке. Пользователи с этим разрешением смогут отправлять непосредственно в ветви, для которых настроены необходимые политики.

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

Примечание.

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

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

Быстрое описание запросов на вытягивание с помощью сообщений фиксации

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

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

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

Когда мы впервые запустили интерфейс запроса на вытягивание (PR), мы думали, что имеет смысл назначить все PR контексту команды, выбранному при создании PR. Это поведение было точкой разочарования, так как многие люди не заметили связь между контекстом команды и назначением PR.

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

1. При создании PR рецензенты по умолчанию не добавляются. Список рецензентов имеет функцию, чтобы упростить добавление отдельных лиц и групп, которые были добавлены в PR недавно. Политика обязательных рецензентов также может помочь командам, которые хотят убедиться, что определенные рецензенты добавляются для проверки кода.
2. Центр запросов на вытягивание содержит новый настраиваемый раздел. По умолчанию в этом разделе показаны PR "Назначены моим командам", предоставляя эквивалентные функциональные возможности в качестве старого раздела. Однако если вы принадлежите нескольким командам, в этом разделе будут отображаться PR, назначенные любой из команд. Этот раздел также настраивается. Просто щелкните действие "Настроить это представление" рядом с заголовком раздела.

Стандартизация описания запросов на вытягивание с помощью шаблонов

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

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

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

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

Изменение целевой ветви запроса на вытягивание

Для большинства команд почти все запросы на вытягивание нацелены на одну и ту же ветвь, например main или develop. Однако в случае, когда вам нужно выбрать другую ветвь, легко забыть изменить целевую ветвь по умолчанию. Благодаря новой функции для изменения целевой ветви активного запроса на вытягивание теперь это простое действие. Щелкните значок карандаша рядом с именем целевой ветви в заголовке запроса на вытягивание.

Помимо простого исправления ошибок, функция изменения целевых ветвей также упрощает "перенацеливание" запроса на вытягивание при слиянии или удалении целевой ветви. Рассмотрим сценарий, в котором вы используете pr, предназначенный для ветвь компонента который содержит некоторые функции, от которых зависят изменения. Вы хотите просмотреть зависимые изменения в изоляции от других изменений в ветвь компонента, поэтому вы изначально нацелены features/new-featureна нее. Затем рецензенты могут видеть только ваши изменения и оставлять соответствующие комментарии.

Теперь рассмотрим, что произойдет, если ветвь компонента также был активен PR и был объединен main перед вашими изменениями? Ранее вам придется отказаться от изменений и создать новый PR в main, или объединить ваш PR в features/new-feature, а затем создать другой PR из features/new-feature main. При этом новом действии для обновления целевой ветви можно просто изменить целевую ветвь PR с features/new-feature mainнуля, сохранив все контекст и комментарии. Изменение целевой ветви даже создает новое обновление на PR, что упрощает просмотр предыдущих диффов перед изменением целевой ветви.

Авторы расширений могут запрашивать контекст для текущего репозитория.

Одной из проблем для автора расширения управления версиями является получение контекста репозитория, отображаемого пользователю, например имя, идентификатор и URL-адрес. Для этого мы добавили VersionControlRepositoryService в качестве службы, доступной для расширений. С помощью этого автор расширения может запрашивать сведения о текущем контексте репозитория Git в пользовательском веб-интерфейсе. В настоящее время он имеет один метод getCurrentGitRepository().

• Если выбран репозиторий Git, объект GitRepository возвращается с основными данными о репозитории (имя, идентификатор и URL-адрес)
• Если выбран репозиторий TFVC или служба обращается за пределами страниц Azure Repos, возвращается значение NULL.

Ниже приведен пример расширения , использующего эту службу.

Pipelines

Управление конвейерами сборки с помощью новой страницы "Сборки"

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

Управление электронными письмами о завершении сборки и развертывания лучше с помощью улучшенного форматирования

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

Элементы нового формата:

• [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
• [Deployment result] [pipeline name] > [release name] : [stage name]

Вот несколько таких случаев.

• [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
• [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

Следуйте новой унифицированной терминологии Azure Pipelines

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

Терминология была унифицирована в Azure Pipelines для уточнения ее концепций. Теперь вы увидите следующие унифицированные термины:

Предыдущий термин	Унифицированный термин	Значение
Размещенный агент	Размещенный агент Майкрософт	Агент сборки и выпуска, работающий в облачной инфраструктуре, управляемой корпорацией Майкрософт.
Частный агент	Локальный агент	Агент сборки и выпуска, который выполняется на компьютере, предоставленном и управляемом вами.
Пул агентов	Пул агентов	Набор компьютеров агента уровня организации, которые могут выполнять сборки или выпуски.
Очередь агента	Пул агентов	Набор компьютеров агента на уровне проекта, которые могут выполнять сборки или выпуски. Он связан с пулом агентов уровня организации.
Определение сборки	Создание конвейера	Комплексный набор шагов сборки для приложения.
Сборка	Сборка	Экземпляр конвейера сборки, запущенного или запущенного.
Этап	Работа	Ряд задач, которые выполняются последовательно или параллельно на агенте. Конвейер сборки или выпуска может содержать одно задание или график нескольких заданий.
Определение выпуска	Конвейер выпуска	Комплексный набор шагов выпуска для развертывания приложения на различных этапах.
Выпуск	Выпуск	Экземпляр конвейера выпуска, запущенного или запущенного.
Среда	Этап	Логическая и независимая сущность, представляющая место развертывания выпуска, созданного из конвейера выпуска.
Параллельное задание или конвейер	Параллельное задание	Параллельное задание позволяет выполнять одно задание сборки или выпуска в вашей организации. С более параллельными заданиями можно одновременно запускать больше заданий сборки и выпуска.
Конечная точка службы	Подключение службы	Группа параметров, например учетные данные, используемая для подключения к внешним службам для выполнения задач в сборке или выпуске.

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

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

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

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

Визуализация хода выполнения выпуска

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

Сведения о конвейере, выпуске и средах

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

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

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

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

Фиксации и рабочие элементы

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

Ход развертывания и журналы

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

Вы можете щелкнуть журналы, чтобы ввести фокусное представление.

Влияние обновления на Azure DevOps Server 2019 на задачи: копирование файлов Windows Machine Copy и PoweShell на целевом компьютере

Группы компьютеров в Test Hub устарели в TFS 2017 RTM. С помощью Azure DevOps Server 2019 служба групп компьютеров больше не доступна. Это повлияет на пользователей задачи "Копирование файлов компьютеров Windows" версии 1.* и PowerShell на целевых компьютерах версии 1.*. Для продолжения работы конвейеров

• Необходимо переключиться на задачу "Копирование файлов компьютеров Windows" версии 2.* и указать полное полное доменное имя целевого компьютера, а не только имя компьютера.
• Перейдите на задачу PowerShell на целевом компьютере версии 2.* или более поздней и укажите полное полное доменное имя компьютера или компьютера, за которым следует порты удаленного управления Windows (http/https). Например, targetMachine:5985 или targetMachine:5986

Результаты тестирования и расширяемость

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

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

Настройка сборок с помощью YAML

Конвейеры сборки на основе YAML доступны на сервере Azure DevOps Server. Автоматизация конвейера непрерывной интеграции с помощью файла YAML, который установлен в репозиторий. Полный справочник по схеме YAML см . здесь.

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

Цепочка связанных сборок вместе с помощью триггеров завершения сборки

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

Теперь можно активировать сборку после успешного завершения другой сборки. Артефакты, созданные вышестоящей сборкой, можно скачать и использовать в последующей сборке, а также получить данные из этих переменных: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Дополнительные сведения см. в документации по триггерам сборки .

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

Локальное обновление агента

Для задач, устанавливаемых из коллекции, иногда требуется более новая версия агента конвейеров. Если сервер Azure DevOps может подключиться к Интернету, новые версии загружаются автоматически. В противном случае необходимо вручную обновить каждый агент. Начиная с этого выпуска, вы можете настроить сервер Azure DevOps для поиска файлов пакета агента на локальном диске, а не из Интернета. Это обеспечивает гибкость и контроль над доступными версиями агента, не предоставляя azure DevOps Server в Интернете.

URL-адрес индикатора состояния новой сборки

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

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

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

Для обеспечения обратной совместимости мы будем продолжать учитывать старые URL-адреса эмблемы сборки.

В сборки добавлены настраиваемые счетчики сборок.

Счетчики сборки предоставляют возможность уникального числа и сборок меток. Ранее для этого можно использовать специальную переменную $(rev:r). Теперь вы можете определить собственные переменные счетчика в определении сборки, которые автоматически увеличиваются при каждом запуске сборки. Это можно сделать на вкладке переменных определения. Эта новая функция обеспечивает большую мощность следующими способами:

• Можно определить настраиваемый счетчик и задать его начальное значение. Например, можно запустить счетчик с 100. $(rev:r) всегда начинается с 0.
• Для сброса счетчика можно использовать собственную пользовательскую логику. $(rev:r) привязан к поколению номеров сборки и автоматически сбрасывается при наличии нового префикса в номере сборки.
• Можно определить несколько счетчиков для каждого определения.
• Можно запросить значение счетчика за пределами сборки. Например, можно подсчитать количество сборок, которые выполняются с момента последнего сброса с помощью счетчика.

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

Проверки безопасности и соответствия Политик Azure в Pipelines

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

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

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

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

Сборка на платформах Linux, ARM и 32-разрядных платформах Windows.

Агент Azure Pipelines открытый код кроссплатформенный агент всегда поддерживается в 64-разрядной версии Windows, macOS и Linux. В этом выпуске мы представляем две новые поддерживаемые платформы: Linux/ARM и Windows/32-разрядная версия. Эти новые платформы дают возможность создавать на менее распространенных, но не менее важных платформах, таких как Raspberry Pi, компьютер Linux или ARM.

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

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

Просмотр выполнения выполняемых тестов

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

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

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

Просмотр сведений об отладке тестового запуска на полной странице

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

Просмотр журнала тестов в контексте

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

Просмотр прерванных тестов

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

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

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

Просмотрите сводные результаты теста

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

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

Примечание.

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

Просмотр тестовой аналитики в Pipelines

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

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

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

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

Упрощение определений с помощью нескольких задач без агента

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

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

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

Хранение развертываний до тех пор, пока шлюзы не будут согласованы

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

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

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

Непрерывное развертывание сборок, помеченных при обработке после сборки

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

Установка переменной во время выпуска

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

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

Передача переменных среды задачам

Авторы задач CI/CD могут задать новое свойство, showEnvironmentVariables в task.json передать переменные среды задачам. При этом дополнительный элемент управления отображается в задаче в редакторе сборки. Это доступно для задач PowerShell, Cmd и Bash .

Это позволяет реализовать два сценария:

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

Клонирование групп переменных.

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

Примечание.

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

Игнорировать шлюз выпуска для развертывания

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

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

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

Создание подключения службы Azure с использованием субъекта-службы, который выполняет аутентификацию на основе сертификата

Теперь можно определить подключение службы Azure к субъекту-службе и сертификату для проверки подлинности. Теперь подключение службы Azure поддерживает субъект-службу, который проходит проверку подлинности с помощью сертификата, теперь можно развернуть в Azure Stack , настроенном с помощью AD FS. Чтобы создать субъект-службу с проверкой подлинности сертификата, ознакомьтесь со статьей о создании субъекта-службы, который проходит проверку подлинности с помощью сертификата.

Поддержка запуска из пакета в развертываниях Службы приложений Azure.

Теперь задача развертывания службы приложение Azure (4.*) поддерживает RunFromPackage (ранее называется RunFromZip).

Служба приложений поддерживает ряд различных методов развертывания файлов, таких как msdeploy (aka WebDeploy), git, ARM и многое другое. Но все эти методы имеют ограничение. Файлы развертываются в папке wwwroot (в частности d:\home\site\wwwroot), а среда выполнения запускает файлы изтуда.

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

• Снижается риск возникновения проблем из-за блокировки копирования файлов.
• Можно выполнить развертывание в рабочее приложение (с помощью перезапуска).
• Обеспечивается надежность файлов, выполняемых в приложении.
• Повышает производительность развертываний служб приложение Azure.
• Может сократиться время "холодного запуска", особенно для функций JavaScript с большими деревьями пакетов npm.

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

Версия 4.* задачи развертывания службы приложение Azure теперь поддерживает развертывание собственного пользовательского контейнера для Функции Azure в Linux.

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

1. Встроенный образ контейнера: код приложения-функции и Azure предоставляет контейнер (встроенный режим образа), поэтому не требуется никаких конкретных знаний, связанных с Docker. Это поддерживается в существующей версии задачи Служба приложений Deploy.
2. Пользовательский образ контейнера. Мы улучшили задачу развертывания Служба приложений для поддержки развертывания пользовательских образов контейнеров в Функции Azure в Linux. Если функции требуют определенной языковой версии или требуют определенной зависимости или конфигурации, которая не предоставляется в встроенном образе, можно создать и развернуть пользовательский образ в Функции Azure в Linux с помощью Azure Pipelines.

Задача Xcode поддерживает новый выпуск Xcode 10

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

Упрощение развертывания в Kubernetes с помощью Helm

Helm — это средство, которое упрощает установку приложений Kubernetes и управление ими. Он также получил большую популярность и поддержку сообщества в прошлом году. Задача Helm в выпуске теперь доступна для упаковки и развертывания диаграмм Helm в Службе контейнеров Azure (AKS) или любом другом кластере Kubernetes.

С добавлением этой задачи Helm теперь вы можете настроить конвейер CI/CD на основе Helm для доставки контейнеров в кластер Kubernetes. Дополнительные сведения см. в документации по развертыванию с помощью Kubernetes в службе контейнеров Azure.

Управление версией Helm, используемой в выпуске

Задача установщика инструментов Helm получает определенную версию Helm из Интернета или кэша инструментов и добавляет ее в ПУТЬ агента (размещенного или закрытого). Используйте эту задачу, чтобы изменить версию Helm, используемую в последующих задачах, таких как задача командной строки .NET Core. Добавление этой задачи перед задачей Helm Deploy в определении сборки или выпуска гарантирует упаковку и развертывание приложения с правильной версией Helm. Эта задача также помогает при необходимости устанавливать средство kubectl , которое является необходимым условием для работы Helm.

Непрерывное развертывание в База данных Azure для MySQL

Теперь вы можете непрерывно развертывать в База данных Azure для MySQL — база данных MySQL Azure как услуга. Управление файлами скриптов MySQL в управлении версиями и непрерывное развертывание в рамках конвейера выпуска с помощью собственной задачи, а не скриптов PowerShell.

Использование улучшенных удаленных задач Windows PowerShell

Доступны новые и улучшенные задачи на основе Windows remote PowerShell. К этим улучшениям относятся несколько исправлений производительности и поддержка динамических журналов и команд вывода консоли, таких как write-Host и Write-Output.

Задача PowerShell для целевой задачи (версия: 3.*): можно добавить встроенный скрипт, изменить параметры PSSession, управлять "ErrorActionPreference" и завершиться стандартной ошибкой.

Задача копирования файлов Azure (версия: 2.*): поставляется с последней версией AzCopy (версии 7.1.0), которая устраняет проблему с GitHub.

Фильтрация ветвей для артефактов GitHub Enterprise или внешних артефактов Git

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

Создание приложений, написанных в Go

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

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

Выполнение встроенных или файловых скриптов Python в конвейере

Новая задача скрипта Python упрощает выполнение скриптов Python в конвейере. Задача будет запускать скрипт из файла Python (.py) в репозитории или вручную ввести скрипт в параметрах задачи, чтобы сохранить в составе конвейера. Задача будет использовать версию Python в пути или указать абсолютный путь к интерпретатору Python для использования.

Использование улучшенных выходных данных сборки и тестирования Xcode из xcpretty

xcpretty повышает удобочитаемость выходных данных xcodebuild и создает результаты теста в формате JUnit. Задача сборки Xcode теперь автоматически использует xcpretty, когда она доступна на компьютере агента, так как она находится в размещенных агентах macOS. Хотя выходные данные xcpretty могут быть разными и менее подробными, чем выходные данные xcodebuild, мы делаем все журналы xcodebuild доступными для каждой сборки.

Test Plans

Клиент тестового запуска (Планы тестирования Azure) для выполнения ручных тестов для классических приложений

Теперь можно использовать клиент тестового запуска (планы тестирования Azure) для выполнения ручных тестов для классических приложений. Это поможет вам перейти от Microsoft Test Manager к планам тестирования Azure. Пожалуйста, ознакомьтесь с нашим руководством здесь. С помощью клиента runner тестирования можно выполнять тесты вручную и записывать результаты теста для каждого шага теста. У вас также есть возможности сбора данных, такие как снимок экрана, журнал действий изображений и запись аудио. Если при тестировании возникла проблема, используйте средство запуска тестов для создания ошибки с помощью шагов тестирования, снимков экрана и примечаний, которые автоматически включены в ошибку.

Для тестового запуска (планы тестирования Azure) требуется однократное скачивание и установка средства выполнения. Выберите "Запустить для классического приложения ", как показано ниже.

Artifacts

Вышестоящие источники

Azure DevOps Server 2019 предоставляет существенные обновления для вышестоящих источников, доступных в веб-каналах Azure Artifacts:

• Вы можете добавить nuget.org вышестоящий источник в существующие веб-каналы, созданные в предыдущих выпусках TFS. Найдите баннер над пакетами веб-канала для получения дополнительных сведений, включая изменения поведения, которые следует учитывать перед обновлением.
• Вы можете добавить другие веб-каналы Azure DevOps Server в качестве вышестоящих источников в веб-канал, что означает, что вы можете использовать пакеты NuGet и npm из этих веб-каналов через веб-канал.

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

Следуйте пакетам

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

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

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

Simplify authentication using the new cross-platform Credential Provider for NuGet (Упрощенная аутентификация с помощью нового кроссплатформенного поставщика учетных данных для NuGet)

Взаимодействие с проверенными веб-каналами NuGet стало намного лучше. Новый поставщик учетных данных на основе .NET Core azure Artifacts работает с msbuild, dotnet и nuget(.exe) в Windows, macOS и Linux. В любое время, когда вы хотите использовать пакеты из веб-канала Артефактов Azure, поставщик учетных данных автоматически получит и сохранит маркер от имени используемого клиента NuGet. Вам больше не нужно вручную хранить маркер и управлять ими в файле конфигурации.

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

Compress symbols when publishing to a file share (Сжатие символов при публикации в общий файловый ресурс)

Мы обновили задачу индексов и публикации символов для поддержки сжатия символов при публикации в общей папке.

Вики

Публикация файлов markdown из репозитория Git в качестве вики-сайта

Разработчики создают документацию по API, пакетам SDK и "справочным документам, объясняющим код" в репозиториях кода. Затем читатели должны прокрутить код, чтобы найти нужную документацию. Теперь вы можете просто опубликовать файлы markdown из репозиториев кода и разместить их в Вики-сайте.

Начните с вики-сайта, нажав кнопку "Опубликовать код" в качестве вики-сайта. Затем можно указать папку в репозитории Git, которая должна быть повышена.

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

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

Ссылка на заголовки на странице

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

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

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

Embed a video in wiki (Вставка видео в вики-сайт)

Теперь вы можете внедрить видео на вики-страницу из веб-службы таких как Microsoft Stream и YouTube. Вы можете добавить внедренный URL-адрес видео с помощью следующего синтаксиса:

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Rename a wiki (Переименование вики-сайта)

Теперь вы можете переименовать вики-сайт в пользовательском интерфейсе вики-сайта и использовать REST API. В меню "Дополнительно" щелкните "Переименовать вики-сайт", чтобы дать вики-сайту запоминающееся имя.

Открытие страницы на новой вкладке

Теперь вы можете щелкнуть правой кнопкой мыши страницу вики-страницы и открыть ее на новой вкладке или просто нажать клавиши CTRL+ слева, чтобы открыть ее на новой вкладке.

Сохранение специальных символов в заголовках вики-страниц

Теперь вы можете создавать вики-страницы со специальными символами, такими как : < > * ? | -. Теперь страницы с заголовками, такими как "Часто задаваемые вопросы?" или "Руководство по настройке" можно создать в вики-сайте. Следующие символы претворяются в строки в кодировке UTF-8:

Символ	Закодированная строка
:	%3A
<	%3C
>	%3E
*	%2A
?	%3F
|	%7C
-	%2D

Просмотр сломанных ссылок

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

Исправление неработающих ссылок при перемещении страниц

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

Внимание

Не забудьте использовать []() синтаксис markdown для ссылок на страницы и тип ссылки на вики-страницы в рабочих элементах, чтобы разрешить вики-сайту находить и исправлять потенциально неисправные ссылки. URL-адреса и гиперссылки обычного текста в рабочих элементах не будут выбраны этой функцией.

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

Затем вы увидите список ссылок страницы и рабочих элементов, затронутых перед выполнением действий.

Создание оглавление для вики-страниц

Иногда вики-страницы могут быть длинными, с содержимым, организованным по нескольким заголовкам. Теперь можно добавить оглавление на любую страницу с по крайней мере одним заголовком с помощью синтаксиса [[_TOC_]] .

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

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

Метаданные Surface для вики-страниц и предварительного просмотра кода с помощью тегов YAML

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

Пример тегов YAML:

---
tag: post
title: Hello world
---

Пример тегов YAML со списком:

---
tags:
- post
- code
- web
title: Hello world
---

Публикация кода как вики-сайта с разрешениями на участие.

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

Отчетность

Теперь доступно расширение Marketplace аналитики для создания отчетов

Расширение Analytics Marketplace теперь доступно для Azure DevOps Server. Аналитика — это будущее отчетов для Azure DevOps и Azure DevOps Server. Установка расширения Analytics предоставляет расширенные мини-приложения, интеграцию Power BI и доступ OData.

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

Изучение журнала сборки с помощью нового мини-приложения панели мониторинга сборки

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

Внимание

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

---

Отзывы

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

---

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