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

| Сообщество разработчиков Системные требования | Условия лицензии DevOps | Блог | SHA-1 Хэши

В этой статье вы найдете сведения о новейшем выпуске для Azure DevOps Server.

Дополнительные сведения об установке или обновлении развертывания Azure DevOps Server см. в разделе Требования к Azure DevOps Server. Чтобы скачать продукты 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 для проверки параметров Включить аргументы задач оболочки.

Примечание

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

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

Важно!

Мы выпустили обновления для агента Azure Pipelines с исправлением 15 12 сентября 2023 г. Если вы не установили обновления агента, как описано в заметках о выпуске для исправления 15, рекомендуется установить эти обновления перед установкой исправления 16. Новая версия агента после установки исправления 15 будет 3.225.0.

Настройка TFX

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

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

File	Хэш SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9F9AF9EFCED5034D2E5

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 , чтобы развернуть агент.  

Примечание

Для AZP_AGENT_DOWNGRADE_DISABLED необходимо задать значение true, чтобы предотвратить понижение уровня агента. В Windows следующую команду можно использовать в командной строке администратора, за которой следует перезагрузка. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Настройка TFX

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

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

1. Скачайте и извлеките Tasks_20230825.zip.
2. Перейдите в каталог извлеченных файлов.
3. Выполните следующие команды, чтобы отправить задачи:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

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

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

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

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

• Пример YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

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

• CVE-2023-36869: уязвимость Azure DevOps Server спуфингом.

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

Примечание

Все нижеперечисленные шаги нужно выполнять на компьютере с 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: уязвимость Azure DevOps Server спуфингом
• CVE-2020-17135: уязвимость Azure DevOps Server спуфингом
• 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 с обновлением 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: уязвимость, связанная с меж site scripting
• При выборе другого источника 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 : уязвимость удаленного выполнения кода в Wiki

---

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 создает исключение, если запрос содержит один и тот же столбец несколько раз.
• В клиентской объектной модели с использованием vso.work_full область oauth происходит сбой WorkItemServer.DownloadFile().
• Копирование внедренного изображения из поля рабочего элемента в другое поле рабочего элемента в другом проекте может привести к сломанному изображению.

Azure Repos

• "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

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

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

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

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) в Test Plans
• CVE-2019-0971 : уязвимость раскрытия информации в API Repos
• CVE-2019-0979 : уязвимость межсайтовых сценариев (XSS) в центре пользователей

---

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

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

• CVE-2019-0857: уязвимость спуфингов на вики-сайте
• 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
• Заметки карточки включают ошибки и типы пользовательских рабочих элементов
• Улучшенное средство выбора ветви
• Изменения в лицензировании конвейера развертывания артефактов и Release Management

---

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

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

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

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

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

• Общие сведения
• Boards
• Repos
• Конвейеры
• Test Plans
• Артефакты
• Вики
• Отчеты

---

Общее

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

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

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

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

Изменения в лицензировании конвейера развертывания артефактов и Release Management

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

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

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

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

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

Обработка наследования в новых коллекциях

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

Развернутое поле поиска

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

Вот поле поиска по умолчанию:

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

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

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

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

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

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

Boards

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

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

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

AB#{work item ID}

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

Adds support for deleting connections. Fixes AB#20.

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения об этих интересных обновлениях см. в нашем блоге DevOps.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа с запросами в пути к области команды с помощью нового @TeamAreas макроса

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

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

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

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

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

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

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

Repos

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одна из трудностей для автора расширения управления версиями заключается в получении контекста репозитория, отображаемого для пользователя, например имени, идентификатора и 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 и PoweShell на целевом компьютере

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

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

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

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

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

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

Добавление настраиваемых счетчиков сборки в сборки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Встроенный образ контейнера: Вы используете код приложения-функции, а Azure предоставляет контейнер и управляет им (встроенный режим образа), поэтому конкретные знания, связанные с Docker, не требуются. Это поддерживается в существующей версии задачи Служба приложений Deploy.
2. Пользовательский образ контейнера: Мы улучшили задачу Служба приложений Deploy для поддержки развертывания пользовательских образов контейнеров в Функции 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 Tool Installer получает определенную версию Helm из Интернета или кэша инструментов и добавляет ее в ПУТЬ агента (размещенного или закрытого). Используйте эту задачу, чтобы изменить версию Helm, используемую в последующих задачах, таких как задача cli .NET Core . Добавление этой задачи перед задачей Helm Deploy в определении сборки или выпуска гарантирует упаковку и развертывание приложения с правильной версией Helm. Эта задача также помогает при необходимости установить средство kubectl , которое является необходимым условием для работы Helm.

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

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

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

Доступны новые и улучшенные удаленные задачи Windows 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 Tool, необходимую для проекта, и добавляет ее в ПУТЬ агента сборки. Если целевая версия средства Go уже установлена в агенте, эта задача пропустит процесс скачивания и установки.

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

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

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

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

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

Test Plans

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

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

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

Artifacts

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

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 и следуйте инструкциям для клиента и платформы.

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.

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

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

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

Важно!

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

---

Отзывы

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

---

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