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

  • Статья

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

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

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

Чтобы скачать 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.

File Хэш SHA-256
devops2022.0.1patch5.exe DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

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

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

Azure DevOps Server 2022 г. Обновление 0.1. Обновление 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, связанная с повышением привилегий.

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

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

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

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

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

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

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

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

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

Azure DevOps Server 2022.0.1 RC — это сводный пакет исправлений ошибок. Он включает все исправления в ранее выпущенных исправлениях 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 Server.
  • Уведомления не отправлялись за 7 дней до даты окончания срока действия pat.

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

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

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

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

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

  • Устранена проблема, которая требовала перезапуска службы tfsjobagent и Azure DevOps Server пула приложений после обновления параметра, связанного с SMTP, в консоли управления Azure DevOps Server.
  • Скопируйте состояние конечной точки на панель редактирования конечной точки службы вместо передачи по ссылке.
  • Ранее при изменении подключений к службе изменения сохранялись в пользовательском интерфейсе после нажатия кнопки отмены. С помощью этого исправления мы исправили в пакете 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 2022 г. Обновление 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. Планы доставки предоставляют три основных сценария:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Еще один пример просмотра зависимостей

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

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

    Рассмотрим некоторые примеры.

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

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

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

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

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

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

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

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

Параметры стиля

  • До

Стилизация карт перед

  • После

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

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

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

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

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

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

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

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

Как и для всех других типов рабочих элементов, тип рабочего элемента Bug имеет четко определенный рабочий процесс. Каждый рабочий процесс состоит из трех или более состояний и причины. Причины указывают, почему элемент переходит из одного состояния в другое. В этом обновлении мы добавили значение Не исправляет причину для типов рабочих элементов Ошибка в гибком процессе. Значение будет доступно в качестве причины при перемещении ошибок из "Новые" или "Активные" в "Устранено". Дополнительные сведения об определении, отслеживании, рассмотрении ошибок программного обеспечения и управлении ими см. в 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 для размещения множества подпроектов, каждый из которых имеет собственный репозиторий Git Azure DevOps и один или несколько конвейеров. В этой структуре может потребоваться указать, какие конвейеры могут обращаться к тем или иным репозиториям. Например, предположим, что у вас есть два репозитория 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-файлах стало проще благодаря использованию выражений ${{ else }} и ${{ elseif }} . Ниже приведены примеры использования этих выражений в файлах конвейеров 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 метки в агентах Azure Pipelines, размещенных у Майкрософт. До сих пор эта метка указывала на агентов Windows-2019. Это изменение будет развернуто в течение нескольких недель, начиная с 17 января. Мы планируем завершить миграцию к марту.

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

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

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

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

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

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

Агент конвейера Azure DevOps — это программный продукт, который выполняется на узле конвейера для выполнения заданий конвейера. Он выполняется на размещенных агентах Майкрософт, агентах масштабируемого набора и локальных агентах. В последнем случае вы устанавливаете его самостоятельно. Агент конвейера состоит из прослушивателя и рабочей роли (реализованной в .NET). Рабочая роль выполняет задачи, которые реализуются в Node или 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 свойство для компонентов конвейера YAML , deploymentи stage , предназначенных для jobиспользования в сочетании с шаблонами.

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

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

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

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

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

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

Repos

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

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

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

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

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

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

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

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

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

Настройка создателей ветвей так, чтобы они не получили "Управление разрешениями" в своих ветвях

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

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

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

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

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

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

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

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

Отчеты

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

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


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

Отображение настраиваемых типов рабочих элементов в мини-приложении burndown

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

Отзывы

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

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