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

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

  • Статья

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

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

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

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

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

Дата выпуска Azure DevOps Server 2022 с Обновлением 2, Патч 5: 8 апреля 2025 г.

Файлы Хэш SHA-256
devops2022.2patch5 299AC29F15BC254167C2987450EF722B083594AFA885A8DAB46625C92D982C1C

Мы выпустили исправление 5 для Azure DevOps Server 2022 с обновлением 2, чтобы включить:

Внимание

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

  • Ранее агент Azure DevOps использовал CDN Edgio с конечной точкой vstsagentpackage.azureedge.net. В рамках прекращения работы Edgio, домен *.azureedge.net выводится из эксплуатации. Для обеспечения непрерывной доступности мы перешли на CDN, поддерживаемый Akamai, с новым конечным узлом download.agent.dev.azure.com. Этот патч включает необходимые изменения для извлечения двоичных файлов агента из новой конечной точки CDN, что позволит прекратить использование предыдущей конечной точки CDN.

Дата выпуска Azure DevOps Server 2022 с обновлением 2 и пакетом исправлений 4: 11 марта 2025 г.

Файлы Хэш SHA-256
devops 2022.2 patch 4 975B0FC28737C15BA40D6E084663D1A735A66FA821EB40C7A377AE3D58F0C7DA

Мы выпустили исправление 4 для Azure DevOps Server 2022 с обновлением 2, чтобы включить:

  • Обновление информации по задачам в связи с прекращением поддержки Edgio CDN. Дополнительные сведения см. в записи блога о переключении поставщиков CDN.
  • Обновленная зависимость русалки.

Дата выхода Azure DevOps Server 2022 Обновление 2 Патч 3: 11 февраля 2025 г.

Примечание.

В понедельник 24 февраля 2025 г. мы повторно выпустили исправление 3 для Azure DevOps Server 2022.2. Если вы ранее установили более раннюю версию этого исправления, обновите его с помощью предоставленной ссылки. Переиздание устраняет проблему, из-за которой конвейеры YAML завершаются сбоем. Дополнительные сведения об этой проблеме можно найти в сообществе разработчиков .

Файлы Хэш SHA-256
devops2022.2patch3 F5C2DA846B8A38A1FB55D1EB555FB2FD6B974B0436F573CC01A0FEBAF3D67521

Мы выпустили Исправление 3 для Azure DevOps Server 2022 Update 2, чтобы включить:

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

Файлы Хэш SHA-256
devops2022.2patch2.exe 70930BE091607B490890A48C250DAB6C2087F7F610CC695C9C632C679A491D23

Мы выпустили Патч 2 для Azure DevOps Server 2022 Обновление 2, чтобы обновить уязвимую зависимость.

Дата выпуска Azure DevOps Server 2022.2 RTW: 9 июля 2024 г.

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

Примечание.

Мы повторно выпустили Azure DevOps Server 2022.2, чтобы устранить проблему с загрузкой имен Teams. Проблема была упомянута в записи блога Azure DevOps Server 2022.2 RTW. Если вы установили версию Azure DevOps Server 2022.2, выпущенную 9 июля, можно установить исправление 1 для Azure DevOps Server 2022.2 , чтобы устранить эту проблему. Исправление 1 не требуется, если вы устанавливаете Azure DevOps Server 2022.2 впервые после обновления ссылок загрузки, чтобы включить исправление.

Azure DevOps Server 2022.2 RTW — это обновление, включающее исправления ошибок. Он включает все функции, которые ранее были выпущены в выпуске-кандидате Azure DevOps Server 2022.2 RC. Вы можете напрямую установить Azure DevOps Server 2022.2 или обновить с Azure DevOps Server 2020, 2019 или Team Foundation Server 2015 или более поздней версии. В этом выпуске устранены следующие проблемы и уязвимости:

Дата выпуска Azure DevOps Server 2022 Update 2 RC: 7 мая 2024 г.

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

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

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

Публикация задачи "Результаты теста"

Задача "Опубликовать результаты теста" теперь поддерживает вложения тестового запуска для формата отчета JUnit.

Новая версия пакета SDK для веб-расширения Azure DevOps

В этом обновлении мы выпускаем новую версию пакета SDK для веб-расширений Azure DevOps. Клиентская библиотека SDK предоставляет веб-расширениям возможность взаимодействовать с основной страницей. Его можно использовать для:

  • Сообщите узлу, что расширение загружено или имеет ошибки
  • Получение основных контекстных сведений о текущей странице (сведения о текущем пользователе, узле и расширении)
  • Получение сведений о теме
  • Получите токен авторизации, чтобы использовать его в REST-вызовах обратно в Azure DevOps
  • Получите удаленные сервисы, предлагаемые хостовой рамкой

Полный справочник по API можно найти в документции пакета azure-devops-extension-sdk. Эта новая версия обеспечивает поддержку следующих модулей:

  • Поддержка модулей ES: пакет SDK теперь поддерживает модули ES (ECMAScript) в дополнение к существующим модулям AMD (асинхронное определение модуля). Теперь пакет SDK можно импортировать с помощью синтаксиса модуля ES, который обеспечивает улучшения производительности и уменьшает размер приложения.

  • Обратная совместимость для модулей AMD: существующая поддержка модулей AMD остается нетронутой. Если проект использует модули AMD, вы можете продолжать использовать их, как и раньше, без каких-либо изменений.

Практическое руководство.

Для модулей ES можно импортировать наши модули с помощью инструкции импорта:

import * as SDK from 'azure-devops-extension-sdk';
// Use the module here

Если вы используете модули AMD, вы можете продолжать импортировать пакет SDK с помощью require функции:

require(['azure-devops-extension-sdk'], function(SDK) {

  // Use the module here
});

Доски

Ограничения для маршрутов области и итерации

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

Снимки экрана: пути областей и итераций.

Контроли разработки и развертывания

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

Снимок экрана служб DevOps.

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

Снимки экрана связанной работы.

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

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

Репозитории

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

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

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

На следующем рисунке показан пулл-реквест, созданный пользователем A, и дополнительные 4 коммита (итерации), сделанные для этого пулл-реквеста пользователями B, C, снова A и C. После завершения второй итерации (коммита, сделанного пользователем B), пользователь C одобрил его. В то время это подразумевало одобрение первого коммита пользователя A (в момент создания запроса на вытягивание), и новая введенная политика будет успешно реализована. После пятой итерации (последняя фиксация пользователя C) утверждение было сделано пользователем A. Это подразумеваемое утверждение для предыдущей фиксации, выполненной пользователем C, но не подразумевало утверждение второй фиксации, выполненной пользователем A в четвертой итерации. Чтобы недавно введенная политика увенчалась успехом, итерация четыре должна быть утверждена либо пользователем B, C, либо любым другим пользователем, который не внес никаких изменений в pull request.

Изображение управления разрешениями.

Примечание.

Существует известная проблема, из-за которой политики ветви будут принимать группу, настроенную в качестве рецензента, как одобряющую сущность. Предположим, что существует требуемое утверждение, сделанное любым пользователем группы G. User A является членом этой группы G. После того как пользователь A предоставляет утверждение, как показано на рисунке выше (после пятой итерации), утверждение Группы G утверждает изменение, выполненное пользователем A. Это не ожидается и будет разрешено в выпуске RTW.

Поддержка фильтров без BLOB и деревьев

Внимание

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

exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1

Azure DevOps теперь поддерживает два дополнительных фильтра во время клонирования и извлечения. Ниже приведены следующие параметры: --filter=blob:none и --filter=tree:0 Первый вариант (клон без больших двоичных объектов) лучше всего используется для регулярной разработки, а второй вариант (клон без дерева) лучше подходит для тех случаев, когда вы удаляете клон, например, после запуска сборки.

Упразднение SSH-RSA

Azure Repos предоставляет два метода для доступа пользователей к репозиторию git в Azure Repos — HTTPS и SSH. Чтобы использовать SSH, необходимо создать пару ключей с помощью одного из поддерживаемых методов шифрования. В прошлом мы поддерживали только SSH-RSA, и мы попросили пользователей включить SSH-RSA здесь.

В этом обновлении мы объявляем об отмене SSH-RSA в качестве поддерживаемого метода шифрования для подключения к Azure Repos с помощью SSH. Дополнительные сведения см. в записи блога Окончание поддержки SSH-RSA для Azure Repos.

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

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

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

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

Снимок экрана: триггер CI YAML.

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

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

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

Скриншот повторной попытки этапа.

Обход согласований и проверок

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

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

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

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

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

Обойти процесс утверждения.

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

Обход проверки рабочих часов.

Снимок экрана: обход проверки рабочих часов.

Обход проверки вызова функции Azure. Обход проверки рабочих часов.

Снимок экрана проверки обхода вызова функции Azure.

При пропуске проверки её можно увидеть на панели проверок.

Снимок экрана: проверка пропущена.

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

Снимок экрана: обязательный шаблон YAML.

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

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

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

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

Снимок экрана: динамическая проверка.

Примечание.

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

Поддержка корпоративного сервера GitHub в требуемой проверке шаблона

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

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

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

Роль администратора во всех средах

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

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

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

Снимок экрана: роль администратора.

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

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

Улучшенная проверка YAML

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

Снимок экрана: проверка YAML.

Проверка YAML теперь более тщательна, когда речь идет о выражениях.

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

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

variables:
  Major: '1'
  Minor: '0'
  Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]

Переменная Patch определяется с помощью counter функции и других двух переменных. В приведенном выше коде YAML в слове format есть опечатка. Ранее эта ошибка не была обнаружена. Теперь функция проверки обнаружит это и обнаружит сообщение об ошибке.

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

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

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

steps:
- task: NuGetCommand@2
  condition: eq(variable.Patch, 0)
  inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

Задача NuGetCommand выполняется только в том случае, если значение переменной Patch равно 0. Опять же, в условии есть опечатка, и функция проверки отобразит ее.

Снимок экрана переменной патча.

Azure Pipelines обнаружит неверные условия YAML, определенные на уровне конвейера или этапа или задания.

REST API для средовых окружений

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

Мы знаем, что вы хотите создавать среды программным способом, поэтому мы опубликовали документацию по REST API.

Улучшения REST API согласований

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

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

Например, следующий вызов GET REST API https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending возвращает

{
    "count": 1,
    "value":
    [
        {
            "id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
            "steps":
            [],
            "status": "pending",
            "createdOn": "2023-11-09T10:54:37.977Z",
            "lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers":
            [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
                }
            },
            "pipeline":
            {
                "owner":
                {
                    "_links":
                    {
                        "web":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
                        },
                        "self":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
                        }
                    },
                    "id": 73222930,
                    "name": "20231109.1"
                },
                "id": "4597",
                "name": "FabrikamFiber"
            }
        }
    ]
}

Журналы конвейеров теперь содержат использование ресурсов

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

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

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

Агент Azure Pipelines теперь поддерживает Alpine Linux

Агент конвейера версии 3.227 теперь поддерживает Alpine Linux версии 3.13 и выше. Alpine Linux — это популярный базовый образ для контейнеров. Агента можно найти на странице выпусков. В версиях агента Alpine Linux есть префикс vsts-agent-linux-musl , например vsts-agent-linux-musl-x64-3.227.1.tar.gz.

Задачи Azure Pipelines используют узел 16

Задачи в конвейере выполняются с помощью средства запуска, которое в большинстве случаев использует Node.js. Задачи Azure Pipelines, которые используют Node в качестве исполнителя, теперь используют Node 16. Так как Node 16 является первой версией Node, которая нативно поддерживает Apple silicon, это также обеспечивает полную поддержку функций для macOS на Apple silicon. Агенты, работающие на процессорах Apple, не нуждаются в программе Rosetta для работы.

Поскольку срок окончания поддержки Node 16 перенесен на более ранний срок, мы начали работу по выполнению задач с Node 20.

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

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

Задача AzureRmWebAppDeployment поддерживает проверку подлинности идентификатора Microsoft Entra

Задачи AzureRmWebAppDeploymentV3 и AzureRmWebAppDeployment@4 были обновлены для поддержки службы приложений с отключенной базовой проверкой подлинности. Если базовая проверка подлинности отключена в Службе приложений, задачи AzureRmWebAppDeploymentV3/4 используют проверку подлинности с помощью удостоверения Microsoft Entra для выполнения развертываний в конечной точке Kudu Службы приложений. Для этого требуется последняя версия msdeploy.exe, установленная на агенте, что относится к windows-2022/windows-latest Hosted agents (см справочник по задачам).

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

Ранее состояние политики покрытия кода изменялось на "Сбой" в случае, если сборка в запросе на внесение изменений (PR) завершалась неудачей. Это стало препятствием для некоторых из вас, у кого сборка была настроена как необязательная проверка, а политика покрытия кода - как обязательная проверка для PR, что приводило к их блокировке.

Снимок экрана: заблокированные PR.

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

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

Артефакты

Представление поддержки Azure Artifacts для Cargo Crates

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

Объявление о прекращении поддержки для задач конвейера NuGet Restore версии 1 и NuGet Installer v0

Если вы используете задачи конвейера NuGet Restore версии 1 и NuGet Installer версии 0, быстро переходите к задаче конвейера NuGetCommand@2. Если вы не выполните этот переход, в скором времени в ваши конвейеры начнут поступать предупреждения. Если никакие действия не будут предприняты, с 27 ноября 2023 года ваши сборки будут завершаться сбоем.

Поддержка аудита npm в Azure Artifacts

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

Отчетность

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

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

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

Попробуйте сейчас и сообщите нам, что вы думаете в нашем сообществе Azure DevOps

Фильтрация рабочих элементов

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

Гиф для демонстрации фильтрации рабочих элементов.

Ваши отзывы бесценны в формировании будущего этой функции. Попробуйте сейчас и сообщите нам, что вы думаете в нашем сообществе Azure DevOps.

Результаты покрытия кода для папок

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

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

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

Быстрое копирование и импорт по идентификатору тестового плана или набора тестов

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

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

GIF для демонстрации плана тестирования, сведений о поиске идентификатора Suite.

Обновление для тестового раннера Azure

Мы рады поделиться тем, что средство запуска тестов Azure обновлено до более новой версии. Это обновление повышает стабильность и производительность, позволяя выполнять тесты без прерываний или задержек. Более старая версия Azure Test Runner больше не поддерживается. Для повышения производительности и зависимости операций тестирования рекомендуется обновить до последней версии как можно скорее.

Новые возможности

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

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

Отзывы

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

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