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


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


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

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

Чтобы скачать Azure DevOps Server продукты, посетите страницу загрузки Azure DevOps Server.

Прямое обновление до Azure DevOps Server 2020 поддерживается Azure DevOps Server 2019 или Team Foundation Server 2015 или более поздней версии. Если развертывание TFS находится на сервере TFS 2013 или более ранней версии, перед обновлением до Azure DevOps Server 2020 необходимо выполнить некоторые промежуточные шаги. Дополнительные сведения см. на странице установки .


Azure DevOps Server Дата выпуска исправления 3 для 2020.0.1: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. Run devops2020.0.1patch3.exe CheckInstall , devops2020.0.1patch3.exe — это файл, скачанный по ссылке выше. Выходные данные команды либо говорят, что исправление установлено, либо не установлено.

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

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

Примечание

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

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

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

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

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

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

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

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

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

Примечание

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

Установка

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

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

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

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

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

~$ tfx login
Copyright Microsoft Corporation

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

  1. Выполните следующую команду, чтобы отправить задачу на сервер. Используйте путь к извлеченному ZIP-файлу из шага 1.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

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

Примечание

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

Установка

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

  2. Скачайте и установите Node.js 14.15.1 и NPM (входит в состав Node.js скачивания), как подходит для компьютера.

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

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

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

~$ tfx login
Copyright Microsoft Corporation

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

  1. Выполните следующую команду, чтобы отправить задачу на сервер. Используйте путь к извлеченному ZIP-файлу из шага 1.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

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

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

Дата выпуска исправления 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 для коллекций, не относящихся к RUS, до 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. Ткмлогжер"
  • Несохраняемые сборки немедленно удаляются после миграции на Azure DevOps Server 2020
  • Исправить исключение поставщика данных

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

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

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

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

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

Примечание

На сервере Azure DevOps 2020 возникла ошибка при установке одной из сборок, используемых виртуальной файловой системой 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 с обновлением 1,1 до Azure DevOps Server 2020 RC1 вы не смогли просматривать файлы в репозиториев, конвейерах и вики веб-интерфейса. Произошла ошибка, указывающая на непредвиденную ошибку в этом регионе страницы. Вы можете попробовать перезагрузить этот компонент или обновить всю страницу. В этом выпуске мы устранили эту ошибку. Дополнительные сведения см. в записи блога.

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

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

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

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


Общие сведения

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

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

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

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

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

Boards

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

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

Снимок экрана с новым родительским фильтром рабочих элементов.

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

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

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

<a name="work-item-live-reload">Динамическая Перезагрузка рабочего элемента

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

![Короткое видео, показывающее, как работает динамическая Перезагрузка рабочего элемента.](media/154_01.gif "Динамическая перезагрузка")

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

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

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

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

Снимок экрана невыполненной работы с вызываемым параметром параметры столбцов.

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

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

Снимок экрана вкладки "проекты" с вызываемым параметром "изменить процесс".

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

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

Снимок экрана, показывающий параметр "скрыть от макета".

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

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

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

Такие метрики, как выработка спринта, поток работ и скорость работы команды, позволяют видеть ход выполнения команды и отвечать на такие вопросы, как:

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

Примечание

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

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

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

    Снимок экрана с диаграммой выработки на вкладке "аналитика".

  • Отчеты о CFD и скорости можно получить на вкладке аналитика в разделе доски и невыполненные работы, щелкнув соответствующую карточку.

    Снимок экрана отчета "совокупная схема потока" и отчета о скорости на вкладке "аналитика".

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

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

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

Снимок экрана со схемой накопительного потока на вкладке аналитика.

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

Снимок экрана: диаграмма скорости на вкладке "аналитика".

<a name="customize-taskboard-columns">Настройка столбцов taskboard

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

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

![Снимок экрана taskboard с вызываемым параметром параметры столбцов.](media/155_01.png "Настройка столбцов в taskboard")

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Новый параметр URL-адреса рабочего элемента

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

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

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

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

Пример можно увидеть здесь.

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

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

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

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

Снимок экрана Azure DevOps Twitter опроса, показывающий, что в 35% респондентов требовалось реакция на функции комментариев.

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

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

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

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

Снимок экрана с параметром "Копировать в панель мониторинга".

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

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

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

Снимок экрана рабочих элементов в невыполненной работе.

Taskboard Live Updates

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

Поддержка пользовательских полей в столбцах свертки

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

  1. В списке невыполненной работы щелкните "Параметры столбцов". Затем на панели щелкните "добавить столбец свертки" и Настройте пользовательскую свертку.

    Снимок экрана: раскрывающийся список добавить столбец свертки.

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

Снимок экрана: панель параметров столбцов с новым пользовательским столбцом.

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

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

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

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

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

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

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

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

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

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

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

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

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

Короткое видео, в котором показано, как импортировать рабочие элементы из CSV-файла.

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

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

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

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

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

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

Repos

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

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

Снимок экрана, показывающий, что вы видите метрики покрытия кода для изменений в представлении запроса на вытягивание (PR).

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

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

Снимок экрана с вызываемым параметром добавления политики состояния и разделом Добавление политики состояния, которое появляется при выборе параметра.

<a name="filter-comment-notifications-from-pull-requests">Фильтрация уведомлений по комментариям из запросов на включение внесенных изменений

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

![Снимок экрана, показывающий, как фильтровать уведомления о комментариях из запросов на вытягивание.](media/155_08.png "Фильтрация уведомлений по комментариям из запросов на включение внесенных изменений")

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

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

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

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

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

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

Снимок экрана, показывающий раздел политик с параметром проверки имени файла, установленным в значение ON.

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

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

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

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

Снимок экрана, показывающий диалоговое окно "автоматически включаемые рецензенты".

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

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

Предварительный просмотр файлов Markdown в запросе на включение внесенных изменений параллельно

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

Снимок экрана, показывающий файл Markdown в проекте с вызываемыми параметрами представления и просмотра.

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

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

Снимок экрана: диалоговое окно "Добавление политики сборки" с разделом срока действия сборки.

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

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

Снимок экрана, на котором показаны политики для всех репозиториев Git на вкладке политики с параметром подтверждения по электронной почте фиксации автора, установленным в значение ON.

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

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

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

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

Примечание

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

Снимок экрана, показывающий проект с представлением в проводнике и пометкой о параметрах просмотра.

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

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

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

Интернет

Снимок экрана: новый веб-интерфейс для Azure Repos целевых страниц.

Мобильные приложения

Снимок экрана: новый пользовательский интерфейс мобильного интерфейса для Azure Repos целевые страницы.

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

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

Снимок экрана: диалоговое окно "Добавление защиты ветви".

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

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

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

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

Возможности для мобильных устройств:

Снимок экрана со страницей файлов преобразования мобильных платформ.

Снимок экрана со страницей "фиксации" для преобразования мобильных платформ.

Поддержка языка Котлин

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

Снимок экрана файла Котлин, отображаемого в пользовательском интерфейсе.

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

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

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

Улучшенная взаимодействие с операциями с ОБЩЕСТВЕНностью

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

Pipelines

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

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

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

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

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

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

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

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

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

Снимок экрана, показывающий диалоговое окно "переменные".

<a name="approve-releases-directly-from-releases-hub">Утверждение выпусков непосредственно из центра выпусков

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

![Снимок экрана, показывающий, как утверждать выпуски непосредственно из центра выпуска.](media/154_16.png "Утверждение выпусков непосредственно из центра выпусков")

Интеграция BitBucket и другие усовершенствования в статье Приступая к работе с конвейерами

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

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

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

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

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

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

Снимок экрана, показывающий раздел "Запуск конвейера" с вызываемым параметром "этапы для выполнения".

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

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

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

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

Снимок экрана: диалоговое окно "Запуск конвейера".

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

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

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

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

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

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

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

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

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

Пропустить первый запуск конвейера

Иногда при создании конвейеров необходимо создать и зафиксировать файл YAML и не запустить выполнение конвейера, так как это может привести к сбою в работе из-за различных причин: инфраструктура не готова или необходимо создать и обновить группы переменных и переменных и т. д. С помощью Azure DevOps CLI можно пропустить первый автоматический запуск конвейера при создании конвейера, включив параметр--Skip-First-Run. Дополнительные сведения см. в документации по команде AZ конвейер Create .

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

Команды CLI конечной точки службы поддерживают только настройку и Управление конечными точками службы Azure RM и GitHub. Однако в этом выпуске команды конечной точки службы позволяют создать конечную точку службы, предоставив конфигурацию с помощью файла и предоставляя оптимизированные команды — AZ devops Service-Endpoint GitHub и AZ devops Service-Endpoint azurerm, которые обеспечивают первую поддержку класса для создания конечных точек службы этих типов. Дополнительные сведения см. в документации по командам .

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

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

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

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

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

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

Мы добавили поддержку для конвейеров CD YAML, где конвейеры CI называются ресурсами конвейера. В представлении "выполнение конвейера CI" теперь вы увидите новую вкладку "связанные конвейеры", где можно найти все запуски конвейеров, которые используют конвейер и артефакты.

Снимок экрана со связанными данными конвейеров компакт-дисков в конвейерах CI.

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

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

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. После того как это ограничение будет ликвидировано, мы предоставляем поддержку других типов проверки подлинности.

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

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

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

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

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

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

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

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

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

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

Неудачные попытки выполнить этапы

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

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

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

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

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

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

Снимок экрана: меню "добавить ресурсы" с подчеркнутым параметром "проверки".

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

Снимок экрана, показывающий, что развертывание ожидает утверждения.

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

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

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

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

Снимок экрана: диалоговое окно "DOCKER".

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

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

Снимок экрана с диалоговым окном "Параметры службы приложений Azure".

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

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

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

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

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

Фильтр уровня промежуточных объектов для реестра контейнеров Azure и артефактов DOCKER HUB

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

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

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

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

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

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

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

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

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

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

Снимок экрана с тестовой страницей структуры контейнеров.

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

Снимок экрана, показывающий, что доступны сводные и проверочные данные.

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

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

Мы поддерживали декораторы для сборок и 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...

Стратегия ранний для Куберенетес сначала развертывает изменения с 10% Pod, за которыми следует 20% при мониторинге работоспособности во время постраутетраффик. Если все пройдет успешно, это займет до 100%.

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

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

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

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

Снимок экрана, показывающий диалоговое окно "Создание утверждений".

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

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

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

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

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

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

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

Снимок экрана: диалоговое окно "вычисление артефакта" с подчеркнутым параметром "использовать шаблоны".

Снимок экрана: диалоговое окно "Настройка политики артефактов" с выбранным параметром "источники список разрешений" и "конвейеры Azure — построение образов".

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

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

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

  • Для стратегии 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

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

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

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

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

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

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

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

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

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

Снимок экрана: диалоговое окно "Вычисление политик артефактов".

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

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

Ревиевапп в окружении

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

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

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

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

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

Снимок экрана: диалоговое окно "Общие" с включенным параметром "опубликовать метаданные из конвейеров".

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

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

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

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

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

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

На третьем шаге будут показаны два каталога, myCode и средства в каталоге Sources.

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

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

При выполнении конвейера 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 Указывает на другую коллекцию DevOps Azure и имеет учетные данные, которые могут получить доступ к репозиторию в другом проекте. Как репозиториев, так self и otherrepo , будут извлечены.

Важно!

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

Снимок экрана страницы "Параметры проекта" с выделенным параметром 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

кустомизе и компосе как параметры внедрить в задаче Кубернетесманифест

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

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)

компосе преобразует 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)

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

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

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

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

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

Снимок экрана задачи Docker Compose, показывающей текстовое поле "новые аргументы".

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

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

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

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

Снимок экрана, показывающий задачу выпуска GitHub с выделенными разделами "сравнить с" и "тип журнала изменений".

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

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

Например, Открытый агент политики может оценивать файлы политики Рего и terraform планы в конвейере.

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

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

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

Снимок экрана задачи Azure CLI, показывающей, что PowerShell и PowerShell Core являются параметрами в раскрывающемся списке Тип скрипта.

Ранний развертывания на основе интерфейса сетки службы в задаче Кубернетесманифест

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

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

Ниже приведен пример выполнения развертывания ранний на основе 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 можно использовать в конвейере сборки или выпуска для копирования файлов в большие двоичные объекты или виртуальные машины хранилища Майкрософт. Задача использует AzCopy, служебную программу командной строки для быстрого копирования данных из учетных записей хранения Azure и в них. В этом обновлении добавлена поддержка AzCopy V10, которая является последней версией AzCopy.

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

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

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

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

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

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

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

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

    Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Снимок экрана, показывающий, что конвейер был запущен автоматически.

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

    Снимок экрана, показывающий фиксации в разделе текущего конвейера.

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

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

    Снимок экрана, показывающий страницу артефактов для конвейера.

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

Снимок экрана: вкладка "рабочие элементы" в разделе "развертывание по".

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

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

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

Снимок экрана, показывающий ошибку 403, возвращенную в журналах.

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

Снимок экрана: Мастер создания подписки на службы ПЕРЕХВАТЧИКов событий, отображающий триггер для этого типа раскрывающегося списка события с вызываемыми параметрами этапа запуска.

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

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

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

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

Optimizely

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

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

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

Снимок экрана: диалоговое окно "Добавление артефакта" с выбранным параметром "выпуск GitHub" и "вызываемый".

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

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

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

Снимок экрана интеграции terraform с Azure Pipelines.

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

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

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

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

Снимок экрана, показывающий задачу экспериментов Google Analytics.

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

Azure Pipelinesное приложение для servicenow поможет интегрировать изменения в Azure pipelines и ServiceNow. Это обновление можно интегрировать с версией ServiceNow в Нью Йорк. Теперь можно выполнить проверку подлинности между двумя службами с помощью OAuth и обычной проверки подлинности. Кроме того, теперь можно настроить расширенный критерий успеха, чтобы можно было использовать любое свойство изменения, чтобы определить результат шлюза.

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

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

Снимок экрана VS Code с предупреждением в правом нижнем углу, которое говорит: успешно настроен конвейер.

Управление ошибками и разрешение ненадежных

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

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

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

Задать для задач VSTest значение Failed, если не выполняется минимальное число тестов

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

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

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

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

Снимок экрана, показывающий текстовое поле папки результатов теста.

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

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

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

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

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

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

Test Plans

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

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

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

Помогите мне разобраться с новой страницей

Страница обзора плана тестирования

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

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

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

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

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

Задачи

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

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

Пункты контекстного меню

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

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

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

Копировать страницу плана тестирования

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

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

страница дерева наборов тестов

Задачи

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

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

Пункты контекстного меню

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

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

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

определить страницу вкладки

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

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

Задачи

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

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

Пункты контекстного меню

Страница "определение контекстного меню вкладки"

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

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

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

Определение страницы "копирование тестовых случаев на вкладке"

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

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

Страница "определение представления связанных элементов вкладки"

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

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

Страница «Выполнение вкладки»

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

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

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

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

Задачи

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

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

Пункты контекстного меню

Страница "выполнение" контекстного меню вкладки

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

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

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

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

Снимок экрана Test Plans раздела с выделенным параметром "отчет о состоянии".

В отчет входят следующие три раздела:

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

Примечание

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

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

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

Снимок экрана Newtonsoft.Jsв пакете NuGet с красной стрелкой, указывающей на лицензию пакета.

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

Снимок экрана окна браузера, диспалинг текст лицензии MIT

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

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

Снимок экрана примера задачи упрощенной проверки подлинности.

На этой иллюстрации использование команды CI и Publish является произвольным. можно использовать любые команды, поддерживаемые Azure Pipelines YAML. Это позволяет полностью управлять вызовом команды и упрощает использование общих скриптов в конфигурации конвейера. Дополнительные сведения см. в документации по задачам для проверки подлинности NuGet, NPM, PIP, твинеи Maven .

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

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

Совместное использование пакетов в общедоступных веб-каналах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

повышение производительности NPM

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

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

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

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

Вики

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

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

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

Снимок экрана, показывающий меню "Правка" с вызываемым параметром "изменить в репозиториев".

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

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

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

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

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

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

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

Снимок экрана, показывающий, как добавлять комментарии на вики-страницы.

Скрыть папки и файлы, начинающиеся с "." в дереве wiki

До настоящего момента в дереве вики-страниц показаны все папки и файлы, начинающиеся с точки (.) в дереве wiki. В сценариях с вики-кодом это означает, что такие папки, как. 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 дней. Эти данные можно использовать для создания отчетов для вики-страниц. Кроме того, эти данные можно хранить в источнике данных и создавать панели мониторинга для получения подробных сведений, таких как первые n наиболее посещаемых страниц.

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

Снимок экрана, показывающий предыдущие посещения вики-страницы.

Примечание

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

Отчеты

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

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

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

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

Снимок экрана, показывающий отчет о сбоях конвейера.

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

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

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

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

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

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

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

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

На такие вопросы об этом обновлении можно ответить с помощью фильтрации на дорожке доски.

Снимок экрана с диалоговым окном настройки с названием раздела "дорожка".

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

Снимок экрана с диалоговым окном "Конфигурация" с вызываемым разделом условий поля.

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

Теперь выработка спринта может выработка по историям. Это посвящено вашим отзывам сообщества разработчиков.

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

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

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

Мини-приложение "выработка спринта" со всеми сведениями, которые вы запросили

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

Сцееншот, отображающее новое мини-приложение "выработка спринта".

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

Примечание

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

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

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

Снимок экрана, показывающий эскиз выработки встроенного спринта.

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

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

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

Снимок экрана: диалоговое окно "Создание панели мониторинга" с выбранным и вызываемым параметром "панель мониторинга проекта".

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

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

Снимок экрана раскрывающегося списка команды.

Примечание

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


Отзывы

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


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