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


| | Сообщество разработчиков Системные требования и условия совместимости условий лицензионного | соглашения | DevOps блог | SHA-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 RC1 Дата выпуска: 9 августа 2022 г.

Общие сведения о новых возможностях Azure DevOps Server 2022 г.

Важно!

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

Azure DevOps Server 2022 г. содержит множество новых возможностей. Вот некоторые из них:

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


Boards

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Вот несколько примеров.

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

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

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

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

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

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

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

Теперь карточки можно стильировать с помощью правил, таких как канбан-доски. Откройте параметры плана и щелкните "Стили". В области "Стили" щелкните "+ Добавить правило стиля ", чтобы добавить правило, а затем нажмите кнопку "Сохранить". Существует до 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 для размещения множества вложенных проектов— каждый из которых имеет собственный репозиторий 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 стало проще с помощью выражений и ${{ 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 метки в агентах, размещенных в Azure Pipelines. До сих пор эта метка указывает на агенты Windows-2019. Это изменение будет развернуто в течение нескольких недель, начиная с 17 января. Мы планируем завершить миграцию к марту.

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

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

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

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

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

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

Агент конвейера 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 свойство для jobdeploymentstage компонентов конвейера YAML, предназначенных для использования в сочетании с шаблонами.

Ниже приведен сценарий использования 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 определения сборки устарело

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

Repos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отчеты

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

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


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

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

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

Вики

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

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

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

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


Отзывы

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


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