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

Сообщество | разработчиковТребования к системе | Условия | лицензииБлог |

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

Дополнительные сведения об установке или обновлении развертывания Azure DevOps Server см. в статье "Требования к серверу Azure DevOps". Чтобы скачать продукты Azure DevOps, перейдите на страницу загрузки azure DevOps Server.

Прямое обновление до Azure DevOps Server поддерживается с Azure DevOps Server 2020, Azure DevOps Server 2019 или Team Foundation Server (TFS) 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 Update 0.2 Patch 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

Файл	Хэш 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, включающее исправления для следующих компонентов.

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

Дата выпуска обновления 0.2 для Azure DevOps Server 2020: 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 

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

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

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

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

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

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

Дата выпуска обновления 0.2 для Azure DevOps Server 2020: 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, включающее исправления для следующих компонентов.

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

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

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

Замечание

Если Azure DevOps Server и Elasticsearch установлены на разных компьютерах, выполните описанные ниже действия.

1. Обновите сервер исправлением 9.
2. Проверьте значение реестра по адресу HKLM:\Software\Elasticsearch\Version. Если значения реестра нет, добавьте строковое значение и установите Версия на 5.4.1 (Имя = Версия, Значение = 5.4.1).
3. Скопируйте содержимое папки с именем zip, расположенной в папке на C:\Program Files\{TFS Version Folder}\Search\zip в удалённую папку Elasticsearch.
4. Запустите Configure-TFSSearch.ps1 -Operation update на компьютере сервера Elasticsearch.

Хэш SHA-256: 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 CheckInstalldevops2020.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 CheckInstalldevops2020.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.

Install

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.

Install

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.

Дата выпуска пакета обновлений 3 для Azure DevOps Server 2020: 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.

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

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

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

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

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

• CVE-2020-17145: уязвимость типа подмены в Azure DevOps Server и Team Foundation Services

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

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

Замечание

На сервере Azure DevOps 2020 возникла проблема с установкой одной из сборок, используемых виртуальной файловой системой 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 RC2 — это свод исправлений ошибок. Она включает все функции в ранее выпущенном выпуске Azure DevOps Server 2020 RC1.

Дата повторного выпуска Azure DevOps Server 2020 RC1: 10 июля 2020 г.

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

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

Дата выпуска Azure DevOps Server 2020 RC1: 30 июня 2020 г.

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

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

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

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

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

---

General

Общедоступная версия Azure DevOps CLI

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

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

Use publish profile to deploy Azure WebApps for Windows from the Deployment Center (Развертывание веб-приложений Azure для Windows из центра развертывания с помощью профиля публикации)

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

Boards

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

Мы добавили новый фильтр как на доску спринта, так и в бэклог спринта. Это позволяет фильтровать элементы невыполненной работы уровня требований (первый столбец слева) по родительскому элементу. Например, на снимке экрана ниже мы отфильтровали представление, чтобы отобразить только пользовательские истории, где родитель — «My big feature».

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

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

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

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

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

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

Столбец родителя рабочего элемента как параметр столбца

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

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

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

".

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

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

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

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

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

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

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

Замечание

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

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

• Диаграмма выполнения задач находится в разделе Sprints.

  

• Доступ к отчетам CFD и Velocity можно получить на вкладке Аналитика в разделе Доски и Бэклоги, щелкнув по соответствующей карточке.

  

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

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

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

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

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

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

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

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

Переключить отображение или скрытие выполненных дочерних рабочих элементов на бэклоге;

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

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

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

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

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

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

Настройка значений системного выпадающего списка

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

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

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

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

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

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

Пример см. здесь.

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

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

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

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

Сделайте отчеты Azure Boards доступными на панели мониторинга

В обновлении Sprint 155 мы включили обновленные версии отчетов CF и Velocity. Эти отчеты доступны на вкладке "Аналитика" досок и заданий. Теперь вы можете закрепить отчеты непосредственно на панели управления. Чтобы закрепить отчеты, наведите указатель мыши на отчет, выберите меню многоточия "...", и выберите Копировать на панель мониторинга.

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

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

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

Обновление доски задач в реальном времени

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

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

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

1. В вашем списке задач щелкните "Настройки столбцов". Затем на панели щелкните "Добавить столбец Роллап" и Настройте пользовательский роллап.

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Repos

Метрики покрытия кода и политика работы с ветвями для pull-запросов.

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

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

фильтрация уведомлений о комментариях в пул-реквестах

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

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

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

Политика блокировки файлов по определенным признакам

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

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

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

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

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

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

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

Просмотр файлов Markdown в пул-запросах с побочным диффом

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

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

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

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

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

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

Пометка файлов как просмотренных в pull request

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

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

Замечание

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

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

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

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

Интернет

мобильное устройство

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

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

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

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

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

Мобильный интерфейс:

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

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

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

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

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

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

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

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

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

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

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

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

Мы рады предложить возможности YAML CD в Azure Pipelines. Теперь мы предлагаем унифицированный интерфейс 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 запрос к 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, таких как утверждения, авторизация и межпроектный общий доступ.

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

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

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

az Улучшения интерфейса командной строки для Azure Pipelines

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

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

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

При создании PR может быть сложно проверить, могут ли изменения привести к сбою выполнения конвейерной линии в целевой ветви. Однако с возможностью запуска конвейера или очереди сборки для ветви 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 — сколько времени, чтобы дать "всегда выполняться, даже если отмененные задачи" перед их завершением
• условие — условное выполнение задания
• переменные — можно добавлять жесткие значения напрямую или группы переменных, группировать переменные, поддерживаемые хранилищем ключей Azure , или ссылаться на набор переменных, определенных в файле.
• continueOnError — если будущие задания должны выполняться, даже если это задание развертывания завершается ошибкой; Значение по умолчанию — false.

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

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

Мы добавили поддержку в сведения о конвейерах CD YAML, где конвейеры CI называются ресурсами конвейера. Теперь в представлении запуска вашего конвейера 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, которая поддерживает настройку этих параметров массово с помощью синтаксиса JSON в веб-приложении или любого из его слотов развертывания. Эту задачу можно использовать вместе с другими задачами службы приложений для развертывания, управления и настройки веб-приложений, приложений-функций или других контейнерных служб приложений.

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

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

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

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

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

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

Улучшения для согласований в конвейерах YAML

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

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

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

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

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

Введите файл конфигурации и данные изображения

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

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

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

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

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

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

Возможности непрерывного развертывания для многоэтапных 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...

Стратегия канареечной стратегии для Kubernetes сначала развертывает изменения с 10% подов, затем 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>']]
• Для канарной стратегии: $[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

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

Avoid rollback of critical changes (Предотвращение отката критических изменений)

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

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

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

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

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

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

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

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

ReviewApp в рабочей среде.

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

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

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

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

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

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

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

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

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

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

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

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

Использование ключевого слова extends в конвейерах

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

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

# 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 checkout. Теперь вы можете получить и проверить другие репозитории, помимо используемого для хранения конвейера YAML.

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

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

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

Третий шаг будет отображать два каталога , MyCode и Tools в каталоге источников.

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

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

Задача установщика Open Policy Agent

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

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

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

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

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

"канареечные" развертывания на базе Service Mesh Interface в задании KubernetesManifest;

Ранее, когда в задаче KubernetesManifest была указана канарская стратегия, задача создаст базовые и канаровые рабочие нагрузки, реплики которых равны проценту реплик, используемых для стабильных рабочих нагрузок. Это было не совсем так же, как разделение трафика до нужного процента на уровне запроса. Для решения этой проблемы мы добавили поддержку канарских развертываний на основе Service Mesh Interface в задаче 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 V10

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

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

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

Ниже приведены дополнительные возможности, поддерживаемые в этой версии задачи:

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

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

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

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

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

  Замечание

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

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

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

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

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

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

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

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

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

Таргетирование этапов и изоляция команд

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, соответствующий приложению. Другими словами, вы не хотите создавать новую сборку, если изменение было отправлено в документы. Вы создаете новую ветвь локально, вносите некоторые изменения в документы, а затем отправляете эту ветвь на сервер. Мы использовали для запуска новой сборки CI. Это нежелательно, так как вы явно попросили не искать изменения в папке документов. Тем не менее, из-за того, как мы обрабатывали новое событие ветви, казалось, как будто изменения были внесены и в папку приложения.

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

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

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

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

Замечание

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

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

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

диагностика агентов.

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

Сервисные перехватчики для YAML-пайплайнов

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

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

Интеграция с Optimizely

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

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

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

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

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

При нажатии кнопки "Добавить артефакт " в определении конвейера выпуска вы найдете новый тип источника выпуска GitHub . Вы можете предоставить подключение к службе и репозиторий 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.

Updated ServiceNow integration with Azure Pipelines (Обновление интеграции ServiceNow с Azure Pipelines)

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

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

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

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

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

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

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

Set VSTest tasks to fail if a minimum number of tests are not run (Настройка для задач VSTest состояния сбоя, если не выполняется минимальное число тестов)

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

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

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

поддержка Markdown в отправляемых автоматически сообщениях об ошибках проверки;

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

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

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

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

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

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

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

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

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

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

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

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

Задачи

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

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

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

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

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

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

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

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

Задачи

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

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

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

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

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

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

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

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

Задачи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задачи

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

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

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

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

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

Отчет о ходе выполнения планов тестирования

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

К трем разделам отчета относятся следующие:

1. Сводка: отображает консолидированное представление для выбранных планов тестирования.
2. Тенденция результатов: представляет ежедневную сводку, чтобы дать вам график трендов выполнения и состояния. Он может отображать данные в течение 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. Узнайте больше о общедоступных веб-каналах в документации по веб-каналам или перейдите прямо в наше руководство по совместному использованию пакетов.

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

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

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

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

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

Теперь мы отображаем значки пакетов, описания и авторы в диспетчере пакетов NuGet Visual Studio для пакетов, обслуживаемых из веб-каналов Артефактов Azure. Ранее большая часть этих метаданных не была предоставлена 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 Wiki :

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

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

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

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

Замечание

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

число посещений вики-страниц

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

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

Замечание

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

Отчетность

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

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

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

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

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

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

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

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

Виджеты времени выполнения и циклического времени: расширенная фильтрация

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

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

С помощью таких вопросов обновления можно ответить, отфильтровав на дорожке доски.

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

Интегрированное сгорание спринта с использованием сторипоинтов

Спринт Берндаун теперь может сгореть по историям. Это относится к вашему отзыву от сообщества разработчиков.

На вкладке "Аналитика" в панели "Спринт" выберите её. Затем настройте отчет следующим образом:

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

Виджет Sprint Burndown с всеми функциями, которые вы хотели

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

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

Замечание

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

встроенная миниатюра диаграммы сгорания спринта

Спринт Берндаун вернулся! Несколько спринтов тому назад мы удалили информацию о спринте в контексте из заголовков Sprint Burndown и Taskboard. Воспользовавшись вашей обратной связью, мы улучшили и снова ввели миниатюру, показывающую снижение задач в спринте.

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

создание панели мониторинга, не связанной с командой.

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

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

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

Замечание

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

---

Отзывы

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

---

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