Share via

Заметки о выпуске Azure DevOps Server 2022 с обновлением 1

  • Статья

| | Сообщество разработчиков Системные требования и условия | лицензиина совместимость | Блог | DevOpsSHA-256 Хэши |

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

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

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

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

Azure DevOps Server 2022 г. обновление 1, исправление 3 Дата выпуска: 12 марта 2024 г.

File Хэш SHA-256
devops2022.1patch3.exe E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

Мы выпустили исправление 3 для Azure DevOps Server 2022 с обновлением 1.

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

Azure DevOps Server 2022 г. обновление 1. Обновление 2 Дата выпуска: 13 февраля 2024 г.

File Хэш SHA-256
devops2022.1patch2.exe 59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

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

  • Исправлена проблема отрисовки страницы сведений в расширении поиска.
  • Исправлена ошибка, из-за которой дисковое пространство, используемое папкой кэша прокси-сервера, вычислялось неправильно, а папка не была очищена должным образом.
  • CVE-2024-20667: Azure DevOps Server уязвимость к удаленному выполнению кода.

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

File Хэш SHA-256
devops2022.1patch1.exe 9D0FDCCD1F20461E586689B756E600CC16424018A3377042F7DC3A6EEF096FB6

Мы выпустили исправление 1 для Azure DevOps Server 2022 с обновлением 1.

  • Запретить настройку requested for при постановке в очередь запуска конвейера.

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

Примечание

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

  1. Версия агента не обновляется после обновления до Azure DevOps Server 2022.1 и использования агента обновления в конфигурации пула агентов. В настоящее время мы работаем над исправлением для устранения этой проблемы и будем делиться обновлениями в Сообщество разработчиков по мере прогресса. В то же время вы можете найти обходное решение для этой проблемы в этом запросе Сообщество разработчиков.
  2. Совместимость Maven 3.9.x. Maven 3.9.x внес критические изменения в Azure Artifacts, обновив транспорт Сопоставителя Maven по умолчанию на собственный HTTP из Wagon. Это приводит к проблемам с проверкой подлинности 401 для клиентов, использующих http, а не https. Дополнительные сведения об этой проблеме можно найти здесь. В качестве обходного решения можно продолжить использование Maven 3.9.x со свойством -Dmaven.resolver.transport=wagon. Это изменение заставляет Maven использовать транспорт сопоставителя вагонов. Дополнительные сведения см. в документации.

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

Примечание

Существует известная проблема с совместимостью Maven 3.9.x. Maven 3.9.x внес критические изменения в Azure Artifacts, обновив транспорт Сопоставителя Maven по умолчанию на собственный HTTP из Wagon. Это приводит к проблемам с проверкой подлинности 401 для клиентов, использующих http, а не https. Дополнительные сведения об этой проблеме можно найти здесь.

В качестве обходного решения можно продолжить использование Maven 3.9.x со свойством -Dmaven.resolver.transport=wagon. Это изменение заставляет Maven использовать транспорт сопоставителя вагонов. Дополнительные сведения см. в документации.

Azure DevOps Server 2022 г. обновление 1 RC2 Дата выпуска: 31 октября 2023 г.

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

Примечание

Существует известная проблема с совместимостью Maven 3.9.x. Maven 3.9.x внес критические изменения в Azure Artifacts, обновив транспорт Сопоставителя Maven по умолчанию на собственный HTTP из Wagon. Это приводит к проблемам с проверкой подлинности 401 для клиентов, использующих http, а не https. Дополнительные сведения об этой проблеме можно найти здесь.

В качестве обходного решения можно продолжить использование Maven 3.9.x со свойством -Dmaven.resolver.transport=wagon. Это изменение заставляет Maven использовать транспорт сопоставителя вагонов. Дополнительные сведения см. в документации.

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

  • Исправлена проблема в локальных веб-каналах, из-за которой вышестоящий записи не разрешали изменения отображаемого имени.
  • При переключении вкладок с кода на другую вкладку на странице "Поиск" произошла непредвиденная ошибка.
  • Ошибка при создании нового типа рабочего элемента с унифицированными иеографами на китайском, японском и корейском языках (CJK). Вопросительный знак отображался в журнале RAW в закрытом проверка, когда имя или файлы командного проекта включали CJK.
  • Исправлена проблема во время установки службы поиска, из-за которой виртуальной машине Java (JVM) не удавалось выделить достаточно памяти для процесса эластичного поиска. Мини-приложение конфигурации поиска теперь использует пакет Java Development Kit (JDK), который входит в пакет эластичного поиска и, следовательно, удаляет зависимость от любой среды выполнения Java (JRE), предустановленной на целевом сервере.

Azure DevOps Server 2022 г. обновление 1 RC1 Дата выпуска: 19 сентября 2023 г.

Azure DevOps Server 2022.1 RC1 включает множество новых функций. Вот некоторые из них:

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

Общее

Все общедоступные REST API поддерживают детализированные области PAT.

Ранее ряд общедоступных задокументированных REST API Azure DevOps не были связаны с областями (например, чтением рабочих элементов), что приводило к тому, что клиенты использовали полные области для использования этих API с помощью неинтерактивных механизмов проверки подлинности, таких как личные маркеры доступа (PAT). Использование полного область личного маркера доступа повышает риск, когда он может посадить в руки злоумышленника. Это одна из main причин, по которым многие из наших клиентов не воспользовались всеми преимуществами политик уровня управления для ограничения использования и поведения PAT.

Теперь все общедоступные REST API Azure DevOps теперь связаны с область и поддерживают детализированный область PAT. Если в настоящее время вы используете полную область pat для проверки подлинности в одном из общедоступных REST API Azure DevOps, рассмотрите возможность миграции в PAT с конкретными область, принятыми API, чтобы избежать ненужного доступа. Поддерживаемые детализированные область PAT для заданного REST API можно найти в разделе Безопасность на страницах документации. Кроме того, здесь есть таблица областей.

Расширения должны отображать свои области

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

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

Boards

Столбец "Последний доступ" на странице "Планы доставки"

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

Gif для демонстрации поля Last Accessed на странице "

Визуализация всех зависимостей от планов доставки

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

Gif для демонстрации визуализации всех зависимостей на странице "

Ограничения редакции новых рабочих элементов

За последние несколько лет мы видели, как коллекции проектов с автоматизированными инструментами создают десятки тысяч исправлений рабочих элементов. Это создает проблемы с производительностью и удобством использования в форме рабочего элемента и rest API отчетов. Чтобы устранить эту проблему, мы реализовали ограничение на редакцию рабочих элементов в 10 000 для Службы Azure DevOps. Ограничение влияет только на обновления, использующие REST API, но не на форму рабочего элемента.

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

Увеличение лимита группы планов доставки с 15 до 20

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

Исправлена ошибка в API получения ссылок на рабочие элементы отчетов, чтобы вернуть правильное значение remoteUrl для System.LinkTypes.Remote.Related типов ссылок. Перед этим исправлением мы возвращали неправильное имя коллекции проектов и отсутствующий идентификатор проекта.

Создание временной конечной точки REST запроса

Мы видели несколько случаев, когда авторы расширений пытались выполнять несохраненные запросы, передавая инструкцию WIQL через querystring. Это работает нормально, если у вас нет большой инструкции WIQL, которая достигает ограничений браузера на длину строки запросов. Чтобы решить эту проблему, мы создали новую конечную точку REST, которая позволяет авторам инструментов создавать временные запросы. Использование идентификатора из ответа для передачи через querystring устраняет эту проблему.

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

API пакетного удаления

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

@CurrentIteration макрос в планах доставки

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

Gif для демонстрации макроса CurrentIteration в планах доставки.

Логика изменения размера карточки в планах доставки

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

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

Ссылка на gif для демонстрации копирования комментариев.

Улучшения пакетного обновления

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

Щелкните здесь , чтобы узнать больше о REST API пакетного обновления.

API пакетного удаления

Эта новая конечная точка REST API для удаления и (или) уничтожения рабочих элементов в пакете теперь общедоступна. Щелкните здесь, чтобы получить дополнительные сведения.

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

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

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

Gif для демонстрации редактирования полей списка выбора, доступных для общего доступа.

Новое разрешение на сохранение комментариев

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

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

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

Путь к области

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

Новое разрешение

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

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

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

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

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

Чтобы просмотреть эти диаграммы, щелкните вкладку Аналитика на страницах Канбан-доска, Невыполненная работа и Спринты.

Интерактивные отчеты

Repos

Удаление разрешения "Изменение политик" для создателя ветви

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

Образ управления разрешениями.

Вам потребуется явное разрешение "Изменить политики" (вручную или через REST API) путем наследования разрешений безопасности или членства в группе.

Pipelines

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

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

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

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

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

Поддержка Azure Pipelines для выпусков ServiceNow в Сан-Диего, Токио & Юта

Azure Pipelines имеет существующую интеграцию с ServiceNow. Интеграция зависит от приложения в ServiceNow и расширения в Azure DevOps. Теперь мы обновили приложение для работы с версиями ServiceNow в Сан-Диего, Токио & юта. Чтобы обеспечить работу этой интеграции, обновите приложение до новой версии (4.215.2) из магазина ServiceNow.

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

Использование URL-адресов прокси для интеграции с GitHub Enterprise

Azure Pipelines интегрируется с локальными серверами GitHub Enterprise Для выполнения сборок непрерывной интеграции и запроса на вытягивание. В некоторых случаях GitHub Enterprise Server находится за брандмауэром и требует, чтобы трафик направлялся через прокси-сервер. Для поддержки этого сценария подключения службы GitHub Enterprise Server в Azure DevOps позволяют настроить URL-адрес прокси-сервера. Ранее не весь трафик из Azure DevOps направлялся через этот URL-адрес прокси-сервера. В этом обновлении мы убедимся, что мы направляем следующий трафик из Azure Pipelines для прохождения через URL-адрес прокси-сервера:

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

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

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

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

Примечание

Управляемому удостоверению, используемому для доступа к Реестр контейнеров Azure, потребуется соответствующее назначение контроль доступа на основе ролей Azure (RBAC), например AcrPull или AcrPush.

Автоматические маркеры, созданные для подключения к службе Kubernetes

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

Задачи Kubernetes теперь поддерживают kubelogin

Мы обновили задачи KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 и AzureFunctionOnKubernetes@1 для поддержки kubelogin. Это дает возможность использовать Службу Azure Kubernetes (AKS), настроенную с интеграцией Azure Active Directory.

Kubelogin не предварительно установлен в размещенных образах. Чтобы убедиться, что указанные выше задачи используют kubelogin, установите его, вставив задачу KubeloginInstaller@0 перед задачей, которая от нее зависит:

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

Улучшения разрешений конвейера

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

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

Новая область PAT для управления авторизацией, утверждениями и проверками конвейера

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

Обновления REST API конвейеров

Следующие вызовы REST API поддерживают новый область PAT следующим образом:

Ограничение открытия защищенных ресурсов администраторами ресурсов

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

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

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

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

Разрешения конвейеров

Улучшения безопасности REST API конвейеров

Большинство REST API в Azure DevOps используют маркеры PAT с заданной областью. Однако для некоторых из них требуются маркеры PAT с полной областью действия. Иными словами, чтобы использовать некоторые из этих API, необходимо создать маркер PAT, выбрав "Полный доступ". Такие маркеры представляют угрозу безопасности, так как их можно использовать для вызова любого REST API. Мы вносим улучшения в Azure DevOps, чтобы устранить потребность в маркерах с полной областью, включив каждый REST API в определенную область. В рамках этих усилий REST API для обновления разрешений конвейера для ресурса теперь требует определенного область. Область зависит от типа ресурса, авторизованного для использования:

  • Code (read, write, and manage) для ресурсов типа repository
  • Agent Pools (read, manage) или Environment (read, manage) для ресурсов типа queue и agentpool
  • Secure Files (read, create, and manage) для ресурсов типа securefile
  • Variable Groups (read, create and manage) для ресурсов типа variablegroup
  • Service Endpoints (read, query and manage) для ресурсов типа endpoint
  • Environment (read, manage) для ресурсов типа environment

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

Детальное управление доступом для пулов агентов

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

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

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

Пул агентов FabrikamFiber для изменений в утверждениях

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

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

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

Чтобы повысить уровень безопасности по умолчанию, Azure DevOps теперь оставляет флажок не замеченным.

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

Возможность отключения маскирования для коротких секретов

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

Все вхождения значения секрета маскируются. Маскирование коротких секретов, например "1", "2", "Dev" позволяет легко угадать их значения, например в дате: "Jan 3, 202***"
Теперь ясно, что "3" является секретом. В таких случаях вы можете предпочесть не маскировку секрета. Если невозможно пометить значение как секрет (например, значение берется из Key Vault), можно задать AZP_IGNORE_SECRETS_SHORTER_THAN для ручки значение до 4.

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

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

Приведенная ниже задача является методом для установки JIT-средства выполнения Node 6, поэтому старая задача по-прежнему может выполняться:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6

Обновлена проверка средства выполнения узлов TFX

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

Расширения, содержащие задачи, использующие средство выполнения Node 6, увидят следующее предупреждение:

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

Инструкции по предварительной установке узла 6 вручную в агентах конвейера

Если вы используете pipeline- веб-канал агента, в агент не включен узел 6. В некоторых случаях, когда задача Marketplace по-прежнему зависит от Node 6, а агенту не удается использовать задачу NodeTaskRunnerInstaller (например, из-за ограничений подключения), вам потребуется предварительно установить Node 6 отдельно. Для этого ознакомьтесь с инструкциями по установке средства выполнения тестов Node 6 вручную.

Журнал изменений задач конвейера

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

Задачи выпуска используют Microsoft API Graph

Мы обновили наши задачи выпуска для использования API Graph Майкрософт. Это удаляет использование API Graph AAD из наших задач.

Повышение производительности задач Windows PowerShell

Задачи можно использовать для определения автоматизации в конвейере. Одна из этих задач — служебная PowerShell@2 задача, которая позволяет выполнять сценарии PowerShell в конвейере. Чтобы использовать скрипт PowerShell для целевой среды Azure, можно использовать AzurePowerShell@5 задачу . Некоторые команды PowerShell, которые могут выводить обновления хода выполнения, например Invoke-WebRequest, теперь выполняются быстрее. Улучшение является более значительным, если у вас есть много этих команд в скрипте или когда они выполняются долго. При этом обновлении свойству progressPreferencePowerShell@2 задач и AzurePowerShell@5 теперь присваивается значение SilentlyContinue по умолчанию.

Агент конвейеров версии 3 в .NET 6

Агент конвейера обновлен для использования .NET 3.1 Core до .NET 6 в качестве среды выполнения. Это предоставляет встроенную поддержку Apple Silicon, а также Windows Arm64.

Использование .NET 6 влияет на требования к системе для агента. В частности, мы отбросируем поддержку следующих операционных систем: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. См. документацию по программному обеспечению агента версии 3.

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

Важно!

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

Укажите версию агента в расширении виртуальной машины агента

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

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

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

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

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

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

Отключение создания классических конвейеров

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

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

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

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

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

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

Пример последнего сообщения о фиксации

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

В этом обновлении мы добавили новое свойство YAML с именем appendCommitMessageToRunName, которое позволяет делать именно это. По умолчанию свойству присвоено значение true. Если задать для него значение false, при выполнении конвейера BuildNumberбудет отображаться только .

Пример выполнения конвейера с номером сборки

Пример выполнения конвейера с сообщением о последней фиксации

Увеличены ограничения Azure Pipeline в соответствии с максимальным размером шаблона azure Resource Manager (ARM) в 4 МБ.

Для создания инфраструктуры Azure можно использовать задачу "Развертывание шаблона Resource Manager Azure". В ответ на ваши отзывы мы увеличили лимит интеграции Azure Pipelines с 2 ДО 4 МБ. Это будет соответствовать максимальному размеру шаблонов ARM в 4 МБ , разрешающим ограничения размера во время интеграции больших шаблонов.

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

В этом выпуске мы упростим общее состояние выполнения конвейера.

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

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

Боковая панель этапов конвейера

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

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

Конвейеры обновления

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

Поиск этапов на боковой панели

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

Обновление конвейеров AZ

Выполнение быстрых действий

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

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

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

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

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

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

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

Ожидание образа проверки конвейера.

Отключение проверка

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

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

Отключение проверка образа. После исправления ошибочного проверка его можно просто включить.

Включение образа проверка.

Потребляемые ресурсы и параметры шаблона в REST API выполнения конвейеров

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

Ниже приведен пример нового текста ответа.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Поддержка шаблонов общей доступности в редакторе YAML

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

Azure Pipelines поддерживает редактор YAML, который может быть полезен при редактировании конвейера. Однако редактор до сих пор не поддерживал шаблоны. Авторам конвейеров YAML не удалось получить помощь с помощью IntelliSense при использовании шаблона. Авторам шаблонов не удалось использовать редактор YAML. В этом выпуске мы добавим поддержку шаблонов в редакторе YAML.

При редактировании main YAML-файле Azure Pipelines можно включить или расширить шаблон. При вводе имени шаблона вам будет предложено проверить шаблон. После проверки редактор YAML понимает схему шаблона, включая входные параметры.

Обновления REST API конвейеров

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

Существуют известные ограничения:

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

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

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

Например, если конвейер размещен в папке FabrikamFiber\Chat в Azure Pipelines, то значение Build.DefinitionFolderPath равно FabrikamFiber\Chat.

Добавлена поддержка функции разбиения строк в выражениях шаблона YAML.

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

Иногда набор элементов для итерации представляется в виде строки. Например, если список сред для развертывания определяется строкой integration1, integration2.

Выслушав ваши отзывы от Сообщество разработчиков, вы узнали, что вам нужна строковая split функция в выражениях шаблонов YAML.

Теперь можно split выполнить итерацию each по подстрокам строки.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Выражения шаблонов в определении ресурса репозитория

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

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

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

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

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

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

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

Укажите версию шаблона для расширения во время очереди сборки

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

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

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

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

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

С появлением выражений шаблонов в определении ресурса репозитория можно написать конвейер следующим образом:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

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

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

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

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

При указании выражения шаблона для ref свойства ресурса репозитория можно использовать parameters предопределенные системные переменные и , но нельзя использовать переменные, определенные в пользовательском интерфейсе YAML или Pipelines.

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

Мы добавили поддержку выражений шаблона при определении endpointсвойств container , volumes, portsи options ресурса в конвейере YAML. Эта функция была очень востребована нашим Сообщество разработчиков.

Теперь вы можете написать конвейеры YAML, как показано ниже.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

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

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

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

Улучшено сообщение об ошибке при сбое загрузки конвейеров

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

Не синхронизировать теги при выборке репозитория Git

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

Этим поведением можно управлять либо из ФАЙЛА YAML, либо из пользовательского интерфейса.

Чтобы отказаться от синхронизации тегов через YAML-файл, добавьте на fetchTags: false шаг оформления заказа. fetchTags Если параметр не указан, он будет таким же, как и при fetchTags: true использовании.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

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

Если этот параметр указан как в YAML-файле, так и в пользовательском интерфейсе, приоритет будет иметь значение, указанное в файле YAML.

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

Artifacts

Обновлены разрешения веб-канала по умолчанию

Учетные записи службы сборки коллекции проектов теперь будут иметь роль Участника совместной работы по умолчанию при создании нового веб-канала Azure Artifacts в области коллекции проекта вместо текущей роли Участника .

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

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

Отчеты

Показать родительский элемент в мини-приложении результатов запроса

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

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

Копировать панель мониторинга

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

Изображение с копией панели мониторинга

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

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

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

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

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

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

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

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

Представление аналитики в навигации по доскам.

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

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

Мы рады сообщить, что мини-приложение запроса на вытягивание для нескольких репозиториев доступно в Azure DevOps Server 2022.1. С помощью этого нового мини-приложения вы можете легко просматривать запросы на вытягивание из 10 различных репозиториев в одном упрощенном списке, что упрощает выполнение запросов на вытягивание.

Мини-приложение с несколькими репозиториями в общедоступной доступности

Запрос на предложение сообщества

Общие сведения о том, как разрешено как завершено в диаграммах сгорания и выгорания

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

Gif для демонстрации разрешается как завершенный в диаграммах с прогоражением и сгоранием.

Вики

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

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

  • Блок-схема
  • Схемы последовательностей
  • Диаграммы Гантта
  • Круговые диаграммы
  • Схемы требований
  • Схемы состояний
  • Путь взаимодействия пользователя

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

Отзывы

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

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