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


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


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

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

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

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


Дата выпуска 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.

Azure DevOps Server 2020,1 RC1 Дата выпуска: 23 марта 2021 г.

Сводка новых возможностей Azure DevOps Server 2020,1 RC1

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

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


Boards

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

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

img

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

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

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

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

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

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

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

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

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

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

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

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

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

backlogs

Azure Boards предел репозитория приложений GitHub

Предельное значение репозитория для Azure Boards приложения в GitHub Marketplace увеличено с 100 до 250.

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

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

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

work-item-state

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

link work items

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

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

edit description

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

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

Customize state

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

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

parent field task board

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

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

"Установить значение, назначенное для создания, когда состояние изменится на" разрешено "

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

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

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

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

Repos

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

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

 default-branch-name

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

Настройка уровня Организации для ветви по умолчанию

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

branch setting for org level

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

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

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

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

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

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


show the optional checks


  • Нажатие клавиш CTRL для выбора пунктов меню

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

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

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


show locations of annotations

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

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


PR updates dropdown missing timing information

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

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


Improved comment filter layout

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

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


Navigation to parent commits

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

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

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


More space for folders and files

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


Name display

  • Сохранять позицию прокрутки при изменении размера панели различий на вкладке "файлы PR"

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

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

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


Search for a commit on a mobile device

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

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


Improved usage of space new PR filename

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

Изображения, измененные в запросе на вытягивание, не отображались в представлении "Сводка по запросам на вытягивание", но отображаются правильно в представлении PR Files. Эта проблема решена.

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

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


branch experience enhancement

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

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

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

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

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

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

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

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

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

Добавлена поддержка "этапов" в качестве фильтра для ресурсов конвейера в YAML. С помощью этого фильтра вам не нужно ждать завершения всего конвейера CI, чтобы активировать конвейер компакт-диска. Теперь вы можете активировать конвейер компакт-дисков после завершения определенного этапа в конвейере 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, для конвейера компакт-диска автоматически запускается новый запуск.

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

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

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

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

    • URL-адрес запроса — " https://dev.azure.com/ /_apis/публик/дистрибутедтаск/вебхукс/<> имя веб-перехватчика ? API — версия = 6.0-Preview"
    • Secret — это необязательно. Если необходимо защитить полезные данные JSON, укажите значение секрета
  2. Создание нового подключения к службе "входящий веб-перехватчик". Это вновь появившийся тип подключения службы, позволяющий определить три важных элемента информации:

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

    На странице &quot;изменение подключения службы&quot; настройте триггеры веб-перехватчика.

  3. webhooksВ конвейерах YAML появился новый тип ресурса с именем. Для подписки на событие веб-перехватчика необходимо определить ресурс веб-перехватчика в конвейере и указать для него подключение к входящему службе веб-перехватчика. Можно также определить дополнительные фильтры для ресурса веб-перехватчика на основе полезных данных 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. Например, мы используем маркер доступа для получения исходного кода, скачивания артефактов, отправки журналов, результатов тестов или для вызова функций RESTFUL в Azure DevOps. Для каждого задания создается новый маркер доступа, срок его действия истекает после завершения задания.

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

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

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

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

Запустить это задание далее

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

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

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

Управление обновлениями автоматизированных задач из Marketplace

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

Мы не рекомендуем регулярно выполнять это действие и использовать его только в качестве временного решения, если вы обнаружите, что более новая задача разбивает конвейеры. Кроме того, при этом не будет устанавливаться старая версия задачи из 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. Теперь агент может выполнять задачи node 6 и 10. В следующем обновлении мы полностью удалим узел 6 из агента. Чтобы подготовиться к удалению узла 6 из агента, мы запрашивает обновление внутренних расширений и пользовательских задач, чтобы в ближайшее время использовать узел 10. Чтобы использовать узел 10 для задачи, в среде в task.json разделе execution обновите Node до Node10 .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


ServiceNow Change Management Integration

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

Artifacts

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

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

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

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

Хотя мы рекомендуем использовать веб-каналы уровня проекта в соответствии с остальными предложениями Azure DevOps, вы можете снова создавать, администрировать и использовать веб-каналы уровня коллекции с помощью пользовательского интерфейса и различных интерфейсов API RESTFUL. Дополнительные сведения см. в документации по веб-каналам.

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

Теперь можно использовать " версию пакета обновления Azure Artifacts " REST API для обновления версий пакетов Maven. Ранее можно было использовать REST API для обновления версий пакетов для NuGet, Maven, NPM и Universal Packages, но не 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 строка Имя коллекции DevOps Azure
version path TRUE строка Версия пакета
project path строка ИДЕНТИФИКАТОР проекта или имя проекта
api-version query TRUE строка Версия API для использования. Для использования этой версии API необходимо задать значение '5,1-Preview. 1'

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

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

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

Отзывы

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


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