Заметки о выпуске 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 2020.

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

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

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

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

Настройка TFX

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

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

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.  

Настройка 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.

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

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: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Дата выпуска 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: раскрытие информации

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

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

Установка

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

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

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 Boards

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

Azure Repos

• "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

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

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

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

Azure Artifacts

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

Аналитика

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

Общие

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

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

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

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

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

Мы добавили поддержку Visual Studio 2019 в задачу Visual Studio Test в конвейерах. Чтобы выполнить тесты с помощью тестовой платформы для 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: уязвимость подмены в Wiki
• CVE-2019-0866: уязвимость удаленного выполнения кода в конвейерах
• CVE-2019-0867: уязвимость межсайтовых сценариев (XSS) в конвейерах
• CVE-2019-0868: уязвимость межсайтовых сценариев (XSS) в пиплайнах
• CVE-2019-0869: уязвимость внедрения HTML в конвейерах
• CVE-2019-0870: уязвимость межсайтового скриптинга (XSS) в Пайплайнах
• CVE-2019-0871: уязвимость межсайтового скриптинга (XSS) в Pipelines
• CVE-2019-0874: уязвимость межсайтовых сценариев (XSS) в конвейерах
• CVE-2019-0875: уязвимость с повышением привилегий в Boards

Дата выпуска Azure DevOps Server 2019: 5 марта 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
• Новый центр запросов
• Стандартизировать описания pull-запросов с помощью шаблонов
• Изменить целевую ветку pull request
• Управление конвейерами сборки с помощью новой страницы "Сборки"
• Управление конвейерами выпуска с помощью новой страницы выпусков
• Визуализация хода выполнения релиза
• Локально обновите своего агента
• Постепенное предоставление и поэтапное развертывание с помощью шлюзов выпуска
• Входящие источники
• Создание оглавление для вики-страниц

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

• Общие сведения
• Таблицы
• 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.

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

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

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

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

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

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

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

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

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

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

Всплывающее окно "Моя работа"

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

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

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

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

Доски

Связать коммиты и pull-реквесты GitHub Enterprise с рабочими элементами Azure Boards

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

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

AB#{work item ID}

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

Adds support for deleting connections. Fixes AB#20.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Repos

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

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

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

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

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

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

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

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

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

Для получения дополнительной информации см. документацию по установке разрешений для ветки.

Быстрое описание pull-запросов с помощью сообщений коммитов

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

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

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

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

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

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

Стандартизируйте описания пул-запросов с помощью шаблонов

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

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

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

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

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

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

Помимо простого исправления ошибок, функция изменения целевых ветвей также упрощает "перенацеливание" запроса на вытягивание при слиянии или удалении целевой ветви. Рассмотрим сценарий, в котором вы используете pull request, предназначенный для фиче-ветки, который содержит функциональность, от которой зависят ваши изменения. Вы хотите просмотреть зависимые изменения в изоляции от других изменений в функциональной ветке, поэтому вы изначально нацелены на 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.

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

Конвейеры

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

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

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

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

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

• [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 File Copy и PowerShell на целевую машину.

Группы компьютеров в 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 в конвейерах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Постоянно развертывать сборки, помеченные в процессе обработки после сборки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поддержка функции запуска из пакета в развертываниях службы Azure App Service.

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

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

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

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

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

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

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

1. Встроенный образ контейнера: код приложения-функции и Azure предоставляет контейнер (встроенный режим образа), поэтому не требуется никаких конкретных знаний, связанных с Docker. Это поддерживается в текущей версии задачи развертывания в службе App Service.
2. Пользовательский образ контейнера: Мы улучшили задачу развертывания службы приложений для поддержки развертывания пользовательских образов контейнеров в Azure Functions на Linux. Если вашим функциям требуется определенная языковая версия или зависят от конкретной зависимости или конфигурации, которая не предоставляется во встроенном образе, вы можете создать и развернуть кастомный образ в Azure Functions на 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. Дополнительные сведения см. в документации по развертыванию в службе контейнеров Azure с помощью Kubernetes.

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

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

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

Теперь вы можете непрерывно развертывать в Azure Database for 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 Tool Installer, чтобы установить одну или несколько версий Go Tool в реальном времени. Эта задача получает определенную версию средства Go, необходимую для проекта, и добавляет ее в PATH агента сборки. Если целевая версия средства Go уже установлена на агенте, эта задача пропустит процесс скачивания и установки еще раз.

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

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

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

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

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

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

Клиент Test Runner (Планы тестирования Azure) для выполнения ручных тестов для настольных приложений.

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

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

Артефакты

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

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

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

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

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

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

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

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

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

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

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

Сжимайте символы при публикации на общий файловый ресурс.

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

Вики

Публикация файлов 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:

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

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

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

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

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

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

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

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

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

Посмотрите документацию по markdown guidance для получения дополнительной информации об использовании markdown в Azure DevOps.

Метаданные 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.

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

Исследование истории сборок с помощью нового виджета панели мониторинга

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

Отзывы

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