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

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

  • Статья

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

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

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

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

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

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

Примечание.

Исправления Azure DevOps Server являются накопительными, если вы не установили исправление 3, это исправление включает обновления агента Azure Pipelines. Новая версия агента после установки исправления 5 будет 3.225.0.

Файлы Хэш SHA-256
devops2022.0.1patch5.exe DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

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

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

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

Примечание.

Исправления Azure DevOps Server являются накопительными, если вы не установили исправление 3, это исправление включает обновления агента Azure Pipelines. Новая версия агента после установки исправления 5 будет 3.225.0.

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

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

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

Примечание.

Это исправление включает обновления агента Azure Pipelines. Новая версия агента после установки исправления 3 будет 3.225.0.

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

  • CVE-2023-33136: уязвимость удаленного выполнения кода Azure DevOps Server.
  • CVE-2023-38155: Azure DevOps Server и Team Foundation Server — уязвимость к повышению привилегий.

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

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

  • CVE-2023-36869: уязвимость сервера Azure DevOps Server Spoofing.
  • Исправлена ошибка в вызовах SOAP, в которых можно вызвать ArithmeticException для XML-ответа больших метаданных.
  • Реализованы изменения в редакторе подключений к службе, чтобы состояние конечной точки очищалось от компонента.
  • Устранена проблема с относительными ссылками, не работающими в файлах Markdown.
  • Исправлена проблема с производительностью, связанная с уровнем приложений, занимает больше времени, чем обычно при запуске, когда определено большое количество тегов.
  • Устранены ошибки TF400367 на странице пулов агентов.
  • Исправлена ошибка, из-за которой идентификатор владельца анализа показал как неактивное удостоверение.
  • Исправлена ошибка бесконечного цикла в CronScheduleJobExtension.

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

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

  • CVE-2023-21565: уязвимость spoofing сервера Azure DevOps.
  • CVE-2023-21569: уязвимость spoofing сервера Azure DevOps.
  • Исправлена ошибка с редактором подключений к службе. Теперь черновик состояния конечной точки очищается при закрытии компонента.
  • Исправлена ошибка, из-за которой отсоединение или присоединение коллекции не сообщалось следующей ошибке: "TF246018: операция базы данных превысила ограничение времени ожидания и была отменена.

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

Azure DevOps Server 2022.0.1 — это свертка исправлений ошибок. Он включает все исправления в ранее выпущенном rc-кандидате Azure DevOps Server 2022.0.1. Вы можете напрямую установить Azure DevOps Server 2022.0.1 или обновить с Azure DevOps Server 2022 или Team Foundation Server 2015 или более поздней версии.

Дата выпуска rc 0.1 для Azure DevOps Server 2022: 11 апреля 2023 г.

Azure DevOps Server 2022.0.1 — это свертка исправлений ошибок. Он включает все исправления в ранее выпущенных исправлениях Azure DevOps Server 2022. Вы можете напрямую установить Azure DevOps Server 2022.0.1 или обновить с Azure DevOps Server 2022 или Team Foundation Server 2015 или более поздней версии.

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

  • Обновленная виртуальная файловая система Git (GVFS) до версии 2.39.1.1-micorosoft.2 для устранения уязвимости безопасности.
  • Тестовые данные не удаляются, что приводит к росту базы данных. В этом исправлении мы обновили хранение сборки, чтобы предотвратить создание новых потерянных тестовых данных.
  • Обновления в AnalyticCleanupJob, состояние задания было остановлено, и теперь мы сообщаем об успешном выполнении.
  • Исправлена ошибка "публикация расширения tfx" с ошибкой "Заданный ключ отсутствует в словаре".
  • Реализовано обходное решение для устранения и ошибки при доступе к расширению "Календарь команды".
  • CVE-2023-21564: уязвимость azure DevOps Server для межсайтовых сценариев
  • CVE-2023-21553: уязвимость удаленного выполнения кода Azure DevOps Server
  • Обновлены задачи MSBuild и VSBuild для поддержки Visual Studio 2022.
  • Методология обновления повторной проверки подлинности для предотвращения вектора атак XSS.
  • Прокси-сервер Azure DevOps Server 2022 сообщает следующую ошибку: VS800069: эта служба доступна только в локальной среде Azure DevOps.
  • Исправлена проблема с специальными возможностями наборов полков через веб-интерфейс.
  • Устранена проблема, требующая перезапуска службы tfsjobagent и пула приложений Azure DevOps Server после обновления параметра, связанного с SMTP, в консоли управления сервера Azure DevOps.
  • Уведомления не отправляются на PAT семь дней до окончания срока действия.

Дата выпуска Azure DevOps Server 20222 с исправлением 4: 13 июня 2023 г.

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

  • CVE-2023-21565: уязвимость spoofing сервера Azure DevOps.
  • CVE-2023-21569: уязвимость spoofing сервера Azure DevOps.
  • Исправлена ошибка с редактором подключений к службе. Теперь черновик состояния конечной точки очищается при закрытии компонента.
  • Исправлена ошибка, из-за которой отсоединение или присоединение коллекции не сообщалось следующей ошибке: "TF246018: операция базы данных превысила ограничение времени ожидания и была отменена.

Дата выпуска Azure DevOps Server 20222 с исправлением 3: 21 марта 2023 г.

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

  • Устранена проблема, требующая перезапуска службы tfsjobagent и пула приложений Azure DevOps Server после обновления параметра, связанного с SMTP, в консоли управления сервера Azure DevOps.
  • Скопируйте состояние конечной точки в панель редактирования конечной точки службы вместо передачи по ссылке.
  • Ранее при редактировании подключений к службе изменения сохранялись в пользовательском интерфейсе после нажатия кнопки отмены. С помощью этого исправления мы исправлены в пакете SDK для уведомлений, если команда имеет набор уведомлений, для которой задано значение "Не доставлять". В этом сценарии, если подписка на уведомление настроена с параметром доставки предпочтений группы, участники команды не получат уведомления. Нет необходимости расширять удостоверения в группе дальше, чтобы проверить настройки участников.

Дата выпуска Azure DevOps Server 2022 с исправлением 2: 14 февраля 2023 г.

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

  • CVE-2023-21564: уязвимость azure DevOps Server для межсайтовых сценариев
  • Обновлены задачи MSBuild и VSBuild для поддержки Visual Studio 2022.
  • Методология обновления повторной проверки подлинности для предотвращения возможного вектора атак XSS.
  • Прокси-сервер Azure DevOps Server 2022 сообщает следующую ошибку: VS800069: эта служба доступна только в локальной среде Azure DevOps.

Дата выпуска Azure DevOps Server 20222 с исправлением 1: 24 января 2023 г.

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

  • Тестовые данные не удаляются, что приводит к росту базы данных. В этом исправлении мы обновили хранение сборки, чтобы предотвратить создание новых потерянных тестовых данных.
  • Обновления в AnalyticCleanupJob, состояние задания было остановлено, и теперь мы сообщаем об успешном выполнении.
  • Исправлена ошибка "публикация расширения tfx" с ошибкой "Заданный ключ отсутствует в словаре".
  • Реализовано обходное решение для устранения и ошибки при доступе к расширению "Календарь команды".

Дата выпуска Azure DevOps Server 2022: 6 декабря 2022 г.

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

Дата выпуска Azure DevOps Server 2022 RC2: 25 октября 2022 г.

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

Примечание.

Новые алгоритмы RSA SSH

Поддержка открытого ключа RSA была улучшена для поддержки типов открытых ключей SHA2 в дополнение к ранее поддерживаемой версии SHA1 SSH-RSA.

Теперь поддерживаются типы открытых ключей:

  • SSH-RSA
  • RSA-SHA2-256
  • RSA-SHA2-512

Требуемое действие

Если вы реализовали работу, чтобы включить SSH-RSA, явно указав его в .ssh/config1 файле, необходимо удалить PubkeyAcceptedTypesили изменить его для использования RSA-SHA2-256 или RSA-SHA2-512 или обоих. Дополнительные сведения о том, что делать, если вы по-прежнему запрашиваете пароль и GIT_SSH_COMMAND="ssh -v" git fetch не отображаете алгоритм взаимной подписи в документации.

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

Дата выпуска Azure DevOps Server 2022 RC1: 9 августа 2022 г.

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

Внимание

Служба хранилища и анализа не рекомендуется использовать в предыдущей версии Azure DevOps Server (2020). В Azure DevOps Server 2022 служба хранилища и анализа была удалена из продукта. Аналитика теперь предоставляет возможности создания отчетов в продукте.

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

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

Boards

Планы выполнения

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

  • Представление временной шкалы плана
  • Ход выполнения работы
  • Отслеживание зависимостей

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

Существует два основных представления: сжатые и развернутые

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

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

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

  • Сжатое представление

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

    Ниже приведен пример переключения плана между сжатыми и расширенными представлениями.

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

  • Развернутое представление

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

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

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

Отслеживание зависимостей

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

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

  • Просмотр зависимостей

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

    Пример просмотра зависимостей

    Другой пример просмотра зависимостей

  • Строки зависимостей

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

    Ниже приведено несколько примеров.

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

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

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

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

    Ниже приведен пример.

    Пример рабочего элемента с несколькими зависимостями

Стилизация карточки

Теперь карточки можно стильировать с помощью правил, таких как доски Kanban. Откройте параметры плана и щелкните "Стили". В области стилей щелкните + Добавить правило стили, чтобы добавить правило, а затем нажмите кнопку "Сохранить". Существует до 10 правил, и каждое правило может содержать до 5 предложений.

Параметры стилизации

  • Перед

Стилизация карточки до

  • После

Стилизация карточки после

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

Удаленные элементы в Центре рабочих элементов

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

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

Удаление возможности скачивания удаленного вложения из журнала рабочих элементов

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

Добавлено значение "Не исправлять" в поле причины ошибки

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

Pipelines

Удаление политик хранения для каждого конвейера в классических сборках

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

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

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

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

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

Агент Azure Pipelines сканирует стандартные выходные данные для специальных команд ведения журнала и выполняет их. Команду setVariable можно использовать для задания переменной или изменения ранее определенной переменной. Это может быть использовано субъектом за пределами системы. Например, если в конвейере есть шаг, который печатает список файлов на ftp-сервере, то пользователь с доступом к ftp-серверу может добавить новый файл, имя которого содержит setVariable команду и привести конвейер к изменению его поведения.

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

  • Мы добавили новую конструкцию для авторов задач. Включив фрагмент кода, например приведенный ниже task.json, автор задачи может управлять, если какие-либо переменные задаются задачей.
{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​

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

  • Наконец, теперь можно использовать конструкции YAML для управления тем, может ли шаг задать переменные.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Создание неограниченного маркера для сборок вилки

Пользователи GitHub Enterprise обычно используют вилки для участия в вышестоящем репозитории. Когда Azure Pipelines создает вклады из вилки репозитория GitHub Enterprise, он ограничивает разрешения, предоставленные маркеру доступа к заданию, и не разрешает доступ к секретам конвейера с помощью таких заданий. Дополнительные сведения о безопасности сборки вилок см. в нашей документации.

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

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

Создание неограниченного маркера для сборок вилки

Репозитории в качестве защищенного ресурса в конвейерах YAML

Вы можете упорядочить проект Azure DevOps для размещения множества вложенных проектов — каждый из них имеет собственный репозиторий Azure DevOps Git и один или несколько конвейеров. В этой структуре может потребоваться управлять доступом к каким конвейерам можно получить доступ к репозиториям. Например, предположим, что у вас есть два репозитория A и B в одном проекте и два конвейера X и Y, которые обычно создают эти репозитории. Возможно, потребуется запретить конвейеру Y получать доступ к репозиторию A. Как правило, вы хотите, чтобы участники A контролировали, к каким конвейерам они хотят предоставить доступ.

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

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

Добавление проверок

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

Управление списком конвейеров на вкладке

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

Примечание.

Эти разрешения и проверки применимы только к конвейерам YAML. Классические конвейеры не распознают эти новые функции.

Разрешения и проверки групп переменных и безопасных файлов

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

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

Мои секретные переменные

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

Добавление утверждения проверок

Изменения в автоматическом создании сред

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

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

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

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

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

Удаление диалога Аналитики из конвейера сборки

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

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

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

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

Чтобы использовать монопольную проверку блокировки с sequential развертываниями или runLatestвыполните следующие действия.

  1. Включите монопольную проверку блокировки в среде (или другой защищенный ресурс).
  2. В файле YAML для конвейера укажите новое свойство lockBehavior. Это можно указать для всего конвейера или для определенного этапа:

Установите на этапе:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Установите в конвейере:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Если вы не указываете , lockBehaviorпредполагается, что он будет runLatest.

Поддержка версии ServiceNow в Квебеке

Azure Pipelines имеет существующую интеграцию с ServiceNow. Интеграция зависит от приложения в ServiceNow и расширения в Azure DevOps. Теперь мы обновили приложение для работы с версией ServiceNow в Квебеке. Классические и конвейеры YAML теперь работают с Квебеком. Чтобы обеспечить работу этой интеграции, выполните обновление до новой версии приложения (4.188.0) из хранилища Service Now. Дополнительные сведения см. в разделе "Интеграция с serviceNow Change Management".

Новые условные выражения YAML

Написание условных выражений в файлах YAML стало проще с помощью и ${{ elseif }} выражений${{ else }}. Ниже приведены примеры использования этих выражений в файлах конвейеров YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

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

Подстановочные карточки можно использовать при указании ветвей включения и исключения для триггеров CI или PR в файле YAML конвейера. Однако их нельзя использовать при указании фильтров путей. Например, нельзя включать все пути, соответствующие src/app/**/myapp*. Это было отмечено как неудобства несколькими клиентами. Это обновление заполняет этот пробел. Теперь можно использовать подстановочные знаки (**, *или ?) при указании фильтров путей.

Спецификация агента по умолчанию для конвейеров будет windows-2022

Образ windows-2022 готов быть версией по умолчанию для windows-latest метки в агентах, размещенных в Microsoft Pipelines. До сих пор эта метка указывает на агенты Windows-2019. Это изменение будет развернуто в течение нескольких недель, начиная с 17 января. Мы планируем завершить миграцию к марту.

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

Изображение windows-2022 включает Visual Studio 2022. Полный список различий между windows-2022 и windows-2019, перейдите к проблеме GitHub. Полный список программного обеспечения, установленного на образе, см . здесь.

Переименование папки конвейера проверяет разрешения

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

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

Что такое агент конвейера?

Агент конвейера Azure DevOps — это программный продукт, работающий на узле конвейера для выполнения заданий конвейера. Он выполняется в размещенных агентах Майкрософт, агентах масштабируемого набора и локальных агентах. В последнем случае вы устанавливаете его самостоятельно. Агент конвейера состоит из прослушивателя и рабочей роли (реализованной в .NET), рабочие задачи выполняются либо в узле, либо в PowerShell, и поэтому размещают эти среды выполнения для них.

Предстоящее обновление до .NET 6 и Red Hat 6 устарело

С выпуском .NET 6 мы можем воспользоваться новыми кроссплатформенными возможностями. В частности, мы сможем обеспечить встроенную совместимость для Apple Silicon и Windows Arm64. Поэтому мы планируем перейти в .NET 6 для агента конвейера (прослушиватель и рабочая роль) в ближайшие месяцы.

Из-за ряда ограничений, которые это налагает, мы сбрасываем поддержку Red Hat Enterprise Linux 6 от нашего агента 30 апреля 2022 года.

Обновление задачи копирования файлов Azure

Мы развертываем новую версию задачи копирования файлов Azure. Эта задача используется для копирования файлов в большие двоичные объекты хранилища Microsoft Azure или виртуальные машины (виртуальные машины). Новая версия имеет несколько обновлений, которые часто запрашивались сообществом:

  • Версия средства AzCopy обновлена до версии 10.12.2, которая поддерживает типы контента файлов. В результате при копировании PDF-файла, Excel, PPT или одного из поддерживаемых типов mime тип контента файла устанавливается правильно.

  • С помощью новой версии AzCopy можно также настроить параметр для очистки целевого объекта, если целевой тип — BLOB-объект Azure. Установка этого параметра приведет к удалению всех папок и файлов в этом контейнере. Или если указан префикс большого двоичного объекта, все папки и файлы в префиксе будут удалены.

  • Новая версия задачи зависит от модулей Az, установленных на агенте, а не на модулях AzureRM. Это приведет к удалению ненужного предупреждения в некоторых случаях при использовании задачи.

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

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

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

  • Пользовательская кнопка в заголовке конвейера: ms.vss-build-web.pipelines-header-menu
  • Настраиваемое меню в папке конвейера: ms.vss-build-web.pipelines-folder-menu

Чтобы использовать эти новые точки расширяемости, просто добавьте новый вклад, предназначенный для них в файле манифеста vss-extension.json расширения Azure DevOps.

Например:

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

Результатом будет:

  • Пользовательская кнопка в заголовке конвейера

    Пользовательская кнопка в заголовке конвейера

  • Пользовательское меню в папке конвейера

    Пользовательское меню в папке конвейера

Улучшена миграция в Azure DevOps Services

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

Улучшение rest API для конвейеров

Ранее REST API конвейеров возвращал только репозиторийself. При этом обновлении REST API конвейеров возвращает все ресурсы репозитория сборки.

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

В этом обновлении мы добавляем новое templateContext свойство для jobdeploymentкомпонентов конвейера YAML, stage предназначенных для использования в сочетании с шаблонами.

Ниже приведен сценарий использования templateContext:

  • Шаблоны используются для уменьшения дублирования кода или повышения безопасности конвейеров

  • Шаблон принимает в качестве параметра список stages, jobsили deployments

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

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

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

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

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Что делает шаблон для каждого задания в testSet параметре, он задает ответ компонентов системы, указанных ${{testJob.templateContext.requiredComponents }}, чтобы вернуть ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Затем можно создать собственный конвейер, который расширяется testing-template.yml , как показано в следующем примере.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Этот конвейер выполняет два теста, положительный и отрицательный. Для обоих тестов требуется, чтобы dimensionsapi компонент был доступен. Задание positive_test ожидает возвращаемого dimensionsapi HTTP-кода 200, в то время как negative_test ожидает, что он возвращает код HTTP 500.

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

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

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

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Информационные запуски

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

Последние запуски конвейеров

Azure DevOps извлекает исходный код конвейера YAML в ответ на внешние события, например push-фиксацию или в ответ на внутренние триггеры, например, чтобы проверить наличие изменений кода и начать запланированное выполнение или нет. При сбое этого шага система создает информационный запуск. Эти запуски создаются только в том случае, если код конвейера находится в репозитории GitHub или BitBucket.

Получение кода YAML конвейера может завершиться ошибкой из-за:

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

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

Свойство REST API retentionRules сборки определения сборки устарело

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

Repos

Новые страницы TFVC

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

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

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

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

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

  • Может перечислять репозиторий в списке репозиториев
  • Не удается прочитать содержимое репозитория
  • Не удается обновить содержимое репозитория
  • См. сообщение об отключении репозитория при попытке доступа к репозиторию в пользовательском интерфейсе Azure Repos.

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

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

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

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

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

Все параметры репозиториев

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

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

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

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

Параметры репозитория

Отчетность

Группы по тегам, доступным в мини-приложениях диаграмм

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


Группы по тегам, доступным в мини-приложениях диаграмм

Отображение пользовательских типов рабочих элементов в мини-приложении "Сжигание"

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

Отзывы

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

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