Заметки о выпуске Azure DevOpsServer 2020 с обновлением 1

| Сообщество разработчиков System Requirements | Terms License Terms | DevOps Blog | SHA-1 Hashes

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

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

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


Безопасное обновление с Azure DevOps Server 2019 до Azure DevOps Server 2020 г.

Azure DevOps Server 2020 г. представляет новую модель хранения выполнения конвейера (сборки), которая работает на основе параметров уровня проекта.

Azure DevOps Server 2020 года обрабатывает хранение сборок по-разному в зависимости от политик хранения на уровне конвейера. Некоторые конфигурации политики приводят к удалению запусков конвейера после обновления. Запуски конвейера, которые были сохранены вручную или сохраняются в выпуске, не будут удалены после обновления.

Дополнительные сведения о безопасном обновлении с Azure DevOps Server 2019 до Azure DevOps Server 2020 г. см. в нашей записи блога.

Azure DevOps Server 2020 с обновлением 1.2 с исправлением 2: 9 августа 2022 г.

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

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

Azure DevOps Server 2020 с обновлением 1.2 с исправлением 1: 12 июля 2022 г.

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

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

дата выпуска Azure DevOps Server 2020 с обновлением 1.2: 17 мая 2022 г.

Azure DevOps Server 2020 с обновлением 1.2 — это сводка исправлений ошибок. Вы можете напрямую установить Azure DevOps Server 2020 с обновлением 1.2 или с Azure DevOps Server 2020 или Team Foundation Server 2013 или более поздней версии.

Примечание

Средство миграции данных будет доступно для Azure DevOps Server 2020 с обновлением 1.2 примерно через три недели после этого выпуска. Список поддерживаемых сейчас версий для импорта см. здесь.

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

  • Azure DevOps Server 2020.1.2 отключает новую модель хранения (представленную в Azure DevOps Server 2020 г.), чтобы предотвратить потерю запусков конвейера (сборок). Это означает, что система будет:

    • Создание аренды для последних 3 сборок, созданных при запуске Server 2020
    • Для конвейеров YAML и классических конвейеров без политик хранения для каждого конвейера сборки будут храниться в соответствии с максимальными параметрами хранения на уровне коллекции.
    • Для классических конвейеров с настраиваемыми политиками хранения для каждого конвейера сборки будут храниться в соответствии с политикой хранения для конкретного конвейера.
    • Сборки с арендой не учитываются в отношении минимального значения, чтобы сохранить параметр
  • Ссылки на примечания к набору изменений и наборов не перенаправлялись должным образом. При добавлении комментариев к файлам в наборы изменений или наборы полок при выборе этих комментариев не перенаправлялись в нужное место в представлении файлов.

  • Не удается пропустить очередь сборки с помощью кнопки "Выполнить далее". Ранее кнопка "Выполнить далее" была включена только для администраторов коллекции проектов.

  • Отмените все личные маркеры доступа после отключения учетной записи Active Directory пользователя.

Azure DevOps Server 2020.1.1 с исправлением 4: 26 января 2022 г.

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

  • Email уведомления не были отправлены при использовании @mention элемента управления в рабочем элементе.
  • В профиле пользователя не обновлялся предпочитаемый адрес электронной почты. Вследствие этого сообщения отправлялись на предыдущий адрес.
  • Заголовок не отображался на странице сводки проекта. Заголовок был показан в течение нескольких миллисекунд, а затем исчез.
  • Улучшение синхронизации пользователей Active Directory.
  • Устранена уязвимость Elasticsearch за счет удаления класса JndiLookup из двоичных файлов Log4j.

Шаги установки

  1. Обновите сервер с помощью исправления 4.
  2. Проверьте значение реестра по адресу HKLM:\Software\Elasticsearch\Version. Если оно отсутствует, добавьте строковое значение и задайте Version со значением 5.4.1 (Имя = Version, Значение = 5.4.1).
  3. Выполните команду обновления PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update, приведенную в файле сведений. Она может возвращать предупреждение вида Невозможно соединиться с удаленным сервером. Не закрывайте окно, так как обновление будет повторять попытку, пока не сработает.

Примечание

Если Azure DevOps Server и Elasticsearch установлены на разных компьютерах, выполните описанные ниже действия.

  1. Обновите сервер с помощью исправления 4.
  2. Проверьте значение реестра по адресу HKLM:\Software\Elasticsearch\Version. Если оно отсутствует, добавьте строковое значение и задайте Version со значением 5.4.1 (Имя = Version, Значение = 5.4.1).
  3. Скопируйте содержимое папки с именем ZIP, расположенной в C:\Program Files\{TFS Version Folder}\Search\zip папку удаленного файла Elasticsearch.
  4. Запустите Configure-TFSSearch.ps1 -Operation update на компьютере сервера Elasticsearch.

Хэш SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 с обновлением 3: 15 декабря 2021 г.

Исправление 3 для Azure DevOps Server 2020.1.1 включает исправления для следующих компонентов.

  • Исправьте макрос рабочего элемента для запросов с помощью слова "Contains Words". Ранее запросы возвращали неверные результаты для значений, содержащих разрыв строки.
  • Увеличьте ограничения для длины символов версии пакета Maven.
  • Проблема локализации для пользовательских состояний макета рабочих элементов.
  • Проблема локализации в шаблоне уведомлений по электронной почте.
  • Проблема с вычислением правил NOTSAMEAS при определении нескольких правил NOTSAMEAS для поля.

Azure DevOps Server 2020.1.1 с обновлением 2: 26 октября 2021 г.

Исправление 2 для Azure DevOps Server 2020.1.1 включает исправления для следующих компонентов.

  • Ранее Azure DevOps Server могли создавать подключения только к GitHub Enterprise Server. С помощью этого исправления администраторы проектов могут создавать подключения между Azure DevOps Server и репозиториями в GitHub.com. Этот параметр можно найти на странице подключений GitHub в разделе "Параметры проекта".
  • Устраните проблему с мини-приложением плана тестирования. В отчете о выполнении теста отображается неверный пользователь в результатах.
  • Исправлена проблема со страницей сводки "Обзор проекта", из-за неуправляемой загрузки.
  • Исправлена проблема, из-за которой сообщения электронной почты не отправлялись для подтверждения обновления продукта.

Azure DevOps Server 2020.1.1 с обновлением 1: 14 сентября 2021 г.

Исправление 1 для Azure DevOps Server 2020.1.1 включает исправления для следующих компонентов.

  • Исправлена ошибка скачивания и отправки артефактов.
  • Устраните проблему с несогласованными данными результатов теста.

дата выпуска обновления 1.1 Azure DevOps Server 2020 г.: 17 августа 2021 г.

Azure DevOps Server 2020 с обновлением 1.1 — это сводка исправлений ошибок. Вы можете напрямую установить Azure DevOps Server 2020 с обновлением 1.1 или с Azure DevOps Server 2020 или Team Foundation Server 2013 или более поздней версии.

Примечание

Средство миграции данных будет доступно для Azure DevOps Server 2020 с обновлением 1.1 примерно через три недели после этого выпуска. Список поддерживаемых сейчас версий для импорта см. здесь.

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

Azure Boards

  • Гиперссылка "Просмотреть рабочий элемент" в сообщениях с уведомлениями не использует общедоступный URL-адрес.

Azure Repos

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

Azure Pipelines

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

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

  • Исправлена орфография в мастере настройки сервера.
  • Увеличенный размер пакета расширения и позволяет изменять размер в реестре.

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

  • Не удается вернуться к результатам теста после перехода из журнала на страницу сводки.

дата выпуска Azure DevOps Server 2020.1 с исправлением 2: 10 августа 2021 г.

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

  • Исправлена ошибка пользовательского интерфейса определения сборки.
  • Изменен журнал браузера для отображения файлов вместо корневого репозитория.

дата выпуска Azure DevOps Server 2020.1 с исправлением 1: 15 июня 2021 г.

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

  • Безопасные файлы cookie, используемые в потоках авторизации, которые утверждают SameSite=None.

  • Устраните проблему с пакетом SDK для уведомлений. Ранее подписки на уведомления, использующие фильтр пути к области, не были правильно проанализированы.

дата выпуска Azure DevOps Server 2020.1 RTW: 25 мая 2021 г.

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

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

Примечание

Средство миграции данных будет доступно для Azure DevOps Server 2020 с обновлением 1 примерно через три недели после этого выпуска. Список поддерживаемых сейчас версий для импорта см. здесь.

Azure DevOps Server 2020.1 RC2 Дата выпуска: 13 апреля 2021 г.

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

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

дата выпуска rc1 Azure DevOps Server 2020.1: 23 марта 2021 г.

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

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

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


Boards

Правила ограничения перехода состояния

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

img

Вы также можете создать правило для ограничения переходов состояния по членству в группе. Например, только пользователи в группе "Утверждающие" могут перемещать истории пользователей из new -> Approved.

Копирование рабочего элемента для копирования дочерних элементов

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

На этой странице показан новый параметр в Azure Boards включения дочерних рабочих элементов в скопированный рабочий элемент.

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

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

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

Заинтересованные лица могут перемещать рабочие элементы между столбцами доски

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

Типы системных рабочих элементов в невыполненных работах и досках

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

Процесс Тип рабочего элемента
Гибкая методика Проблема
Scrum Препятствие
CMMI Запрос на изменение
Проблема
Просмотр
Риск

Добавление типа системного рабочего элемента на уровень невыполненной работы просто. Просто перейдите к пользовательскому процессу и перейдите на вкладку "Уровни невыполненной работы". Выберите нужный уровень невыполненной работы (пример: невыполненная работа по требованиям) и выберите вариант редактирования. Затем добавьте тип рабочего элемента.

Задержек

Azure Boards превышено ограничение репозитория приложений GitHub

Ограничение репозитория для приложения Azure Boards в marketplace GitHub увеличено с 100 до 250.

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

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

У нас есть новая функция, которая позволяет задать для рабочих элементов требуемое состояние при объединии и завершении запроса на вытягивание. Для этого мы сканируем описание запроса на вытягивание и найдите значение состояния, за которым следует #mention рабочих элементов. В этом примере мы зададим две пользовательские истории в состояние "Разрешено" и закрываем две задачи.

состояние рабочего элемента

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

Связывание рабочих элементов

Редактирование описания (текст справки) в системных полях

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

изменить описание

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

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

Настройка состояния

Родительское поле на доске задач

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

Доска задач родительского поля

Удаление правила "Назначено кому" для типа рабочего элемента ошибки

Существует несколько скрытых системных правил для всех различных типов рабочих элементов в Agile, Scrum и CMMI. Эти правила существуют в течение более десяти лет и, как правило, работали в порядке без каких-либо жалоб. Тем не менее, есть несколько правил, которые иссякнули их приветствие. Одно правило, в частности, вызвало много боли для новых и существующих клиентов, и мы решили, что было время, чтобы удалить его. Это правило существует в типе рабочего элемента "Ошибка" в процессе Agile.

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

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

Удаленные элементы на странице "Рабочие элементы"

Страница "Рабочие элементы" — это отличное место для быстрого поиска созданных или назначенных вам элементов, среди прочего. Она предоставляет несколько персонализированных сводных данных и фильтров. Одна из основных жалоб на сводку "Назначено мне" заключается в том, что она отображает удаленные рабочие элементы (т. е. рабочие элементы в состоянии "Удалено"). И мы согласны! Удаленные элементы — это работа, которая больше не имеет значения и поэтому была удалена из невыполненной работы, поэтому ее включение в это представление не полезно.

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

Repos

Предпочтение имени ветви по умолчанию

Azure Repos теперь предлагает настраиваемое имя ветви по умолчанию для Git. В параметрах репозитория можно выбрать любое юридическое имя ветви, используемое при инициализации репозитория. Azure Repos всегда поддерживает изменение имени ветви по умолчанию для существующего репозитория. Дополнительные сведения см. в разделе "Управление ветвями ".

 default-branch-name

Примечание. Если вы не включите эту функцию, репозитории будут инициализированы с именем по умолчанию Azure Repos. Сейчас по умолчанию используется master. Чтобы соблюдать приверженность Корпорации Майкрософт и запросы клиентов на инклюзивный язык, мы будем присоединяться к отраслевым коллегам , изменив это значение по умолчанию на main. Это изменение произойдет позже этим летом. Если вы хотите продолжать использовать главный сервер, включите эту функцию и задайте для нее значение master.

Параметр уровня организации для ветви по умолчанию

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

Параметр ветви для уровня организации

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

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

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

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

  • Сделать необязательные проверки более видимыми

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


отображение необязательных проверок


  • Нажатие клавиш CTRL для элементов меню

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

  • Расположение заметки [+]

В дереве списка файлов в запросе на вытягивание отображается заметка [+], помогая авторам и рецензентам выявлять новые файлы. Так как заметка была после многоточия, она часто не отображалась для более длинных имен файлов.


отображение расположений заметок

  • Раскрывающийся список обновлений pr восстановить сведения о времени

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


В раскрывающемся списке обновлений pr отсутствуют сведения о времени

  • **Улучшенный макет фильтра комментариев **

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


Улучшенный макет фильтра комментариев

  • Переход к родительским фиксациям

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


Переход к родительским фиксациям

  • Больше места для папок и файлов с длинными именами на вкладке PR-файлов

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

Изображение нового дерева файлов:


Больше места для папок и файлов

Изображение дерева файлов при наведении указателя мыши на каталог:


Отображаемое имя

  • Сохранение положения прокрутки при изменении размера области диффа на вкладке PR-файлов

При изменении размера параллельной области диффа на вкладке PR-файлов будет потеряно расположение прокрутки пользователя. Эта проблема устранена; Расположение прокрутки пользователя теперь сохраняется в области различений.

  • Поиск фиксации на мобильном устройстве

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


Поиск фиксации на мобильном устройстве

  • Улучшенное использование пространства для нового представления pr-файлов

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


Улучшено использование пространства для нового имени PR-файла

  • Расширенные изображения в представлении сводки по запросу на вытягивание

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

  • Улучшенный интерфейс ветви при создании нового запроса на вытягивание

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


Расширение возможностей филиала

Pipelines

Дополнительная платформа агента: ARM64

Мы добавили Linux/ARM64 в список поддерживаемых платформ для агента Azure Pipelines. Хотя изменения кода были минимальными, многие за кулисами работы должны были быть завершены в первую очередь, и мы рады объявить о своем выпуске!

Поддержка фильтра тегов для ресурсов конвейера

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

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

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

Например, если у вас есть запланированный набор триггеров для конвейера CD, который требуется запустить только в том случае, если ci имеет рабочий тег, теги в разделе триггеров гарантируют, что конвейер CD активируется только в том случае, если условие добавления тегов выполняется событием завершения CI.

Управление разрешенными задачами в конвейерах

Теперь можно отключить задачи Marketplace. Некоторые из вас могут разрешить расширения Marketplace, но не задачи конвейеров, которые они объединяют. Для еще большего контроля мы также позволяем независимо отключать все встроенные задачи (за исключением оформления заказа, которое является специальным действием). Если оба этих параметра включены, единственными задачами, разрешенными для выполнения в конвейере, будут те, которые были отправлены с помощью tfx. Перейдите https://dev.azure.com/<your_org>/_settings/pipelinessettings к разделу "Ограничения задач", чтобы приступить к работе.

Политика монопольной блокировки развертывания

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

На странице

Фильтры этапов для триггеров ресурсов конвейера

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

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Когда этапы, указанные в фильтре триггеров, успешно завершены в конвейере CI, новый запуск автоматически активируется для конвейера CD.

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

Сегодня у нас есть различные ресурсы (например, конвейеры, контейнеры, сборка и пакеты), с помощью которых можно использовать артефакты и включить автоматические триггеры. Однако до сих пор невозможно автоматизировать процесс развертывания на основе других внешних событий или служб. В этом выпуске мы представляем поддержку триггеров веб-перехватчика в конвейерах YAML, чтобы обеспечить интеграцию автоматизации конвейеров с любой внешней службой. Вы можете подписаться на любые внешние события с помощью веб-перехватчиков (Github, Github Enterprise, Nexus, Aritfactory и т. д.) и активировать конвейеры.

Ниже приведены действия по настройке триггеров веб-перехватчика.

  1. Настройте веб-перехватчик во внешней службе. При создании веб-перехватчика необходимо указать следующие сведения:

    • URL-адрес запроса : "https://dev.azure.com/<Коллекция> ADO/_apis/public/distributedtask/webhooks/<Имя >веб-перехватчика?api-version=6.0-preview"
    • Секрет — это необязательно. Если необходимо защитить полезные данные JSON, укажите значение secret
  2. Создайте подключение службы "Входящий веб-перехватчик". Это новый тип подключения службы, который позволит определить три важных элемента информации:

    • Имя веб-перехватчика: имя веб-перехватчика должно соответствовать веб-перехватчику, созданному во внешней службе.
    • Заголовок HTTP — имя заголовка HTTP в запросе, который содержит хэш-значение полезных данных для проверки запроса. Например, в случае GitHub заголовок запроса будет "X-Hub-Signature"
    • Секрет — секрет используется для анализа хэша полезных данных, используемого для проверки входящего запроса (это необязательно). Если вы использовали секрет при создании веб-перехватчика, необходимо указать тот же секретный ключ.

    На странице

  3. В конвейерах YAML появился новый тип webhooks ресурса. Чтобы подписыться на событие веб-перехватчика, необходимо определить ресурс веб-перехватчика в конвейере и указать ему подключение к службе входящих веб-перехватчиков. Вы также можете определить дополнительные фильтры для ресурса веб-перехватчика на основе полезных данных JSON для дальнейшей настройки триггеров для каждого конвейера, а также использовать полезные данные в виде переменных в заданиях.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
  1. При получении события веб-перехватчика подключением службы входящих веб-перехватчиков новое выполнение будет активировано для всех конвейеров, подписанных на событие веб-перехватчика.

Проблемы с триггером ресурсов YAML поддерживают и отслеживаемость

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

Триггеры ресурсов могут не выполняться по двум причинам.

  1. Если источник предоставленного подключения службы недопустим или в триггере есть синтаксические ошибки, триггер не будет настроен вообще. Они отображаются как ошибки.

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

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

Триггеры с несколькими репозиториями

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

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

В этом обновлении триггеры с несколькими репозиториями будут работать только для репозиториев Git в Azure Repos. Они не работают для ресурсов репозитория GitHub или BitBucket.

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

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

Конвейер в этом примере будет активирован, если есть какие-либо обновления:

  • main ветвь в репозитории self , содержав файл YAML
  • main или release ветви в tools репозитории

Дополнительные сведения см. в разделе "Несколько репозиториев" в конвейере.

Улучшены отправки журналов агента

Когда агент перестает взаимодействовать с сервером Azure Pipelines, задание, выполняемое им, перестает работать. Если вы смотрели на журналы консоли потоковой передачи, возможно, вы получили некоторые подсказки о том, что агент был прав, прежде чем он перестал отвечать. Но если вы не были, или если вы обновили страницу, эти журналы консоли исчезли. В этом выпуске, если агент перестает отвечать перед отправкой полных журналов, мы будем хранить журналы консоли в качестве следующего лучшего. Журналы консоли ограничены 1000 символами на строку и иногда могут быть неполными, но они гораздо более полезны, чем отображение ничего! Изучение этих журналов может помочь вам устранить неполадки с собственными конвейерами, и это, безусловно, поможет нашим инженерам службы поддержки, когда они помогают в устранении неполадок.

При необходимости подключите тома контейнеров только для чтения

При запуске задания контейнера в Azure Pipelines несколько томов, содержащих рабочую область, задачи и другие материалы, сопоставляются как тома. По умолчанию эти тома получают доступ на чтение и запись. Для повышения безопасности можно подключить тома только для чтения, изменив спецификацию контейнера в YAML. Для каждого ключа в разделе mountReadOnly можно задать значение true только для чтения (значение по умолчанию — false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

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

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

Ниже приведен пример конвейера, использующий новую возможность:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Кроме того, мы добавим список контейнеров в переменную Agent.ContainerMappingконвейера. Это можно использовать, если вы хотите проверить список контейнеров в скрипте, например. Он содержит строковое сопоставление объекта JSON с именем ресурса ("builder" из приведенного выше примера) с идентификатором контейнера, которым управляет агент.

Распакуть пакеты задач для каждого шага

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

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

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

Каждое задание, которое выполняется в выпусках, получает маркер доступа. Маркер доступа используется задачами и скриптами для обратного вызова в Azure DevOps. Например, мы используем маркер доступа для получения исходного кода, скачивания артефактов, отправки журналов, результатов тестирования или выполнения вызовов REST в Azure DevOps. Для каждого задания создается новый маркер доступа, срок действия которого истекает после завершения задания.

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

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

Улучшения API предварительной версии YAML

Теперь вы можете предварительно просмотреть полный YAML конвейера без его запуска. Кроме того, мы создали выделенный URL-адрес для возможности предварительной версии. Теперь можно выполнить post, чтобы https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview получить завершенный текст YAML. Этот новый API принимает те же параметры, что и очередь выполнения, но больше не требует разрешения "Сборки очередей".

Выполните это задание следующим образом.

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

Выражения шаблонов, разрешенные в блоке YAML resources

Ранее выражения времени компиляции (${{ }}) не были разрешены в resources разделе YAML-файла Azure Pipelines. В этом выпуске мы отменили это ограничение для контейнеров. Это позволяет использовать содержимое параметров среды выполнения в ресурсах, например выбрать контейнер во время очереди. Мы планируем расширить эту поддержку другим ресурсам с течением времени.

Контроль над автоматическими обновлениями задач из Marketplace

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

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

Пример

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Поддержка node 10 в агенте и задачах

Так как узел 6 больше не поддерживается, мы переносим задачи для работы с узлом 10. Для этого обновления мы перенесли почти 50 % задач в 10.0. Теперь агент может выполнять задачи Node 6 и Node 10. В будущем обновлении мы полностью удалим узел 6 из агента. Чтобы подготовиться к удалению узла 6 из агента, мы просим обновить внутренние расширения и пользовательские задачи, чтобы также использовать Узел 10 в ближайшее время. Чтобы использовать узел 10 для задачи, в task.jsonразделе ,в разделе executionобновления до NodeNode10.

Улучшение преобразования YAML в классическом конструкторе сборок

В этом выпуске мы представляем новую функцию экспорта в YAML для конвейеров сборки конструктора. Сохраните определение конвейера, а затем в меню найдите "Экспорт в ... YAML".

Новая функция экспорта заменяет функцию "View as YAML", которая ранее была найдена в классическом конструкторе сборок. Эта функция была неполной, так как она могла проверять только то, что веб-интерфейс знал о сборке, что иногда приводило к неправильному созданию YAML. Новая функция экспорта учитывает способ обработки конвейера и создает YAML с полной точностью к конвейеру конструктора.

Преобразование новой веб-платформы — параметры репозитория

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

Преобразование новой веб-платформы.

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

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

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

Выберите ветвь, чтобы просмотреть политики.

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

Показывает, откуда наследуется политика.

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

Фильтры поиска для каждого раздела.

Интеграция управления изменениями ServiceNow с конвейерами YAML

Приложение Azure Pipelines для ServiceNow помогает интегрировать Azure Pipelines и ServiceNow Change Management. В этом обновлении мы рассмотрим процесс управления изменениями в Azure Pipelines, управляемый в ServiceNow дальше к конвейерам YAML.

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


Интеграция serviceNow Change Management

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

Artifacts

Возможность создавать веб-каналы с областью действия организации из пользовательского интерфейса

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

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

Создайте веб-каналы с областью сбора, выбрав артефакты, а затем создайте веб-канал и выберите тип веб-канала в области.

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

Rest API обновления версии пакета теперь доступен для пакетов Maven

Теперь для обновления версий пакетов Maven можно использовать REST API Azure Artifacts "Update Package Version" (Обновление версии пакета). Ранее можно использовать REST API для обновления версий пакетов для NuGet, Maven, npm и универсальных пакетов, но не для пакетов Maven.

Чтобы обновить пакеты Maven, используйте следующую команду HTTP PATCH.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Можно задать следующее:

Параметры URI

имя; Где Обязательно Тип Описание
artifactId path true строка Идентификатор артефакта пакета
feed path true строка Имя или идентификатор веб-канала
groupId path true строка Идентификатор группы пакета
коллекция path true строка Имя коллекции Azure DevOps
version path true строка Версия пакета
проект path строка Идентификатор проекта или имя проекта
api-version query true строка Используемая версия API. Для использования этой версии API необходимо задать значение 5.1-preview.1.

Текст запроса

имя; Тип Описание
узел "Представления" JsonPatchOperation Представление, в которое будет добавлена версия пакета

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

Отзывы

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


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