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

| Сообщество разработчиков System Requirements License | Terms | DevOps Blog | SHA-1 Hashes

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

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

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


Безопасное обновление с Azure DevOps Server 2019 до Azure DevOps Server 2020 г.

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

Azure DevOps Server 2020 г. обрабатывает хранение сборок по-разному в зависимости от политик хранения на уровне конвейера. Некоторые конфигурации политики приводят к удалению конвейера после обновления. Запуски конвейера, которые были сохранены вручную или сохраняются в выпуске, не будут удалены после обновления.

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

Примечание

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

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

Хэш SHA-256: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

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

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

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

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

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

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

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

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

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

Azure DevOps Server 2020.0.1 с обновлением 5: 10 августа 2021 г.

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

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

дата выпуска Azure DevOps Server 2020.0.1 с исправлением 4: 15 июня 2021 г.

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

Примечание

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

Установка

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

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

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

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

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

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

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

Azure DevOps Server 2020 с обновлением 2: 12 января 2021 г.

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

Сводка новых средств в Azure DevOps Server 2020 г.

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

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


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

Общая доступность Azure DevOps CLI

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

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

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

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

Boards

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Снимок экрана: вкладка

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

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

Снимок экрана: параметр

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

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

Три новых интерактивных отчета: Burndown, Интегральная блок-схема (CF) и скорость. Отчеты отображаются на новой вкладке аналитики.

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

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

Примечание

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

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

  • Диаграмма сгорания находится в центре Sprints .

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

  • Доступ к отчетам о ПРОИЗВОДИТЕЛЬНОСТИ и скорости можно получить на вкладке "Аналитика " в разделе "Доски и невыполненные работы ", щелкнув соответствующую карточку.

    Снимок экрана: отчет о сводной схеме потоков и отчет о скорости на вкладке

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

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

Ниже приведен пример отчета о СОСТОЯНИИ СОБЫТИЙ, показывающий поток за последние 30 дней невыполненной работы историй.

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

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

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

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

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

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

Снимок экрана: панель задач с указанным параметром

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Снимок экрана: параметр

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Снимок экрана: элемент управления

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

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

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

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

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

Снимок экрана: карточка рабочего элемента с выбранным параметром

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

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

Снимок экрана: раздел

Repos

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

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

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

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

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

Снимок экрана: параметр

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

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

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

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

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

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

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

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

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

Снимок экрана: раздел

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

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

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

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

Снимок экрана: диалоговое окно автоматического включения рецензентов.

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

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

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

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

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

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

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

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

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

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

Снимок экрана: политики для всех репозиториев Git на вкладке

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

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

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

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

Примечание

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

Снимок экрана: проект с представлением в проводнике и пометкой как видимые параметры просмотра.

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

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

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

Интернет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Улучшенная эффективность pr

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

Pipelines

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

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

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

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

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

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

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

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

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

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

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

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

Снимок экрана: утверждение выпусков непосредственно из центра выпуска.

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

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

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

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

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

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

Для разработчиков: post to dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview with a JSON body like this:

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

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

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

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

  1. Настройка в виде кода: вы можете отслеживать расписания вместе с конвейером в рамках кода.
  2. Экспрессивное выражение: у вас есть более выразительная сила в определении расписаний, чем то, что вы смогли с помощью пользовательского интерфейса. Например, проще указать одно расписание, которое запускает выполнение каждый час.
  3. Отраслевой стандарт: многие разработчики и администраторы уже знакомы с синтаксисом cron.
schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

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

Снимок экрана: меню

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

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

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

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

Снимок экрана: меню

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

Примечание

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

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

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

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

Снимок экрана: раздел

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

Снимок экрана: раздел

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

Сбой повторных попыток

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

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

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

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

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

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

Снимок экрана: меню

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

Снимок экрана: развертывание ожидает утверждения.

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

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

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

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

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

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

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

Снимок экрана: диалоговое окно Служба приложений Azure

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

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

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

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

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

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

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

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

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

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

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

Снимок экрана: вкладка

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

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

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

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

Снимок экрана: страница

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

Снимок экрана: доступны сводка и тестовые данные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Для стратегии runOnce : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
  • Для канарной стратегии: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
  • Для последовательной стратегии: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]
// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

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

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

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

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

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

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

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

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

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

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

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

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

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

ReviewApp в среде

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

Снимок экрана: уведомление об утверждении.

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно!

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

Снимок экрана: страница

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

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

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

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

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

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

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

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

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

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

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

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

Снимок экрана: диаграммы Package and deploy Helm, показывающие флажок

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

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

Снимок экрана: задача Docker Compose с новым текстовым полем

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

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

Снимок экрана: задача выпуска GitHub с указанными разделами

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

Снимок экрана: задача выпуска GitHub с выделенными разделами

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

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

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

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

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

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

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

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

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

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

Ниже приведен пример последовательного выполнения развертываний на основе 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 версии 10

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

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

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

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

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

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

Каждое задание, выполняемое в Azure Pipelines, получает маркер доступа. Маркер доступа используется задачами и скриптами для обратного вызова в Azure DevOps. Например, мы используем маркер доступа для получения исходного кода, отправки журналов, результатов тестирования, артефактов или выполнения вызовов REST в 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Снимок экрана: фиксации в разделе

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

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

    Снимок экрана: страница артефактов для конвейера.

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

Снимок экрана: раздел

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

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

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

Снимок экрана: ошибка 403, возвращенная в журналах.

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

Примечание

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

Sceenshot на странице

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

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

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

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

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

Снимок экрана мастера NEW SERVICE HOOKS SUBSCRIPTION, показывающий триггер для этого типа раскрывающегося списка событий с вызванными параметрами этапа выполнения.

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

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

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

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

Оптимизация

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

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

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

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

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

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

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

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

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

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

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

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

Снимок экрана: задача

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

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

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

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

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

Устранение ошибок и управление ошибками Flaky

Мы представили высокоуровневое управление тестами для поддержки комплексного жизненного цикла с обнаружением, отчетом и разрешением. Чтобы улучшить его дальше, мы добавляем flaky test bug management and resolution.

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

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

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

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

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

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

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

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

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

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

Снимок экрана: поддержка Markdown в сообщениях об ошибках автоматического тестирования.

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

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

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

Test Plans

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

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

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

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

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

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

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

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

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

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

Задачи

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

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

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

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

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

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

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

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

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

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

Задачи

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

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

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

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

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

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

Страница

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

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

Задачи

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

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

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

Страница контекстного меню

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

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

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

Страница

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

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

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

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

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

Страница

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

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

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

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

Задачи

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

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

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

Страница контекстного меню

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

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

Отчет о ходе выполнения 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 (красная стрелка на рисунке ниже).

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

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

Снимок экрана: окно браузера с разрознав текстом лицензии MIT

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

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

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

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

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

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

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

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

Снимок экрана: страница PublicFeed для пакетов.

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

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

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

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

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

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

Обновлено подключение к веб-каналу

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

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

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

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

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

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

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

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

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

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

Вики

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

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

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

Снимок экрана: меню

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это пример нового URL-адреса для вики-страницы приветствия в Azure DevOps :

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

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

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

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

Снимок экрана: вики-панель инструментов с вызванным значком прокрутки синхронизации и переключателем

Примечание

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

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

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

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

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

Примечание

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

Отчеты

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

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

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

Снимок экрана: вкладка

Снимок экрана: отчет о сбое конвейера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sceenshot с новым мини-приложением Sprint Burndown.

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

Примечание

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

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

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

Снимок экрана: эскиз встроенного спринта сгореть.

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

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

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

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

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

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

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

Примечание

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


Отзывы

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


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