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

| Сообщество разработчиков Системные требования | Условия лицензии DevOps | Блог | SHA-1 Хэши 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 2020 г. Обновление 0.2. Обновление 6 Дата выпуска: 14 ноября 2023 г.

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

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

Примечание

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

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

Важно!

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

Настройка TFX

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

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

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

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

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

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

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

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

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

• Пример YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 г. обновление 0.2. Обновление 5 Дата выпуска: 10 октября 2023 г.

Важно!

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

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

• Исправлена ошибка, из-за которой удостоверение "Владелец анализа" отображалось как неактивное удостоверение на компьютерах с обновлением исправлений.

Azure DevOps Server 2020 г. обновление 0.2, исправление 4 Дата выпуска: 12 сентября 2023 г.

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

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

Важно!

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

Примечание

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

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

1. Скачайте и установите Azure DevOps Server 2020 с обновлением 0.2 с обновлением 4.

Обновление агента 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 2020 г. обновление 0.2, исправление 3 Дата выпуска: 8 августа 2023 г.

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

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

Azure DevOps Server 2020 г. Обновление 0.2. Дата выпуска исправления 2: 13 июня 2023 г.

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

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

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

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

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

Azure DevOps Server 2020.0.2 Дата выпуска: 17 мая 2022 г.

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

Примечание

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

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

• Не удается пропустить очередь сборки с помощью кнопки "Выполнить далее". Ранее кнопка "Выполнить далее" была включена только для администраторов коллекции проектов.

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

Azure DevOps Server 2020.0.1 Исправление 9 Дата выпуска: 26 января 2022 г.

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

• Email уведомления не были отправлены при использовании @mention элемента управления в рабочем элементе.
• Исправлена ошибка TF400813 при переключении учетных записей. Эта ошибка произошла при обновлении TFS 2018 до Azure DevOps Server 2020.0.1.
• Исправлена проблема с ней при загрузке страницы сводки "Обзор проекта".
• Улучшение синхронизации пользователей Active Directory.
• Устранена уязвимость Elasticsearch за счет удаления класса JndiLookup из двоичных файлов Log4j.

Шаги установки

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

Azure DevOps Server 2020.0.1. Обновление 8 Дата выпуска: 15 декабря 2021 г.

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

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

Azure DevOps Server 2020.0.1. Обновление 7 Дата выпуска: 26 октября 2021 г.

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

• Ранее Azure DevOps Server могли создавать подключения только к GitHub Enterprise Server. С помощью этого исправления администраторы проекта могут создавать подключения между Azure DevOps Server и репозиториями на GitHub.com. Этот параметр можно найти на странице подключений GitHub в разделе Параметры проекта.
• Устранение проблемы с мини-приложением "План тестирования". В отчете о выполнении теста отображался неправильный пользователь в результатах.
• Исправлена проблема с ней при загрузке страницы сводки "Обзор проекта".
• Исправлена проблема, из-за которой сообщения электронной почты не отправлялись для подтверждения обновления продукта.

Azure DevOps Server 2020.0.1 Дата выпуска исправления 6: 14 сентября 2021 г.

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

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

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

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

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

Azure DevOps Server 2020.0.1. Обновление 4 Дата выпуска: 15 июня 2021 г.

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

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

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

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

• Несогласованные данные результатов теста при использовании Microsoft.TeamFoundation.TestManagement.Client.

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

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

• Вариант 1. Запустите devops2020.0.1patch3.exe CheckInstall, devops2020.0.1patch3.exe — это файл, скачанный по ссылке выше. В выходных данных команды будет указано, что исправление установлено или не установлено.

• Вариант 2. Проверьте версию следующего файла: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 устанавливается c:\Program Files\Azure DevOps Server 2020 в по умолчанию. После установки Azure DevOps Server 2020.0.1 с обновлением 3 версия будет 18.170.31228.1.

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

Примечание

Если у вас Azure DevOps Server 2020 г., необходимо сначала обновить до Azure DevOps Server 2020.0.1 . После обновления 2020.0.1 установите Azure DevOps Server 2020.0.1, исправление 2

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

• CVE-2021-27067 : раскрытие информации
• CVE-2021-28459: повышение привилегий

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

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

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

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

• Вариант 1. Запустите devops2020.0.1patch2.exe CheckInstall, devops2020.0.1patch2.exe — это файл, скачанный по ссылке выше. В выходных данных команды будет указано, что исправление установлено или не установлено.

• Вариант 2. Проверьте версию следующего файла: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 устанавливается c:\Program Files\Azure DevOps Server 2020 в по умолчанию. После установки Azure DevOps Server 2020.0.1 с исправлением 2 версия будет 18.170.31123.3.

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

Примечание

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

Установка

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

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

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

npm install -g tfx-cli

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

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

~$ tfx login
Copyright Microsoft Corporation

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

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

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

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

Примечание

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

Установка

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

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 2020.0.1 Дата выпуска исправления 1: 9 февраля 2021 г.

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

• Устранение проблемы, о чем сообщалось в этом Сообщество разработчиков запросе на отзыв| Кнопка "Новый тестовый случай" не работает
• Включите исправления, выпущенные с Azure DevOps Server 2020, исправление 2.

Azure DevOps Server 2020 г. Дата выпуска исправления 3: 9 февраля 2021 г.

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

• Устранение проблемы, о чем сообщалось в этом Сообщество разработчиков запросе на отзыв| Кнопка "Новый тестовый случай" не работает

Azure DevOps Server 2020.0.1 Дата выпуска: 19 января 2021 г.

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

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

• Устраните проблему обновления с Azure DevOps Server 2019 г., из-за которой прокси-сервер Git может перестать работать после обновления.
• Исправлено исключение System.OutOfMemoryException для коллекций, не относящихся к ENU, до Team Foundation Server 2017 при обновлении до Azure DevOps Server 2020. Устранена проблема, обнаруженная в этом Сообщество разработчиков запросе обратной связи.
• Сбой обслуживания, вызванный отсутствием Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll. Устранена проблема, обнаруженная в этом Сообщество разработчиков запросе обратной связи.
• Исправлена ошибка недопустимого имени столбца в Аналитике при обновлении до Azure DevOps Server 2020. Устранена проблема, обнаруженная в этом Сообщество разработчиков запросе обратной связи.
• Хранимая функция XSS при отображении шагов тестового случая в результатах тестового случая.
• Сбой шага обновления при переносе данных результатов в TCM.

Azure DevOps Server 2020 г. Дата выпуска исправления 2: 12 января 2021 г.

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

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

Azure DevOps Server 2020 г. Обновление 1 Дата: 8 декабря 2020 г.

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

• CVE-2020-17145 : уязвимость для спуфинга в Azure DevOps Server и службах Team Foundation Service

Azure DevOps Server 2020 г. Дата выпуска: 6 октября 2020 г.

Azure DevOps Server 2020 г. — это сводка исправлений ошибок. Он включает в себя все функции, выпущенные ранее Azure DevOps Server 2020 RC2.

Примечание

В Azure DevOps 2020 Server возникла проблема с установкой одной из сборок, используемых виртуальной файловой системой Git (GVFS).

Если вы выполняете обновление с Azure DevOps 2019 (любой выпуск) или с версии-кандидата Azure DevOps 2020 и устанавливаетсяе в тот же каталог, что и предыдущий выпуск, сборка Microsoft.TeamFoundation.Git.dll не будет установлена. Вы можете убедиться, что вы столкнулись с проблемой, выполнив поиск Microsoft.TeamFoundation.Git.dll в <Install Dir>\Version Control Proxy\Web Services\binпапках , <Install Dir>\Application Tier\TFSJobAgent и <Install Dir>\Tools . Если файл отсутствует, можно выполнить восстановление для восстановления отсутствующих файлов.

Чтобы выполнить восстановление, перейдите по адресу Settings -> Apps & Features на Azure DevOps Server компьютере или виртуальной машине и запустите восстановление на Сервере Azure DevOps 2020. После завершения восстановления можно перезапустить компьютер или виртуальную машину.

Azure DevOps Server 2020 rc2 Дата выпуска: 11 августа 2020 г.

Azure DevOps Server 2020 версии-кандидата 2 — это сводка исправлений ошибок. Он включает все функции, выпущенные ранее Azure DevOps Server 2020 RC1.

Azure DevOps Server 2020 г. Дата повторного выпуска ВЕРСИИ-кандидата 1: 10 июля 2020 г.

Мы повторно выпустили Azure DevOps Server 2020 RC1, чтобы исправить этот Сообщество разработчиков запрос обратной связи.

Ранее после обновления Azure DevOps Server 2019 с обновлением 1.1 до версии-кандидата 1 Azure DevOps Server 2020 вы не могли просматривать файлы в репозиториях, конвейерах и вики-страницах пользовательского веб-интерфейса. Появилось сообщение об ошибке, указывающее, что в этой области страницы произошла непредвиденная ошибка. Вы можете попробовать перезагрузить этот компонент или обновить всю страницу. В этом выпуске мы устранили эту проблему. Дополнительные сведения см. в записи блога.

Azure DevOps Server 2020 г. Версия-кандидат 1 Дата выпуска: 30 июня 2020 г.

Сводка новых возможностях в Azure DevOps Server 2020 г.

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

• Многоэтапные конвейеры
• Непрерывное развертывание в YAML
• Отслеживание хода выполнения родительских элементов с помощью сводки невыполненной работы на досках
• Добавление фильтра "Родительский рабочий элемент" на доску задач и невыполненную работу по спринту
• Новый веб-интерфейс для целевых страниц Azure Repos
• Администрирование политики ветвей между репозиторием
• Страница "Новый план тестирования"
• Расширенное редактирование вики-страниц кода
• Отчеты о сбоях и длительности конвейера

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

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

---

Общее

Общая доступность Интерфейса командной строки Azure DevOps

В феврале мы представили расширение Azure DevOps для Azure CLI. Расширение позволяет взаимодействовать с Azure DevOps из командной строки. Мы собрали ваши отзывы, которые помогли нам улучшить расширение и добавить дополнительные команды. Теперь мы рады сообщить, что расширение является общедоступным.

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

Использование профиля публикации для развертывания веб-приложений Azure для Windows из Центра развертывания

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

Boards

Добавление фильтра "Родительский рабочий элемент" на доску задач и невыполненную работу по спринту

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

Улучшение процесса обработки ошибок — обязательные поля для ошибки или задачи

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

Динамическая перезагрузка рабочего элемента

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

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

Теперь вы можете управлять итерацией и путями к областям из командной строки с помощью az boards iteration команд и az boards area . Например, вы можете настроить итерацию и пути к областям и управлять ими в интерактивном режиме из интерфейса командной строки или автоматизировать всю настройку с помощью скрипта. Дополнительные сведения о командах и синтаксисе см. в документации здесь.

Родительский столбец рабочего элемента в качестве столбца

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

Изменение процесса, используемого проектом

Ваши средства должны меняться, как и ваша команда. Теперь вы можете переключать проекты с любого готового шаблона процесса на любой другой готовый процесс. Например, вы можете изменить проект с agile на Scrum или basic на Agile. Полную пошаговую документацию можно найти здесь.

Скрытие настраиваемых полей из макета

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

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

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

Три новых интерактивных отчета: Burndown, Совокупная схема потока (CFD) и Скорость. Отчеты можно просмотреть на новой вкладке аналитики.

Метрики, такие как спринт сжечь, поток работы и скорость команды, дают вам представление о прогрессе вашей команды и помогают ответить на такие вопросы, как:

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

Примечание

Диаграммы, ранее показанные в заголовках, были заменены этими расширенными отчетами.

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

• Диаграмму сгорания можно найти в концентраторе Спринты .

  

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

  

С новыми отчетами у вас есть больше контроля и информации о вашей команде. Ниже приведено несколько примеров.

• В отчетах Sprint Burndown и Velocity можно задать количество рабочих элементов или сумму оставшихся трудоемких работ.
• Вы можете изменить временной интервал спринта, не влияя на даты проекта. Таким образом, если ваша команда обычно проводит первый день планирования каждого спринта, теперь вы можете сопоставить диаграмму, чтобы отразить это.
• На диаграмме Burndown теперь есть водяной знак, показывающий выходные дни.
• Отчет CFS позволяет удалить столбцы доски, такие как Design, чтобы получить больше внимания на потоке, который контролируется командами.

Ниже приведен пример отчета CFD, в котором показан поток за последние 30 дней невыполненной работы по историям.

Диаграмму Скорость теперь можно отслеживать для всех уровней невыполненной работы. Например, теперь можно добавить функции и epics, в то время как ранее на предыдущей диаграмме поддерживались только требования. Ниже приведен пример отчета о скорости для последних 6 итераций невыполненной работы по функциям.

Настройка столбцов панели задач

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

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

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

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

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

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

Последние теги, отображаемые при добавлении тегов к рабочему элементу

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

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

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

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

Теперь можно настроить значения для любого списка выбора системы (за исключением поля причины), например Серьезность, Активность, Приоритет и т. д. Настройки списка выбора ограничены, поэтому вы можете управлять различными значениями для одного поля для каждого типа рабочего элемента.

Параметр URL-адреса нового рабочего элемента

Поделитесь ссылками на рабочие элементы в контексте доски или невыполненной работы с помощью нового параметра URL-адреса рабочего элемента. Теперь можно открыть диалоговое окно рабочего элемента на доске, невыполненной работе или в спринте, добавив параметр ?workitem=[ID] в URL-адрес.

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

Упоминание людей, рабочих элементов и PRs в текстовых полях

Когда мы слушали ваши отзывы, мы услышали, что вам нужна возможность упоминание людей, рабочих элементов и ЗАПРОСОВ в области описания рабочего элемента (и других полях HTML) в рабочем элементе, а не только в комментариях. Иногда вы сотрудничаете с кем-то над рабочим элементом или хотите выделить запрос на вытягивание в описании рабочего элемента, но у вас нет способа добавить эту информацию. Теперь вы можете упоминание людей, рабочих элементов и PRs во всех длинных текстовых полях рабочего элемента.

Пример можно найти здесь.

• Чтобы использовать упоминания людей, введите @ знак и имя пользователя, которого вы хотите упоминание. @mentionsв полях рабочего элемента будут создаваться Уведомления по электронной почте, подобные тому, что он делает для комментариев.
• Чтобы использовать упоминания рабочих элементов, введите # знак, за которым следует идентификатор или заголовок рабочего элемента. #mentions создаст связь между двумя рабочими элементами.
• Чтобы использовать упоминания с запросом на вытягивание, добавьте ! и свой идентификатор или имя запроса на вытягивание.

Реакции на комментарии к обсуждению

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

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

Закрепление Azure Boards отчетов на панели мониторинга

В обновление Sprint 155 мы включили обновленные версии отчетов о КОНТРАКТАХ и Скорости. Эти отчеты доступны на вкладке Аналитика раздела Boards and Невыполненная работа. Теперь можно закрепить отчеты непосредственно на панели мониторинга. Чтобы закрепить отчеты, наведите указатель мыши на отчет и нажмите кнопку с многоточием "..." и Копировать на панель мониторинга.

Отслеживание хода выполнения родительских элементов с помощью сводки невыполненной работы на досках

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

Например, здесь мы показываем ход выполнения по рабочим элементам , в котором отображаются индикаторы выполнения для нисходящих рабочих элементов в зависимости от процента закрытых дочерних элементов. Элементы-потомки для Epics включают все дочерние компоненты и их дочерние рабочие элементы. Дочерние элементы для компонентов включают все дочерние пользовательские истории и их дочерние рабочие элементы.

Динамические обновления доски задач

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

Поддержка настраиваемых полей в столбцах свертки

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

1. В невыполненной работы щелкните "Параметры столбца". Затем на панели щелкните "Add Rollup column" (Добавить столбец накопительного пакета) и Configure custom rollup (Настроить пользовательский накопительный пакет).

   

2. Выберите между индикатором выполнения и итогом.
3. Выберите тип рабочего элемента или уровень невыполненной работы (обычно невыполненная работа объединяет несколько типов рабочих элементов).
4. Выберите тип агрегирования. Количество рабочих элементов или сумма. Для параметра Сумма необходимо выбрать поле для формирования сводных данных.
5. Кнопка ОК вернется на панель параметров столбца, где можно изменить порядок нового настраиваемого столбца.

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

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

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

Параметры уведомлений о настраиваемых рабочих элементах

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

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

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

Связывание рабочих элементов с развертываниями

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

Импорт рабочих элементов из CSV-файла

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

Добавление родительского поля в карточки рабочих элементов

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

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

Родительское поле теперь доступно при просмотре невыполненных работ и результатов запросов. Чтобы добавить родительское поле, используйте представление параметров столбца .

Repos

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

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

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

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

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

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

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

Политика блокировки файлов с указанными шаблонами

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

Разрешение рабочих элементов с помощью фиксаций с помощью ключевых слов

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

Степень детализации для автоматических рецензентов

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

Использование проверки подлинности на основе учетной записи службы для подключения к AKS

Ранее при настройке Azure Pipelines из Центра развертывания AKS мы использовали подключение Resource Manager Azure. Это подключение имело доступ ко всему кластеру, а не только пространству имен, для которого настроен конвейер. В этом обновлении наши конвейеры будут использовать проверку подлинности на основе учетной записи службы для подключения к кластеру, чтобы у него был доступ только к пространству имен, связанному с конвейером.

Предварительный просмотр файлов Markdown в запросах на вытягивание параллельно diff

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

Срок действия политики сборки для сборок вручную

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

Добавление политики для блокировки фиксаций на основе автор фиксации электронной почты

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

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

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

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

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

Примечание

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

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

Новый веб-интерфейс для целевых страниц Azure Repos

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

Интернет

Мобильные службы

Администрирование политики ветвей между репозиторием

Политики ветвей — это одна из мощных функций Azure Repos, которые помогают защитить важные ветви. Хотя возможность задавать политики на уровне проекта существует в REST API, для нее не было пользовательского интерфейса. Теперь администраторы могут устанавливать политики для определенной ветви или ветвь по умолчанию во всех репозиториях в своем проекте. Например, администратор может потребовать двух минимальных рецензентов для всех запросов на вытягивание, выполняемых в каждой ветви main в каждом репозитории в своем проекте. Функцию Добавить защиту ветвей можно найти в параметрах проекта Repos.

Новые целевые страницы преобразования веб-платформы

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

Веб-интерфейс:

Работа с мобильными устройствами.

Поддержка языка Kotlin

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

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

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

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

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

Pipelines

Многоэтапные конвейеры

Мы работаем над обновленным пользовательским интерфейсом для управления конвейерами. Эти обновления делают конвейеры современными и совместимыми с направлением Работы с Azure DevOps. Кроме того, эти обновления объединяют классические конвейеры сборки и многоэтапные конвейеры YAML в единый интерфейс. Она удобна для мобильных устройств и предоставляет различные улучшения в управлении конвейерами. Вы можете детализировать и просмотреть сведения о конвейере, сведения о запуске, аналитику конвейера, сведения о задании, журналы и многое другое.

В новый интерфейс включены следующие возможности:

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

Непрерывное развертывание в YAML

Мы рады предоставить функции AZURE Pipelines YAML CD. Теперь мы предлагаем унифицированный интерфейс YAML, поэтому вы можете настроить каждый конвейер для выполнения ci, CD или CI и CD вместе. В функциях YAML CD представлено несколько новых расширенных функций, доступных для всех коллекций, использующих многоэтапные конвейеры YAML. Вот некоторые из них:

• Многоэтапные конвейеры YAML (для CI и CD)
• Утверждения и проверки ресурсов
• Среды и стратегии развертывания
• Ресурсы Kubernetes и виртуальных машин в среде
• Просмотр приложений для совместной работы
• Обновленный пользовательский интерфейс для подключений к службам
• Ресурсы в конвейерах YAML

Если вы готовы приступить к сборке, проверка документацию или блог о создании многоэтапных конвейеров CI/CD.

Управление переменными конвейера в редакторе YAML

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

Утверждение выпусков непосредственно из центра выпусков

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

Улучшения в начале работы с конвейерами

Мастер начала работы часто запрашивает возможность переименовать созданный файл. В настоящее время он возвращается как azure-pipelines.yml в корне репозитория. Теперь вы можете обновить его до другого имени или расположения файла перед сохранением конвейера.

Наконец, у нас будет больше контроля при возврате azure-pipelines.yml файла в другую ветвь, так как вы можете пропустить создание запроса на вытягивание из этой ветви.

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

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

Для разработчиков: post to dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview с текстом JSON, как показано ниже:

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

Ответ будет содержать отрисованный YAML.

Расписания Cron в YAML

Ранее можно было использовать редактор пользовательского интерфейса для указания запланированного триггера для конвейеров YAML. В этом выпуске вы можете запланировать сборки с помощью синтаксиса cron в файле YAML и воспользоваться следующими преимуществами:

1. Настройка как код. Вы можете отслеживать расписания вместе с конвейером как часть кода.
2. Экспрессивный. Вы можете определять расписания более выразительно, чем в пользовательском интерфейсе. Например, проще указать одно расписание, которое запускает запуск каждый час.
3. Отраслевой стандарт. Многие разработчики и администраторы уже знакомы с синтаксисом cron.

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

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

Обновления к пользовательскому интерфейсу подключений к службе

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

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

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

Примечание

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

Пропуск этапов в конвейере YAML

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

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

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

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

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

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

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

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

az Улучшения ИНТЕРФЕЙСА командной строки для Azure Pipelines

Команды управления группами переменных конвейера и переменными

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

Запуск конвейера для ветви запроса на вытягивание

При создании запроса на вытягивание может быть сложно проверить, могут ли изменения нарушить выполнение конвейера в целевой ветви. Однако с помощью возможности запуска конвейера или постановки сборки в очередь для ветви pr теперь можно проверить и визуализировать изменения, которые будут входить, запустив их в целевом конвейере. Дополнительные сведения см. в документации по командам az pipelines run и az pipelines build queue .

Пропуск первого запуска конвейера

При создании конвейеров иногда требуется создать и зафиксировать ФАЙЛ YAML, а не запускать запуск конвейера, так как это может привести к сбою по различным причинам— инфраструктура не готова или потребуется создать и обновить группы переменных или переменных и т. д. С помощью Azure DevOps CLI теперь можно пропустить первый автоматический запуск конвейера при создании конвейера, включив параметр --skip-first-run. Дополнительные сведения см. в документации по команде az pipeline create .

Улучшение команды конечной точки службы

Команды CLI конечной точки службы поддерживают только настройку и управление конечной точкой службы Azure rm и GitHub. Однако в этом выпуске команды конечной точки службы позволяют создавать любую конечную точку службы, предоставляя конфигурацию через файл и предоставляя оптимизированные команды — az devops service-endpoint github и az devops service-endpoint azurerm, которые обеспечивают первоклассную поддержку для создания конечных точек служб этих типов. Дополнительные сведения см. в документации по командам .

Задания развертывания

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

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

• timeoutInMinutes — время выполнения задания перед автоматической отменой
• cancelTimeoutInMinutes — сколько времени нужно дать "выполнять всегда, даже если отмененные задачи" перед их завершением
• условие — условное выполнение задания
• variables — жестко закодированные значения можно добавлять напрямую, можно ссылаться на группы переменных, на которые поддерживается хранилище ключей Azure , или ссылаться на набор переменных, определенных в файле.
• continueOnError — если будущие задания должны выполняться, даже если это задание развертывания завершается сбоем; значение по умолчанию — false

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

Отображение сведений о связанных конвейерах CD в конвейерах CI

Мы добавили поддержку в сведения о конвейерах CD YAML, где конвейеры CI называются ресурсами конвейера. В представлении выполнения конвейера НЕПРЕРЫВНОй интеграции вы увидите новую вкладку "Связанные конвейеры", где можно найти все запуски конвейера, которые используют ваш конвейер, и артефакты из него.

Поддержка пакетов GitHub в конвейерах YAML

Недавно мы представили новый тип ресурса под названием packages , который добавляет поддержку для использования пакетов NuGet и npm из GitHub в качестве ресурса в конвейерах YAML. В рамках этого ресурса теперь можно указать тип пакета (NuGet или npm), который вы хотите использовать из GitHub. Вы также можете включить автоматические триггеры конвейера после выпуска новой версии пакета. Сейчас поддержка доступна только для использования пакетов из GitHub, но в дальнейшем мы планируем расширить поддержку для использования пакетов из других репозиториев пакетов, таких как NuGet, npm, AzureArtifacts и многие другие. Дополнительные сведения см. в примере ниже.

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Примечание

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

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

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

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

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

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

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

Связывание рабочих элементов с многоэтапными конвейерами YAML

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

Отмена этапа в многоэтапном выполнении конвейера YAML

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

Этапы повторных попыток, завершились сбоем

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

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

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

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

Утверждения в многоэтапных конвейерах YAML

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

Запуски конвейера, развернутые в dev, остановятся для утверждения в начале этапа.

Увеличение ограничения времени ожидания шлюза и частоты

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

Новый шаблон образа сборки для Dockerfile

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

Новая задача для настройки Служба приложений Azure параметров приложения

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

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

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

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

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

Фильтр уровня этапа для артефактов Реестр контейнеров Azure и Docker Hub

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

Усовершенствования утверждений в конвейерах YAML

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

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

Поддержка тестирования структуры контейнеров в Azure Pipelines

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

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

Ввод сведений о файле конфигурации и образе

Тестовые данные и сводка

Декораторы конвейеров для конвейеров выпуска

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

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

Развертывание azure Resource Manager (ARM) на уровне подписки и группы управления

Ранее мы поддерживали развертывания только на уровне группы ресурсов. В этом обновлении добавлена поддержка развертывания шаблонов ARM на уровне подписки и группы управления. Это поможет вам развернуть набор ресурсов вместе, но разместить их в разных группах ресурсов или подписках. Например, развертывание резервной виртуальной машины для Azure Site Recovery в отдельной группе ресурсов и расположении.

Возможности CD для многоэтапных конвейеров YAML

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

Ниже приведена подробная схема YAML для ресурса конвейеров.

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

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

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

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

Оркестрация стратегии канареечного развертывания в среде для Kubernetes

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

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

Стратегия canary для Kuberenetes сначала развертывает изменения с 10 % модулей pod, а затем 20 % при мониторинге работоспособности во время postRouteTraffic. Если все пойдет хорошо, это будет способствовать до 100%.

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

Политики утверждения для конвейеров YAML

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

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

ACR как ресурс конвейера первого класса

Если вам нужно использовать образ контейнера, опубликованный в ACR (Реестр контейнеров Azure), как часть конвейера, и активировать конвейер при публикации нового образа, можно использовать ресурс контейнера ACR.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

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

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Усовершенствования политики проверки артефактов в конвейерах

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

Поддержка выходных переменных в задании развертывания

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

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

• Для стратегии runOnce : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Для стратегии canary : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Для последовательной стратегии: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

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

Избегайте отката критических изменений

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

Упрощенная авторизация ресурсов в конвейерах YAML

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

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

Оценка проверка артефактов

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

Обновления в задачу развертывания шаблона ARM

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

Просмотр приложений в среде

ReviewApp развертывает каждый запрос на вытягивание из репозитория Git в ресурс динамической среды. Рецензенты могут видеть, как выглядят эти изменения, а также работать с другими зависимыми службами, прежде чем они будут объединены в ветвь main и развернуты в рабочей среде. Это позволит легко создавать ресурсы reviewApp и управлять ими, а также пользоваться всеми возможностями трассировки и диагностики функций среды. С помощью ключевое слово reviewApp можно создать клон ресурса (динамически создать новый ресурс на основе существующего ресурса в среде) и добавить новый ресурс в среду.

Ниже приведен пример фрагмента YAML по использованию reviewApp в средах.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MasterNamespace

Сбор автоматических и пользовательских метаданных из конвейера

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

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

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

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

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

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Примечание

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

Дополнительный контроль над развертываниями

Azure Pipelines уже некоторое время поддерживает развертывания, управляемые с помощью утверждений вручную. Благодаря последним улучшениям теперь у вас есть дополнительный контроль над развертываниями. В дополнение к утверждениям владельцы ресурсов теперь могут добавлять автоматизированные checks для проверки политик безопасности и качества. Эти проверки можно использовать для запуска операций, а затем ждать их завершения. С помощью дополнительных проверок теперь можно определить критерии работоспособности на основе нескольких источников и быть уверенными, что все развертывания, предназначенные для ваших ресурсов, являются безопасными независимо от конвейера YAML, выполняющего развертывание. Оценку каждого проверка можно периодически повторять на основе указанного интервала повторных попыток для проверка. Теперь доступны следующие дополнительные проверки:

• Вызовите любой REST API и выполните проверку на основе текста ответа или обратного вызова из внешней службы.
• Вызов функции Azure и выполнение проверки на основе ответа или обратного вызова функции
• Запрос правил Azure Monitor для активных оповещений
• Убедитесь, что конвейер расширяет один или несколько шаблонов YAML

Уведомление об утверждении

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

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

Настройка стратегий развертывания из портал Azure

Благодаря этой возможности мы упростили настройку конвейеров, использующих выбранную стратегию развертывания, например Rolling, Canary или Blue-Green. Используя эти встроенные стратегии, вы можете безопасно развертывать обновления и снижать риски, связанные с развертыванием. Чтобы получить доступ к этой статье, щелкните параметр "Непрерывная доставка" на виртуальной машине Azure. В области конфигурации вам будет предложено выбрать сведения о проекте Azure DevOps, где будет создан конвейер, группе развертывания, конвейере сборки, который публикует пакет для развертывания, и выбранной стратегии развертывания. В дальнейшем вы настроите полнофункциональный конвейер, который развертывает выбранный пакет на этой виртуальной машине.

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

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

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

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

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

Использование расширяет ключевое слово в конвейерах

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

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

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

Управление переменными, которые можно переопределить во время очереди

Ранее можно было использовать пользовательский интерфейс или REST API для обновления значений любой переменной перед началом нового запуска. Хотя автор конвейера может пометить определенные переменные как _settable at queue time_, система не применяла это и не запрещала устанавливать другие переменные. Другими словами, параметр использовался только для запроса дополнительных входных данных при запуске нового запуска.

Мы добавили новый параметр коллекции, который применяет _settable at queue time_ параметр . Это позволит вам контролировать, какие переменные можно изменить при запуске нового запуска. В дальнейшем вы не сможете изменить переменную, которая не помечена автором как _settable at queue time_.

Примечание

Этот параметр по умолчанию отключен в существующих коллекциях, но он будет включен по умолчанию при создании новой коллекции Azure DevOps.

Новые предопределенные переменные в конвейере YAML

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

• Environment.Id — идентификатор среды.
• Environment.Name — имя среды, предназначенной для задания развертывания.
• Environment.ResourceId — идентификатор ресурса в среде, на которую нацелено задание развертывания.
• Environment.ResourceName — имя ресурса в среде, на которую нацелено задание развертывания.

Извлечение нескольких репозиториев

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

Например, если у вас есть репозиторий с именем MyCode с конвейером YAML и второй репозиторий с именем Tools, конвейер YAML будет выглядеть следующим образом:

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

На третьем шаге будут показаны два каталога: MyCode и Tools в каталоге sources.

поддерживаются Azure Repos репозитории Git. Дополнительные сведения см. в разделе Извлечение нескольких репозиторий.

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

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

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

Разрешить ссылки репозитория на другие коллекции Azure Repos

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

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection указывает на другую коллекцию Azure DevOps и имеет учетные данные, которые могут получить доступ к репозиторию в другом проекте. И репозитории, self и otherrepo, в конечном итоге будут извлечены.

Важно!

MyServiceConnectionдолжно быть подключением к службе Azure Repos или Team Foundation Server, см. рисунок ниже.

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

Мы добавили в конвейер предопределенные переменные для ресурсов конвейеров YAML. Ниже приведен список доступных переменных ресурсов конвейера.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

kustomize и kompose как параметры выпечки в задаче KubernetesManifest

kustomize (часть kubernetes sig-cli) позволяет настраивать необработанные файлы YAML без шаблонов для нескольких целей и оставляет исходный YAML нетронутым. Добавлен параметр для kustomize в действии bake задачи KubernetesManifest , чтобы можно было использовать любую папку, содержащую файлы kustomization.yaml, для создания файлов манифеста, используемых в действии развертывания задачи KubernetesManifest.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

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

Kompose преобразует файлы Docker Compose в ресурс Kubernetes.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

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

Поддержка учетных данных администратора кластера в задаче HelmDeploy

Ранее задача HelmDeploy использовала учетные данные пользователя кластера для развертываний. Это привело к интерактивным запросам на вход и сбою конвейеров для кластера с поддержкой RBAC на основе Azure Active Directory. Чтобы устранить эту проблему, мы добавили флажок, который позволяет использовать учетные данные администратора кластера вместо учетных данных пользователя кластера.

Входные аргументы в задаче Docker Compose

В задаче Docker Compose появилось новое поле, которое позволяет добавлять аргументы, --no-cacheнапример . Аргумент будет передан задачей при выполнении таких команд, как сборка.

Усовершенствования задач выпуска GitHub

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

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

Задача "Открыть установщик агента политики"

Open Policy Agent — это открытый код подсистема политик общего назначения, которая обеспечивает единое применение политик с учетом контекста. Мы добавили задачу Open Policy Agent installer (Открыть установщик агента политики). Это особенно полезно для применения политик в конвейере в отношении поставщиков инфраструктуры как кода.

Например, Open Policy Agent может оценивать файлы политики Rego и планы Terraform в конвейере.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Поддержка скриптов PowerShell в задаче Azure CLI

Ранее можно было выполнять пакетные и bash-скрипты в рамках задачи Azure CLI. В этом обновлении мы добавили в задачу поддержку основных сценариев PowerShell и PowerShell.

Canary deployments in KubernetesManifest task in KubernetesManifest

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

Абстракция интерфейса сетки службы позволяет настраивать подключаемые модули с поставщиками сетки служб, такими как Linkerd и Istio. Теперь задача KubernetesManifest берет на себя трудную работу по сопоставлению объектов SMI TrafficSplit со стабильными, базовыми и канарееическими службами в течение жизненного цикла стратегии развертывания. Требуемое процентное разделение трафика между стабильным, базовым и канарееарным является более точным, так как разделение трафика в процентах контролируется в запросах в плоскости сетки служб.

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

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

Задача копирования файлов Azure теперь поддерживает AzCopy версии 10

Задачу копирования файлов Azure можно использовать в конвейере сборки или выпуска для копирования файлов в большие двоичные объекты хранилища Майкрософт или виртуальные машины (ВМ). Задача использует AzCopy, сборку служебной программы командной строки для быстрого копирования данных из учетных записей хранения Azure и в нее. В этом обновлении мы добавили поддержку AzCopy версии 10, которая является последней версией AzCopy.

Команда azcopy copy поддерживает только аргументы , связанные с ней. Из-за изменения синтаксиса AzCopy некоторые существующие возможности недоступны в AzCopy версии 10. К ним относятся следующие объекты.

• Указание расположения журнала
• Очистка файлов журнала и планов после копирования
• Возобновление копирования в случае сбоя задания

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

• Подстановочные знаки в имени файла или пути к источнику
• Вывод типа контента на основе расширения файла при отсутствии аргументов
• Определение детализации журнала для файла журнала путем передачи аргумента

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

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

• Запретить маркеру доступ к ресурсам за пределами командного проекта

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

  Примечание

  Параметр коллекции переопределяет параметр проекта.

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

• Ограничение доступа к репозиториям службы сборки область

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

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

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

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

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

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

Нацеливание на шаг и изоляция команд

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

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

Ниже приведен полный пример выполнения шагов на узле в контейнере заданий и в другом контейнере:

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

Переменные только для чтения

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

variables:
- name: myVar
  value: myValue
  readonly: true

Доступ на основе ролей для подключений к службам

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

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

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

Совместное использование подключений служб между проектами

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

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

Возможность трассировки для конвейеров и ресурсов ACR

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

В представлении сводки по выполнению конвейера можно увидеть следующее:

• Версия ресурса, активировав запуск. Теперь конвейер можно активировать после завершения другого запуска конвейера Azure или при отправке образа контейнера в ACR.

  

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

  

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

• Артефакты, доступные для использования при выполнении.

  

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

Поддержка больших тестовых вложений

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

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

Чтобы устранить эту проблему, рекомендуется обновить брандмауэр для исходящих запросов до https://*.vstmrblob.vsassets.io. Сведения об устранении неполадок см. здесь.   ​

Примечание

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

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

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

Триггеры CI для новых ветвей

Долгое время ожидающий запрос не запускал сборки CI при создании новой ветви и когда в ней нет изменений. Рассмотрим следующие примеры:

• Веб-интерфейс используется для создания новой ветви на основе существующей ветви. Это немедленно активирует новую сборку CI, если фильтр ветви соответствует имени новой ветви. Это нежелательно, так как содержимое новой ветви совпадает по сравнению с существующей ветвью.
• У вас есть репозиторий с двумя папками — приложением и документацией. Вы настроили фильтр путей для CI в соответствии с "app". Иными словами, вы не хотите создавать новую сборку, если изменения были отправлены в документы. Вы создаете новую ветвь локально, вносите некоторые изменения в документы, а затем отправляете эту ветвь на сервер. Мы использовали для активации новой сборки CI. Это нежелательно, так как вы явно попросили не искать изменения в папке docs. Однако из-за того, как мы обрабатывали событие новой ветви, казалось бы, что в папку приложения были внесены изменения.

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

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

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

Выходные переменные по-прежнему создаются путем выполнения шагов внутри заданий. Вместо ссылки на dependencies.jobName.outputs['stepName.variableName']этапы ссылаются на stageDependencies.stageName.jobName.outputs['stepName.variableName'].

Примечание

По умолчанию каждый этап конвейера зависит от этапа непосредственно перед ним в ФАЙЛЕ YAML. Таким образом, каждый этап может использовать выходные переменные из предыдущего этапа. Вы можете изменить граф зависимостей, что также изменит доступные выходные переменные. Например, если для этапа 3 требуется переменная из этапа 1, необходимо объявить явную зависимость от этапа 1.

Отключение автоматического обновления агентов на уровне пула

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

Диагностика агента

Мы добавили диагностика для многих распространенных проблем, связанных с агентом, таких как многие проблемы с сетью и распространенные причины сбоев обновления. Чтобы начать работу с диагностика, используйте run.sh --диагностика или run.cmd --диагностика в Windows.

Перехватчики служб для конвейеров YAML

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

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

Оптимизация интеграции

Optimizely — это мощная платформа A/B-тестирования и маркировки функций для групп разработчиков продуктов. Интеграция Azure Pipelines с платформой экспериментов Optimizely позволяет командам по продуктам ускорять тестирование, обучение и развертывание, а также получать все преимущества DevOps от Azure Pipelines.

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

Дополнительные сведения о расширении Azure DevOps Optimizely см. здесь.

Добавление выпуска GitHub в качестве источника артефактов

Теперь вы можете связать выпуски GitHub в качестве источника артефактов в конвейерах выпуска Azure DevOps. Это позволит использовать выпуск GitHub в рамках развертываний.

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

Интеграция Terraform с Azure Pipelines

Terraform — это средство с открытым кодом для безопасной и эффективной разработки, изменения и управления версиями инфраструктуры. Terraform кодифицирует API в декларативные файлы конфигурации, что позволяет определять и подготавливать инфраструктуру с помощью высокоуровневого языка конфигурации. Расширение Terraform можно использовать для создания ресурсов во всех основных поставщиках инфраструктуры: Azure, Amazon Web Services (AWS) и Google Cloud Platform (GCP).

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

Интеграция с Google Analytics

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

Расширение экспериментов Google Analytics для Azure DevOps добавляет шаги экспериментирования в конвейеры сборки и выпуска, чтобы вы могли непрерывно выполнять итерацию, изучать и развертывать в ускоренном темпе, управляя экспериментами на постоянной основе, получая все преимущества DevOps от Azure Pipelines.

Вы можете скачать расширение экспериментов Google Analytics из Marketplace.

Обновленная интеграция ServiceNow с Azure Pipelines

Приложение Azure Pipelines для ServiceNow помогает интегрировать Azure Pipelines и ServiceNow Change Management. С помощью этого обновления вы можете интегрироваться с версией ServiceNow в Нью-Йорке. Теперь проверку подлинности между двумя службами можно выполнять с помощью OAuth и обычной проверки подлинности. Кроме того, теперь можно настроить расширенные критерии успешного выполнения, чтобы использовать любое свойство изменения для определения результата шлюза.

Создание Azure Pipelines из VSCode

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

Ненадежные управление ошибками и их устранение

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

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

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

Установка задач VSTest на сбой, если не выполняется минимальное количество тестов

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

Параметр VSTest TestResultsDirectory доступен в пользовательском интерфейсе задачи

Задача VSTest сохраняет результаты теста и связанные файлы в папке $(Agent.TempDirectory)\TestResults . Мы добавили параметр в пользовательский интерфейс задачи, позволяющий настроить другую папку для хранения результатов теста. Теперь все последующие задачи, которым нужны файлы в определенном расположении, могут использовать их.

Поддержка Markdown в сообщениях об автоматических тестах

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

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

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

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

Test Plans

Страница "Новый план тестирования"

Новая страница Test Plans (Test Plans *) доступна для всех коллекций Azure DevOps. На новой странице представлены упрощенные представления, которые помогут вам сосредоточиться на нужной задаче — планировании, разработке или выполнении тестов. Она также не содержит помех и совместима с остальной частью предложения Azure DevOps.

Помогите мне понять новую страницу

Новая страница Test Plans содержит в общей сложности 6 разделов, первые 4 из которых являются новыми, а разделы Диаграммы & Расширяемость являются существующими функциями.

1. Заголовок плана тестирования. Используйте его, чтобы найти, добавить в избранное, изменить, скопировать или клонировать план тестирования.
2. Дерево наборов тестов. Используйте его для добавления, экспорта и заказа наборов тестов, а также управления ими. Используйте его, чтобы также назначать конфигурации и выполнять приемочное тестирование пользователей.
3. Вкладка "Определение": сортировка, добавление тестовых случаев и управление ими в выбранном наборе тестов с помощью этой вкладки.
4. Вкладка "Выполнение". Назначьте и выполните тесты с помощью этой вкладки или найдите результат теста для детализации.
5. Вкладка Диаграмма. Отслеживайте выполнение теста и состояние с помощью диаграмм, которые также можно закрепить на панелях мониторинга.
6. Расширяемость: поддерживает текущие точки расширяемости в продукте.

Давайте рассмотрим эти новые разделы в широком росчерке ниже.

1. Заголовок плана тестирования

Задания

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

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

Параметры контекстного меню

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

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

Копирование плана тестирования (новая возможность)

Рекомендуется создать новый план тестирования для каждого спринта или выпуска. При этом, как правило, план тестирования для предыдущего цикла можно скопировать, и с небольшими изменениями скопированный план тестирования готов к новому циклу. Чтобы упростить этот процесс, мы включили функцию "Копировать план тестирования" на новой странице. Используя его, вы можете копировать или клонировать планы тестирования. Его резервный REST API рассматривается здесь , и API позволяет копировать или клонировать план тестирования в проектах.
Дополнительные рекомендации по использованию Test Plans см. здесь.

2. Дерево наборов тестов

Задания

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

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

Параметры контекстного меню

Контекстное меню в дереве Наборы тестов предоставляет следующие параметры:

• Создание новых наборов. Вы можете создать 3 различных типа наборов следующим образом:
  • Используйте статический набор или набор папок для упорядочения тестов.
  • Используйте набор на основе требований, чтобы напрямую ссылаться на требования и пользовательские истории для обеспечения легкой трассировки.
  • Используйте запросы для динамической организации тестовых случаев, соответствующих критериям запроса.
• Назначение конфигураций. Вы можете назначить конфигурации для набора (например, Chrome, Firefox, EdgeChromium), которые затем будут применяться ко всем существующим или новым тестовым случаям, которые вы добавите позже в этот набор.
• Экспорт в формате pdf/email: экспортируйте свойства плана тестирования, свойства набора тестов, а также сведения о тестовых случаях и тестовых точках в виде сообщения электронной почты или печати в PDF-файл.
• Открыть рабочий элемент набора тестов. Этот параметр позволяет изменить форму рабочих элементов набора тестов для управления полями рабочего элемента.
• Назначение тестировщиков для выполнения всех тестов. Этот параметр очень полезен для сценариев пользовательского приемочного тестирования (UAT), в которых один и тот же тест должен выполняться несколькими тестировщиками, обычно принадлежащими к разным отделам.
• Переименование или удаление. Эти параметры позволяют управлять именем набора или удалять набор и его содержимое из плана тестирования.

3. Вкладка "Определение"

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

Вкладка Определение и определенные операции доступны только пользователям с уровнем доступа "Базовый " и Test Plans или эквивалентным. Все остальное должно осуществляться пользователем с уровнем доступа "Базовый".

Задания

На вкладке Определить можно выполнять следующие задачи:

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

Параметры контекстного меню

Контекстное меню в узле Тестовый случай на вкладке Определение предоставляет следующие параметры:

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

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

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

Просмотр связанных элементов (новая возможность)

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

4. Вкладка "Выполнение"

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

Что такое точка тестирования? Сами по себе тестовые случаи не являются исполняемыми. При добавлении тестового случая в набор тестов создаются тестовые точки. Точка тестирования — это уникальное сочетание тестового случая, набора тестов, конфигурации и тестировщика. Пример. Если у вас есть тестовый случай как "Проверка функциональности входа" и вы добавляете в него 2 конфигурации как Edge и Chrome, это приведет к 2 тестовых точкам. Теперь эти тестовые точки можно выполнять. При выполнении создаются результаты теста. В представлении результатов теста (журнал выполнения) можно просмотреть все выполнения точки тестирования. Последнее выполнение для точки тестирования отображается на вкладке "Выполнение".
Таким образом, тестовые случаи являются повторно используемыми сущностями. При включении их в план тестирования или набор создаются тестовые точки. Выполняя тестовые точки, вы определяете качество разрабатываемого продукта или услуги.

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

Вкладка Определение и определенные операции доступны только пользователям с уровнем доступа "Базовый " и Test Plans или эквивалентным. Все остальное, включая вкладку "Выполнить", должно осуществляться пользователем с уровнем доступа "Базовый".

Задания

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

• Массовая пометка тестовых точек. Этот параметр позволяет быстро пометить результаты тестовых точек — пройденные, неудачные, заблокированные или неприменимые, без необходимости запуска тестового случая с помощью средства выполнения тестов. Результат можно отметить для одной или нескольких тестовых точек за один раз.
• Запуск тестовых точек. Этот параметр позволяет запускать тестовые случаи, по отдельности проходя каждый этап теста и помечая их как пройденные или неудачные с помощью средства выполнения тестов. В зависимости от приложения, которое вы тестируете, можно использовать "Средство веб-выполнения" для тестирования "веб-приложения" или "средство выполнения на рабочем столе" для тестирования классических и /или веб-приложений. Можно также вызвать "Выполнить с параметрами", чтобы указать сборку, для которой требуется выполнить тестирование.
• Параметры столбцов. Список столбцов, отображаемых на вкладке Выполнение, можно управлять с помощью команды "Параметры столбца". Список столбцов, доступных для выбора, связан с точками тестирования, такими как Запуск, Назначенный тестировщик, Конфигурация и т. д.
• Полноэкранный режим. С помощью этого параметра можно просмотреть содержимое всей вкладки Выполнение в полноэкранном режиме.
• Фильтрация. С помощью панели фильтров можно отфильтровать список точек тестирования, используя поля "название тестового случая", "назначено", "состояние", "результат теста", "Тестировщик" и "Конфигурация". Вы также можете отсортировать список, щелкнув заголовки столбцов.

Параметры контекстного меню

Контекстное меню узла Точка тестирования на вкладке Выполнение предоставляет следующие параметры:

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

Отчет о ходе выполнения Test Plans

Этот встроенный отчет помогает отслеживать выполнение и состояние одного или нескольких Test Plans в проекте. Посетите Test Plans > отчет о ходе выполнения*, чтобы приступить к работе с отчетом.

К трем разделам отчета относятся:

1. Сводка: отображает объединенное представление для выбранных планов тестирования.
2. Тенденция к результату: ежедневно отображает snapshot, чтобы получить линию тренда выполнения и состояния. Он может отображать данные за 14 дней (по умолчанию), 30 дней или настраиваемый диапазон.
3. Подробные сведения. В этом разделе вы можете детализировать каждый план тестирования и получить важную аналитику для каждого набора тестов.

Artifacts

Примечание

Azure DevOps Server 2020 не импортирует веб-каналы, которые находятся в корзине во время импорта данных. Если вы хотите импортировать веб-каналы, которые находятся в корзине, восстановите их из корзины перед началом импорта данных.

Выражения лицензий и внедренные лицензии

Теперь вы можете просматривать сведения о лицензиях для пакетов NuGet, хранящихся в Azure Artifacts, при просмотре пакетов в Visual Studio. Это относится к лицензиям, представленным с помощью выражений лицензий или внедренных лицензий. Теперь вы увидите ссылку на сведения о лицензии на странице сведений о пакете Visual Studio (красная стрелка на рисунке ниже).

Щелкнув ссылку, вы перейдете на веб-страницу, где можно просмотреть сведения о лицензии. Этот интерфейс одинаков как для выражений лицензий, так и для внедренных лицензий, поэтому вы можете просматривать сведения о лицензиях для пакетов, хранящихся в Azure Artifacts, в одном месте (для пакетов, которые указывают сведения о лицензии и поддерживаются Visual Studio).

Упрощенные задачи проверки подлинности

Теперь вы можете выполнять проверку подлинности с помощью популярных диспетчеров пакетов из Azure Pipelines с помощью задач легкой проверки подлинности. К ним относятся NuGet, npm, PIP, Twine и Maven. Ранее вы могли выполнять проверку подлинности в этих диспетчерах пакетов с помощью задач, которые предоставляли большой объем функциональных возможностей, включая возможность публикации и скачивания пакетов. Однако для этого необходимо использовать эти задачи для всех действий, которые взаимодействовали с диспетчерами пакетов. Если бы у вас были собственные скрипты для выполнения таких задач, как публикация или скачивание пакетов, вы не сможете использовать их в конвейере. Теперь вы можете использовать скрипты собственной разработки в конвейере YAML и выполнять проверку подлинности с помощью этих новых упрощенных задач. Пример использования npm:

Использование команд "ci" и "publish" на этом рисунке является произвольным. Вы можете использовать любые команды, поддерживаемые YAML Azure Pipelines. Это позволяет полностью контролировать вызов команд и упрощает использование общих скриптов в конфигурации конвейера. Дополнительные сведения см. в документации по задачам проверки подлинности NuGet, npm, PIP, Twine и Maven .

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

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

Общий доступ к пакетам с общедоступными веб-каналами

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

Настройка вышестоящих потоков в разных коллекциях в клиенте AAD

Теперь вы можете добавить веб-канал в другую коллекцию, связанную с клиентом Azure Active Directory (AAD), в качестве источника вышестоящий в веб-канал Артефактов. Веб-канал может находить и использовать пакеты из веб-каналов, настроенных в качестве вышестоящий источников, что позволяет легко совместно использовать пакеты в коллекциях, связанных с клиентом AAD. Сведения о настройке см. в документации.

Использование поставщика учетных данных Python для проверки подлинности pip и twine с помощью веб-каналов Azure Artifacts

Теперь вы можете установить и использовать поставщик учетных данных Python (artifacts-keyring) для автоматической настройки проверки подлинности для публикации или использования пакетов Python в веб-канале Azure Artifacts или из него. С поставщиком учетных данных вам не нужно настраивать файлы конфигурации (pip.ini/pip.conf/.pypirc), вы просто будете проходить через поток проверки подлинности в веб-браузере при первом вызове pip или twine. Дополнительные сведения см. в документации.

Веб-каналы Azure Artifacts в диспетчере пакетов Visual Studio

Теперь в диспетчере пакетов NuGet в Visual Studio отображаются значки, описания и авторы пакетов, обслуживаемого из веб-каналов Azure Artifacts. Ранее большая часть этих метаданных не предоставлялась в VS.

Обновлен интерфейс подключения к веб-каналу

Диалоговое окно Подключение к веб-каналу — это начальная возможность использования Azure Artifacts; В нем содержатся сведения о настройке клиентов и репозиториев для отправки и извлечения пакетов из веб-каналов в Azure DevOps. Мы обновили диалоговое окно, добавив подробные сведения о настройке, и расширили инструменты, для которые мы предоставляем инструкции.

Общедоступные веб-каналы теперь общедоступны с поддержкой вышестоящий

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

Создание веб-каналов с областью проекта на портале

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

Улучшения производительности npm

Мы внесли изменения в нашу основную структуру, чтобы улучшить способ хранения и доставки пакетов npm в веб-каналах Azure Artifacts. Это помогло нам достичь до 10-кратного сокращения задержки для некоторых из наиболее часто используемых API для npm.

Улучшение специальных возможностей

Мы развернули исправления для устранения проблем со специальными возможностями на странице веб-каналов. К исправлениям относятся следующие:

• Создание веб-канала
• Интерфейс параметров глобального веб-канала
• Подключение к веб-каналу

Вики

Расширенное редактирование вики-страниц кода

Ранее при редактировании вики-страницы кода вы были перенаправлены в центр Azure Repos для редактирования. В настоящее время центр Репозитория не оптимизирован для редактирования Markdown.

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

Создание и внедрение рабочих элементов на вики-странице

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

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

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

Комментарии на вики-страницах

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

Скрытие папок и файлов, начиная с "." в дереве вики-сайта

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

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

Короткие и доступные для чтения вики-страницы URL-адреса

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

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

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Ниже приведен пример нового URL-адреса для вики-страницы Добро пожаловать в Azure DevOps :

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

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

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

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

Примечание

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

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

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

Вы также увидите агрегированное количество посещений страниц за последние 30 дней на каждой странице.

Примечание

Посещение страницы определяется определенным пользователем как представление страницы с 15-минутным интервалом.

Отчеты

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

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

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

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

Улучшение мини-приложения "Результаты запроса"

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

В этом обновлении мы добавили множество долгожданных улучшений:

• Теперь можно выбрать столько столбцов, сколько нужно отобразить в мини-приложении. Не более 5 столбцов!
• Мини-приложение поддерживает все размеры от 1x1 до 10x10.
• При изменении размера столбца сохраняется ширина столбца.
• Мини-приложение можно развернуть в полноэкранном режиме. При развертывании будут отображаться все столбцы, возвращаемые запросом.

Расширенная фильтрация мини-приложений "Потенциальный клиент" и "Время цикла"

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

До сих пор мини-приложения времени для потенциальных клиентов и циклов не поддерживали расширенные критерии фильтра для вопросов, например: "Сколько времени занимает моя команда, чтобы закрыть элементы с более высоким приоритетом?"

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

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

Встроенный спринт сгора с использованием точек истории

Спринт Burndown теперь может сгореть с помощью Историй. Это соответствует вашим отзывам из Сообщество разработчиков.

В центре Sprint выберите вкладку Аналитика. Затем настройте отчет следующим образом:

1. Выбор невыполненной работы по историям
2. Выберите, чтобы сжечь по сумме точек истории

Мини-приложение Sprint Burndown со всем, что вы просили

Новое мини-приложение Sprint Burndown поддерживает запись по точкам истории, количеству задач или суммированию настраиваемых полей. Вы даже можете создать спринт для функций или epics. Мини-приложение отображает среднее сгорание, процент завершения и увеличение область. Вы можете настроить команду, позволяя отображать спринт прогона для нескольких команд на одной панели мониторинга. Благодаря всем этим замечательным сведениям мы можем изменить размер до 10x10 на панели мониторинга.

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

Примечание

В новом мини-приложении используется аналитика. Мы сохранили устаревшую версию Sprint Burndown на случай, если у вас нет доступа к Аналитике.

Эскиз встроенного спринта

Спринт Burndown вернулся! Несколько спринтов назад мы удалили спринт в контексте из заголовков Sprint Burndown и Taskboard. На основе ваших отзывов мы улучшили и повторно ввели эскиз спринта.

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

Создание панели мониторинга без команды

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

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

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

Примечание

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

---

Отзывы

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

---

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