Поделиться через

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

  • Статья

| Сообщество разработчиков Системные требования и условия лицензионного | соглашения | devOps блог | SHA-256 | |

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

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

Чтобы скачать продукты 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 необходимо выполнить некоторые промежуточные действия. Дополнительные сведения см. на странице "Установка".

Дата выпуска обновления 4 для Azure DevOps Server 2022 с обновлением 4: 11 июня 2024 г.

Файлы Хэш SHA-256
devops2022.1patch4.exe 29012B79569F042E2ED4518CE721CA521F9435CCD80295B71F734AA60FCD03F

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

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

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

Файлы Хэш SHA-256
devops2022.1patch3.exe E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

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

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

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

Файлы Хэш SHA-256
devops2022.1patch2.exe 59B3191E86DB787F91F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

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

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

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

Файлы Хэш SHA-256
devops2022.1patch1.exe 9D0FDCCDD1F20461E58689B756E600CC16424018A377042F7DC3A6EEF096FB6

Мы выпустили исправление 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 Resolver по умолчанию до собственного 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 Resolver по умолчанию до собственного 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 Resolver по умолчанию до собственного HTTP из Wagon. Это приводит к возникновению проблем с проверкой подлинности 401 для клиентов, использующих http, а не https. Дополнительные сведения об этой проблеме см. здесь.

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

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

  • Исправлена проблема в локальных веб-каналах, из-за которых вышестоящие записи не разрешали изменения отображаемого имени.
  • При переключении вкладок с кода на другую вкладку на странице поиска произошла непредвиденная ошибка.
  • Ошибка при создании нового типа рабочего элемента с использованием китайских, японских и корейских (CJK) унифицированных иеографов. Вопросительный знак отображался в журнале RAW при входе в систему во встроенном входе, когда имя проекта команды или файлы включали CJK.
  • Исправлена проблема при установке поиска, из-за которой виртуальная машина Java (JVM) не могла выделить достаточно памяти для процесса эластичного поиска. Мини-приложение конфигурации поиска теперь будет использовать Пакет средств разработки Java (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). Использование полного маркера личного доступа повышает риск, когда он может приземлиться в руках злоумышленника. Это одна из основных причин, по которым многие из наших клиентов не воспользовались всеми преимуществами политик плоскости управления, чтобы ограничить использование и поведение PAT.

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

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

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

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

Boards

Столбец Last Accessed на странице "Планы доставки"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы просмотреть эти диаграммы, перейдите на вкладку "Аналитика" на страницах Kanban Board, Backlog и Sprints.

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

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

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

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

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

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

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

Большинство ИНТЕРФЕЙСов REST API в Azure DevOps используют маркеры PAT с областью действия. Однако для некоторых из них требуются полностью ограниченные маркеры PAT. Другими словами, необходимо создать маркер PAT, выбрав "Полный доступ", чтобы использовать некоторые из этих API. Такие маркеры представляют угрозу безопасности, так как их можно использовать для вызова любого 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 теперь предоставляет точное управление доступом для пулов агентов. Этот интерфейс аналогичен одному для управления разрешениями конвейера для подключений к службе.

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

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

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

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

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

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

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

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

Все вхождения значения секрета маскируются. Маскирование коротких секретов, например '', '12'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 обновлен для выполнения проверок в версиях runner node, см. в записи блога по запуску узла.

Расширения, содержащие задачи с помощью средства выполнения 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.

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

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

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

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

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

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

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

Задачи можно использовать для определения автоматизации в конвейере. Одной из этих задач является PowerShell@2 задача служебной программы, которая позволяет выполнять скрипты PowerShell в конвейере. Чтобы использовать скрипт PowerShell для целевой среды Azure, можно использовать AzurePowerShell@5 эту задачу. Некоторые команды PowerShell, которые могут печатать обновления хода выполнения, теперь Invoke-WebRequestвыполняются быстрее. Улучшение является более значительным, если у вас есть многие из этих команд в скрипте или когда они долго работают. При этом обновлении progressPreference свойство PowerShell@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, состояние этапа выполнения изменилось одним из этих событий. Событие изменения состояния этапа выполнения должно содержать сведения о выполнении, включая имя конвейера. Ранее она включала только сведения об идентификаторе и имени запуска. В этом обновлении мы внесли изменения в событие, чтобы включить недостающие сведения.

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

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

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

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

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

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

Мы сделали отладку менее мучительной. Иногда проверка REST API "Вызов функции 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.

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

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

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

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

  • Если шаблон имеет необходимые параметры, которые не предоставляются в качестве входных данных в основном файле YAML, проверка завершается ошибкой и запрашивает предоставление этих входных данных. В идеальном интерфейсе проверка не должна быть заблокирована, и вы сможете заполнить входные параметры с помощью 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 }}

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

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

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

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

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

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

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.

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

Мы добавили поддержку выражений container шаблонов при определении endpoint, volumesportsи 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, но не те, которые определены в пользовательском интерфейсе Pipelines. Если переменная переопределяется, например с помощью команд журнала агента, она не будет иметь никакого эффекта.

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

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

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

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

Отчетность

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

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

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

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

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

Изображение с помощью панели мониторинга копирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Знакомство с разрешенным как завершенным в диаграммах сгорения и сгорания

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

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

Вики

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

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

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

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

Отзывы

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

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