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


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


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

Дополнительные сведения см. в разделе Azure DevOps Server требования. Посетите страницу VisualStudio.com/downloads , чтобы скачать продукты Team Foundation Server.

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


Дата выпуска обновления 8 для Azure DevOps Server 2019 1,1:13 апреля, 2021

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

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

Общая установка исправлений

При наличии Azure DevOps Server 2019 с обновлением 1,1 необходимо установить Azure DevOps Server 2019 обновление 1,1 Patch 8.

Проверка установки

  • Вариант 1. Run devops2019.1.1patch8.exe CheckInstall , devops2019.1.1patch8.exe — это файл, скачанный по ссылке выше. Выходные данные команды либо говорят, что исправление установлено, либо не установлено.

  • Вариант 2. Проверьте версию следующего файла: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll . Azure DevOps Server 2019 устанавливается в c:\Program Files\Azure DevOps Server 2019 по умолчанию. После установки Azure DevOps Server 2019.1.1 Patch 8 версия будет 17.153.31129.2.

Установка задачи AzureResourceGroupDeploymentV2

Примечание

Все нижеперечисленные шаги нужно выполнять на компьютере с Windows.

Установка

  1. Извлеките AzureResourceGroupDeploymentV2.zip пакет в новую папку на компьютере. Например: D:\tasks\AzureResourceGroupDeploymentV2.

  2. Скачайте и установите Node.js 14.15.1 и NPM (входит в состав Node.js скачивания), как подходит для компьютера.

  3. Откройте командную строку в режиме администратора и выполните следующую команду, чтобы установить tfx-cli.

npm install -g tfx-cli
  1. Создайте личный маркер доступа с привилегиями Полного доступа и скопируйте его. Этот личный маркер доступа будет использоваться при выполнении команды tfx login.

  2. В командной строке выполните следующую команду. При появлении запроса введите URL-адрес службы и личный маркер доступа.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. Выполните следующую команду, чтобы отправить задачу на сервер. Используйте путь к извлеченному ZIP-файлу из шага 1.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Дата выпуска обновления 7 для Azure DevOps Server 2019 1,1:12 января 2021

Мы выпустили исправление для Azure DevOps Server 2019 с обновлением 1,1, которое устраняет следующие проблемы. Дополнительные сведения см. в записи блога.

  • Сведения о тестовом запуске не отображают сведения о шаге теста для тестовых данных, перенесенных с помощью миграции OpsHub
  • Исключение в инициализаторе для "Microsoft. TeamFoundation. TestManagement. Server. Ткмлогжер"
  • Несохраняемые сборки немедленно удаляются после миграции на Azure DevOps Server 2020
  • Исправить исключение поставщика данных

Дата выпуска пакета обновления 6 для Azure DevOps Server 2019 1,1:8 декабря 2020

Мы выпустили исправление для Azure DevOps Server 2019 с обновлением 1,1, которое устраняет следующие проблемы. Дополнительные сведения см. в записи блога.

  • CVE-2020-1325: уязвимость подмены Azure DevOps Server
  • CVE-2020-17135: уязвимость подмены Azure DevOps Server
  • CVE-2020-17145 : уязвимость для спуфинга в Azure DevOps Server и службах Team Foundation Service
  • Устранение проблемы с TFVC не обрабатывая все результаты

Важно!

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

Общая установка исправлений

При наличии Azure DevOps Server 2019 с обновлением 1,1 необходимо установить Azure DevOps Server 2019 обновление 1,1 Patch 6.

Проверка установки

  • Вариант 1. Run devops2019.1.1patch6.exe CheckInstall , devops2019.1.1patch6.exe — это файл, скачанный по ссылке выше. Выходные данные команды либо говорят, что исправление установлено, либо не установлено.

  • Вариант 2. Проверьте версию следующего файла: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll . Azure DevOps Server 2019 устанавливается в c:\Program Files\Azure DevOps Server 2019 по умолчанию. После установки Azure DevOps Server 2019.1.1 Patch 6 версия будет 17.153.30723.5.

Установка задачи AzurePowerShellV4

Примечание

Все нижеперечисленные шаги нужно выполнять на компьютере с Windows.

Предварительные требования

  1. Установите Azure PowerShell AZ Module Azure PowerShell на компьютере частного агента.

  2. Создайте конвейер с задачей AzurePowerShellV4 . В задаче будет отображаться только один сбой в стандартной ошибке .

Установка

  1. Извлеките AzurePowerShellV4.zip пакет в папку с именем AzurePowerShellV4.

  2. Скачайте и установите Node.js 14.15.1 и npm (входит в состав загрузки Node.js), совместимые с вашим компьютером.

  3. Откройте командную строку в режиме администратора и выполните следующую команду, чтобы установить tfx-cli.

npm install -g tfx-cli
  1. Создайте личный маркер доступа с привилегиями Полного доступа и скопируйте его. Этот личный маркер доступа будет использоваться при выполнении команды tfx login.

  2. В командной строке выполните следующую команду. При появлении запроса введите URL-адрес службы и личный маркер доступа.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. Выполните следующую команду, чтобы отправить задачу на сервер. Путь к извлеченному пакету будет D:\tasks\AzurePowerShellv4.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Дата выпуска обновления 5 для Azure DevOps Server 2019 1,1:8 сентября 2020 г.

Мы выпустили исправление для Azure DevOps Server 2019 с обновлением 1,1, которое устраняет следующие проблемы. Дополнительные сведения см. в записи блога.

  • DTS 1713492 — непредвиденное поведение при добавлении групп AD в разрешения безопасности.

Дата выпуска обновления 4 для Azure DevOps Server 2019 1,1:14 июля 2020

Мы выпустили исправление для Azure DevOps Server 2019 с обновлением 1,1, которое устраняет следующие проблемы. Дополнительные сведения см. в записи блога.

  • CVE-2020-1326: уязвимость межсайтовых сценариев
  • Конвейер сборки показывает неправильное подключение для неавторизованных пользователей при выборе другого источника Git.
  • Исправить ошибку при изменении наследования на on или Off в определении сборки XAML.

Дата выпуска обновления 3 для Azure DevOps Server 2019 1,1:9 июня, 2020

Мы выпустили исправление для Azure DevOps Server 2019 с обновлением 1,1, которое устраняет следующие проблемы. Дополнительные сведения см. в записи блога.

  • CVE-2020-1327: Убедитесь, что Azure DevOps Server очищает входные данные пользователя.

Дата выпуска обновления 2 для Azure DevOps Server 2019 1,1:14 апреля, 2020

Мы выпустили исправление для Azure DevOps Server 2019 с обновлением 1,1, которое устраняет следующие проблемы. Дополнительные сведения см. в записи блога.

  • Фиксации SVN не активируют конвейер

  • Добавление поддержки SHA2 в SSH в Azure DevOps

Дата выпуска обновления 1 для Azure DevOps Server 2019 1,1:10 марта 2020

Мы выпустили исправление безопасности для обновления Azure DevOps Server 2019 1,1, которое устраняет следующие ошибки. Дополнительные сведения см. в записи блога.

  • CVE-2020-0700 : уязвимость для межсайтовых сценариев

  • CVE-2020-0758 : уязвимость к повышению привилегий

  • CVE 2020-0815: уязвимость повышения привилегий


Azure DevOps Server 2019 обновление 1,1 RTW Дата выпуска: 10 декабря 2019 г.

Azure DevOps Server обновление 2019 1,1 является сведением к исправлению ошибок и обновлений безопасности. Он включает все исправления в ранее выпущенных исправлениях Azure DevOps Server 2019 с обновлением 1. Можно напрямую установить обновление Azure DevOps Server 2019 1,1 или обновление с Azure DevOps Server 2019 или Team Foundation Server 2012 или более поздней версии.

Примечание

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

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

Azure Boards

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

Azure Pipelines

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

  • Изменение полей в Test Plans выполняется очень долго.
  • В тестовом случае при открытии с доски (в отличие от Test Plans) сведения об общем шаге не открываются.

Общие

Администрирование

  • Высокий уровень использования памяти.
  • Серверам с конфигурацией подсистемы балансировки нагрузки пришлось явно добавить их общедоступный источник в запись реестра AllowedOrigins.
  • Клиенты, которые устанавливают на SQL Azure, не видят диалоговое окно полный пробный период.
  • При установке расширений возникает ошибка "сообщение об ошибке" отсутствует публикация (MS. VSS-Dashboards-Web. Мини-пакета SDK-Version-2) ".
  • При настройке эластичного поиска возникает ошибка: "пользователь не авторизован".
  • Индексирование и сбои запросов в эластичном поиске при обновлении с TFS 2018 с обновлением 2 или более поздней версии.
  • Шаг "Создание хранилища" завершается ошибкой при настройке Azure DevOps Server.

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

  • Поддержка SQL Server 2019.

Дата выпуска обновления 1 для Azure DevOps Server 2019 с обновлением 1 — 10 сентября 2019 г.

Выпущено исправление безопасности для Azure DevOps Server 2019 с обновлением 1, устраняющее следующую ошибку. Дополнительные сведения см. в записи блога.

  • CVE-2019-1306 : уязвимость удаленного выполнения кода в Wiki

Дата выпуска обновления 1 для Azure DevOps Server 2019:20 августа 2019

Примечание

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


Дата выпуска RC2:23 июля 2019 г.

RC2 включает несколько исправлений ошибок, начиная с версии RC1, и является окончательным планом предварительной версии.


Дата выпуска RC1:2 июля 2019 г.

Общие сведения о новых возможностях Azure DevOps Server 2019 с обновлением 1

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

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


Общие

Темная тема

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

Темная тема

Boards

Новый базовый процесс

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

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

Базовый процесс

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

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

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

порядок состояний

Включение функции больше не доступно

Клиентам потребуется вручную обновить XML для каждого проекта, чтобы включить новые функции после обновления коллекции.

Включение функций

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

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

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

Вложения рабочих элементов

Совместное использование доски команды с помощью значка

ФАЙЛ сведений о репозитории часто является доменом, к которому ваша группа проекта может получить информацию о том, как участвовать в решении и использовать его. Теперь, как и в Azure Pipelines, можно добавить в файл README значок для доски команды в Azure Boards. Можно настроить эмблему, чтобы отображались только выполняющиеся столбцы или все столбцы, а также сделать видимым открытое окно, если проект является открытым исходным кодом.

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

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

Снимок экрана с эмблемой в файле README на GitHub.

Запрос работы относительно начала дня, недели, месяца или года

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

  • @StartOfYear
  • @StartOfMonth
  • @StartOfWeek
  • @StartOfDay

Каждый из этих макросов также принимает новую строку модификатора, позволяющую сместить данные по разным единицам дат. Например, можно написать запрос, чтобы найти все рабочие элементы, выполненные в первом квартале этого года, запросив дату изменения состояния >= @StartOfYear и дату изменения состояния <= @StartOfYear ("+ 3m"). Дополнительные сведения см. в документации по макросам запросов .

Снимок экрана с запросом работы относительно начала дня, недели, месяца или года.

Изменение и удаление комментариев в обсуждениях

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

Снимок экрана, показывающий комментарии к обсуждению.

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

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

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

Экспорт результатов запроса в CSV-файл

Теперь вы можете экспортировать результаты запроса непосредственно в файл форматирования CSV из Интернета.

Короткое видео, в котором показано, как экспортировать результаты запроса.

Теперь, когда вы упоминаете рабочий элемент в комментариях проблемы, запроса на вытягивание или фиксации в GitHub с помощью AB#{work item ID} синтаксиса, эти упоминания станут гиперссылками, которые можно щелкнуть, чтобы перейти непосредственно к упомянутому рабочему элементу.

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

Снимок экрана, показывающий запрос на вытягивание на GitHub.

<a name="accept-and-execute-on-issues-in-github-while-planning-in-azure-boards">Примите и исполните проблемы в GitHub во время планирования Azure Boards

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

![Снимок экрана, показывающий, что вы можете связать рабочие элементы в Azure Boards с соответствующими проблемами в GitHub.](media/151_04.png "Связывание рабочих элементов в Azure Boards со связанными проблемами в GitHub")

Тот же синтаксис, который ваша команда использует для фиксаций и запросов на вытягивание, по-прежнему применяется, и, конечно, вы можете вручную выполнить компоновку в Azure Boards с помощью URL-адреса проблемы. Дополнительные сведения см. в документации по & Azure Boards GitHub .

Снимок экрана, показывающий, как связать вручную в Azure Boards с URL-адресом проблемы GitHub.

Быстрое Просмотр связанных действий GitHub с доски Канбан

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

Снимок экрана, показывающий, как просмотреть связанное действие GitHub с доски Канбан.

Repos

Черновые запросы на вытягивание

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

Черновики запросов на вытягивание можно создать, выбрав создать как черновик в раскрывающемся списке " создать " при создании запроса на вытягивание.

Создание черновика запроса на вытягивание

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

Снимок экрана запроса на вытягивание с отображением ЧЕРНОВИКа ".

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

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

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

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

Примечание

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

Просмотр только левого или правого файла в запросе на включение внесенных изменений

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

Снимок экрана с односторонними параметрами сравнения с курсором, наведя указатель мыши на параметр "показывать измененное содержимое".

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

Теперь у вас есть дополнительные параметры при объединении изменений из запроса на вытягивание в целевую ветвь. Мы добавили поддержку двух наших наиболее востребованных функций сообщества разработчиков: быстрое слияние и частичное слияние (также называемое "Переоснованием и слиянием").

Теперь вы увидите новые параметры, доступные в диалоговом окне полный запрос на включение внесенных изменений :

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

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

Снимок экрана с разделом ограничений на объединение типов.

Примечание

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

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

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

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

Фильтровать по целевой ветви в запросах на вытягивание (вытягивание)

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

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

Снимок экрана: параметры фильтрации запроса на вытягивание Azure Pipelines.

Можно также использовать фильтрацию конечной ветви для настройки представления "запросы на вытягивание" на вкладке " Мои ".

Снимок экрана: Настройка запроса на вытягивание на вкладке "мои".

Разрешить расширениям добавлять выделение синтаксиса и Автозаполнение

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

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

Пример расширения, демонстрирующий эту функцию, можно найти здесь.

Кроме того, добавлена поддержка выделения синтаксиса языка Kusto .

Точка расширения создания репозитория

Добавлена точка расширения, позволяющая добавлять новые элементы в средство выбора репозитория. Эта точка расширения позволяет добавлять настраиваемые действия (перенаправления, всплывающие окна и т. д.) в меню выбора репозитория, что позволяет использовать такие потоки, как альтернативные сценарии создания репозитория.

Снимок экрана, на котором показано расширение создания репозитория.

Улучшенная поддержка кодирования

Ранее редактирование и сохранение файлов в Интернете будет сохраняться только как кодировка UTF-8, и при изменении кодировки файла не выводится запрос. Теперь мы выдаем предупреждение при попытке сохранить файл, который не кодируется в кодировке UTF через веб-узел (который поддерживает только кодировку UTF). Кроме того, мы добавили поддержку кодировки UTF-16 и UTF-32 через конечную точку веб-Push. Это означает, что тип кодировки будет сохранен, поэтому вам не придется переписывать их как UTF-8.

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

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

Получение поддержки команд Get в Azure Repos

Go — это язык программирования с открытым исходным кодом, который также называется Golang. В Go можно использовать команду Get для скачивания и установки пакетов и зависимостей. Благодаря этому обновлению мы добавили поддержку go get в репозиторий Azure DevOps. С помощью go get вы сможете скачивать пакеты с их зависимостями по путям импорта. importДля указания пути импорта можно использовать ключевое слово.

Pipelines

Веб-редактор с технологией IntelliSense для конвейеров YAML

Если вы используете YAML для определения конвейеров, теперь вы можете воспользоваться новыми функциями редактора, появившимися в этом выпуске. Создается ли новый конвейер YAML или редактируется существующий конвейер YAML, вы сможете редактировать файл YAML в веб-редакторе конвейера. Используйте клавиши Ctrl + пробел для поддержки IntelliSense при редактировании файла YAML. Вы увидите выделенные синтаксические ошибки, а также получите справку по исправлению этих ошибок.

Снимок экрана, показывающий выделенные синтаксические ошибки.

<a name="task-assistant-for-editing-yaml-files">Помощник по задачам для редактирования файлов YAML

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

![Короткое видео, в котором показано, как использовать помощник по задаче для редактирования файлов YAML.](media/150_34.gif "Помощник по задачам для редактирования файлов YAML")

Активация конвейеров YAML с помощью тегов

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

Можно указать, какие теги включать и исключать. Пример:

trigger:
  tags:
    include:
    - releases/*
    exclude:
    - releases/old*

Объявить ресурсы контейнера как встроенные

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

jobs:
- job: my-container-job
  container:
    image: microsoft/dotnet:latest

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

По умолчанию конвейеры, активируемые запросами на включение внесенных изменений (вытягивание), будут отменены, если новая фиксация помещается в тот же запрос на вытягивание. Это желательно в большинстве случаев, так как обычно вы не хотите продолжать выполнение конвейера на устаревшем коде. Если вы не хотите это делать, можно добавить автоотмена: false для триггера PR.

pr:
  branches:
    include:
    - main
    - releases/*
  autoCancel: false

Выберите каталог извлеченного кода в конвейерах YAML

Ранее мы извлекли репозиториев в s каталог в папке $ (Agent. BuildDirectory). Теперь можно выбрать каталог, в котором будет извлечен репозиторий Git для использования с конвейерами YAML.

Используйте path ключевое слово ON checkout , и вы будете контролировать структуру папок. Ниже приведен пример кода YAML, который можно использовать для указания каталога.

steps:
- checkout: self
  path: my-great-repo

В этом примере код будет извлечен в my-great-repo каталог в рабочей области агента. Если путь не указан, репозиторий будет по-прежнему извлечен в каталог с именем s .

Новые задачи службы приложений Azure, оптимизированные для YAML

Теперь мы поддерживаем четыре новых задачи, которые предоставляют простой, но мощный способ развертывания служб приложений Azure с учетом современных разработчиков. Эти задачи имеют оптимизированный синтаксис YAML, облегчающий создание развертываний в Azure AppServices, включая веб приложения, Функтионаппс, веб Apps для контейнеров и FunctionApp для контейнеров на платформах Windows и Linux.

Мы также поддерживаем новую служебную задачу для преобразования файлов и подстановку переменных для форматов XML и JSON.

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

До этого момента участники проекта не смогли создать конвейеры, если только они явно не задают разрешение CREATE Build Definition. Для новых проектов члены команды могут создавать и обновлять конвейеры. Это изменение снизит трение для новых клиентов, которые приводят к Azure Pipelines. Вы всегда можете обновить разрешения по умолчанию для группы "участники" и ограничить их доступ.

Управление выпусками GitHub с помощью конвейеров

Выпуски GitHub — это отличный способ упаковки и предоставления пользователям программного обеспечения. Мы рады сообщить о том, что теперь вы можете автоматизировать его с помощью задачи выпуска GitHub в Azure Pipelines. С помощью задачи можно создать новый выпуск, изменить существующие черновые или опубликованные выпуски или удалить старые. Она поддерживает такие функции, как отправка нескольких ресурсов, пометка выпуска в качестве предварительной версии, сохранение выпуска как черновика и многое другое. Эта задача также позволяет создавать заметки о выпуске. Он также может автоматически вычислять изменения (фиксации и связанные с ними проблемы), сделанные в этом выпуске, и добавлять их в заметки о выпуске в удобном для пользователя формате.

Вот простой YAML для задачи:

task: GithubRelease@0 
displayName: 'Create GitHub Release'      
inputs:
  githubConnection: zenithworks
  repositoryName: zenithworks/pipelines-java
  assets: $(build.artifactstagingdirectory)/*.jar

Снимок экрана: диалоговое окно "выпуск GitHub (Предварительная версия)".

Пример выпуска GitHub, созданный с помощью этой задачи:

Снимок экрана с примером выпуска GitHub, созданного с помощью этой задачи.

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

Снимок экрана файла Build Solution dirs. proj с выделенной строкой журнала и ссылкой копирования на этот параметр выбора.

Усовершенствования авторизации ресурсов

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

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

Снимок экрана, показывающий сводку конвейера с ошибкой авторизации.

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

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

Существуют две точки вклада:

  1. Кнопка настраиваемого действия на панели инструментов

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

    Снимок экрана с параметром "настраиваемое действие".

  2. Вкладка "настраиваемые сведения" в области сведений

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

Запустить агент однократно

Если вы используете инфраструктуру, например службу "экземпляры контейнеров Azure" для запуска частных агентов эластичных БД, часто требуется, чтобы каждый агент принимал только одно задание, прежде чем отказаться от него. До настоящего момента это было не так просто, так как пришлось прерывать работу агента (возможно, привести к ошибке) или принять риск того, что агент может получить другое задание, прежде чем можно будет завершить его работу. В этом обновлении мы добавили к конфигурации агента флаг --Once . Если настроить агент таким образом, он будет принимать только одно задание, а затем завершать его работу.

Обновление пользовательского интерфейса пула агентов

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

Снимок экрана, показывающий обновление пользовательского интерфейса пула агентов (UX)

Развертывание в невыполненных целевых объектах в группе развертывания

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

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

Автоматическое повторное развертывание при сбое

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

Снимок экрана: диалоговое окно "условия после развертывания" с именем триггера автоматического повторного развертывания.

Обработчик службы Grafana Annotations

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

Снимок экрана панели мониторинга Grafana, отображающей изменения в метриках.

Задачи предупреждений Azure Monitor запросов

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

Снимок экрана, показывающий предварительный просмотр запросов Azure Monitor предупреждений.

Встроенный ввод спецификации файла в задаче "развертывание в Kubernetes"

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

Снимок экрана, показывающий встроенную функцию настройки.

Задача установщика DOCKER CLI

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

Снимок экрана, показывающий установленный DockerCLI.

Восстановление удаленных конвейеров выпуска

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

Снимок экрана, показывающий вариант восстановления для конвейеров.

Уведомления при сбое запроса на создание выпуска

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

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

Снимок экрана: Мастер создания подписки с выделенной категорией выпусков и вызываемый параметр "запрос на создание выпуска".

Планирование выпусков при изменении источника или конвейера

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

Снимок экрана: раздел триггера запланированного выпуска с единственными выпусками расписания, если параметр источника или конвейера был изменен на "out".

Точка вклада для переменных в диалоговом окне создания выпуска

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

Снимок экрана: диалоговое окно "Создание нового выпуска".

Публикация в очередях сеанса служебной шины Azure

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

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

Новый вариант подписки Azure в подключении к службе Kubernetes

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

В этом обновлении мы добавили параметр проверки подлинности в форму подключения к службе Kubernetes. Теперь можно выбрать подписку Azure для проверки подлинности подключения. Это упрощает развертывание в определенные пространства имен, настроив подключения Kubernetes с помощью подписки Azure и имени кластера.

Для кластера, поддерживающего управление доступом на основе ролей (RBAC), объекты учетная запись службы и ролебиндинг создаются в выбранном пространстве имен. Объект Ролебиндинг ограничивает операции созданной учетной записи службы только выбранным пространством имен. Для кластера, отключенного с RBAC, созданная учетная запись службы имеет разрешения на уровне кластера для всех пространств имен.

Снимок экрана: диалоговое окно "Добавление подключения к службе Kubernetes" с вызываемым параметром подписки Azure.

Реестр контейнеров Azure в подключении к службе реестра DOCKER

Теперь вы можете создать подключение к службе реестра DOCKER на странице параметров проекта. Чтобы создать подключение, выберите реестр контейнеров Azure в одной из подписок, связанных с удостоверением Azure Active Directory (AAD). Все задачи, которые требуют подключения к службе для реестров контейнеров, такие как Docker@2 и, KubernetesManifest@0 поддерживают один способ указания соединения.

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

Поиск по имени папки в определениях выпуска

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

Снимок экрана, показывающий определения выпуска, хранящиеся в папках.

Задача установщика средства сумку в конвейере сборки и выпуска

Сумку — это программа командной строки, которая позволяет устанавливать облачные пакеты приложений для машинного кода (КНАБ) и управлять ими. С помощью КНАБС вы можете объединять, устанавливать и администрировать приложения-контейнеры и их службы.

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

Снимок экрана установщика инструмента сумку.

Задачи с манифестом Kubernetes

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

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

  • Состояние развертывания манифеста — проверяется на наличие объектов Kubernetes, развернутых для включения проверок стабильности при вычислении состояния задачи как успешного или неуспешного выполнения.

  • Заметки о трассировке. заметки добавляются в развернутые объекты Kubernetes для получения сведений о отслеживаемой Организации, проекте, конвейере и выполнении.

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

  • Стратегия развертывания. Выбор стратегии ранний с действием развертывания приводит к созданию требуемого процента рабочих нагрузок с суффиксом -Baseline и -ранний , чтобы их можно было сравнить во время выполнения ManualIntervention задачи перед использованием действия "повысить/отклонить" задачи, чтобы завершить ее версию.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

Обновление задачи DOCKER

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

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Установщик средств Kubectl

Добавлена новая задача, позволяющая установить определенную версию двоичного файла Kubectl на агентах. Строки с последними и semver версиями, такие как "v 1.14.0", принимаются как допустимые значения для ввода спецификации версии Kubectl.

Снимок экрана, показывающий установщик инструмента Kubectl.

Усовершенствования интеграции ServiceNow

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

Снимок экрана, показывающий функцию управления изменениями ServiceNow.

Поддержка Red Hat Enterprise Linux 6

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

Поддержка модуля Azure PowerShell AZ

Azure PowerShell предоставляет набор командлетов, которые можно использовать для управления ресурсами Azure из командной строки. Последний Декабрь: модуль Azure PowerShell AZ стал доступным и теперь является предполагаемым модулем для управления ресурсами Azure.

Ранее мы не поддерживали поддержку модуля Azure PowerShell az в наших размещенных агентах. С помощью новой Azure PowerShellной задачи версии 4. * в конвейерах сборки и выпуска мы добавили поддержку нового модуля AZ для всех платформ. Задача Azure PowerShell версии 3. * продолжит поддерживать модуль AzureRM. Однако, чтобы обеспечить актуальность новейших служб и функций Azure, рекомендуется перейти на Azure PowerShellную задачу версии 4. * как можно скорее.

Модуль AZ имеет режим совместимости, позволяющий использовать существующие сценарии при их обновлении для использования нового синтаксиса. Чтобы включить совместимость для модуля AZ, используйте Enable-AzureRmAlias команду. Псевдонимы позволяют использовать старые имена командлетов с помощью команды AZ Module. Дополнительные сведения о переносе из модуля Azure RM в модуль Azure PowerShell AZ можно получить здесь.

Примечание

При использовании частных агентов необходимо установить модуль AZ на компьютере агента.

Дополнительные сведения о модуле Azure PowerShell AZ см. в документации здесь.

Поддержка проверки подлинности Azure Active Directory (AD) для задачи SQL Azure

Задача SQL Azure была улучшена для поддержки подключения к базе данных с помощью Azure AD (интегрированный & пароль) и строки подключения в дополнение к существующей поддержке проверки подлинности SQL Server.

Снимок экрана: диалоговое окно развертывания базы данных SQL Azure с выделенным раскрывающимся списком "тип проверки подлинности".

Публикация артефактов сборки с длинными путями файлов

До настоящего момента существовало ограничение на передачу артефактов сборки с путями длиннее 233 символов. Это может помешать отправке результатов покрытия кода из сборок Linux и macOS с путями к файлам, превышающими ограничение. Ограничение было изменено для поддержки длинных путей.

Пропустить непрерывную интеграцию (CI) для фиксации

Теперь можно указать Azure Pipelines игнорировать фиксацию и пропустить выполнение конвейера, который обычно активирует фиксацию. Просто включите [skip ci] в сообщение фиксации головной фиксации, а Azure pipelines пропустит CI. Можно также использовать любой из перечисленных ниже вариантов. Это поддерживается для фиксаций Azure Repos Git и GitHub Enterprise Server.

  • [skip ci] или [ci skip]
  • skip-checks: true или skip-checks:true
  • [skip azurepipelines] или [azurepipelines skip]
  • [skip azpipelines] или [azpipelines skip]
  • [skip azp] или [azp skip]
  • ***NO_CI***

Test Plans

Мини-приложение тренда результатов теста (Advanced)

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

Снимок экрана мини-приложения "тренд результатов теста" (Advanced).

Мини-приложение "тренд результатов теста" (Advanced) помогает находить выбросы в результатах теста и отвечать на такие вопросы: тесты выполняются дольше, чем обычно? Какой тестовый файл или конвейер влияет на общую скорость передачи? Как долго выполнялись тесты?

Чтобы помочь вам ответить на эти вопросы, Мини-приложение предоставляет следующие возможности:

  • Отображает тренд скорости передачи и число результатов теста или длительность тестирования.
  • Представляет результаты тестов на основе нескольких конвейеров сборки или конвейеров выпуска
  • Использует Объединенные параметры диаграмм для показа двух метрик по одной и той же тенденции
  • Фильтрует число тестов в течение времени по результату теста
  • Фильтрует все результаты теста по ветви или тесту
  • Помещает метрики по атрибутам тестирования, таким как приоритет или Среда .
  • Группировка данных по тестовым файлам, владельцам или конвейерам

Мини-приложение обеспечивает широкие возможности настройки, позволяя использовать его в самых разных сценариях.

Совместное использование результатов тестового запуска через URL-адрес

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

К уровням общего доступа относятся:

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

При совместном использовании URL-адреса средства просмотра увидят результаты тестового запуска в полноэкранном режиме.

Artifacts

Пакеты NuGet с номерами версий SemVer 2.0.0

Ранее Azure Artifacts не поддерживали пакеты NuGet с номерами версий SemVer 2.0.0 (как правило, Номера версий, которые содержат часть метаданных сборки версии, которая обозначается параметром + ). Теперь можно сохранять пакеты из nuget.org, содержащие метаданные сборки, и отправлять собственные пакеты с помощью метаданных сборки. Согласно спецификации SemVer Spec и NuGet.org, метаданные сборки нельзя использовать для упорядочения пакетов. Поэтому нельзя публиковать 1.0.0+build1 и 1.0.0+build2 в Azure Artifacts (или NuGet.org), так как эти версии будут считаться эквивалентными и, таким образом, подчиняются ограничениям неизменности.

Сведения об проверенных пакетах

В этом обновлении мы немного упростили понимание проверенного количества пакетов: кто или кто опубликовал их и какой исходный код должен быть зафиксирован. Эти сведения автоматически заполняются для всех пакетов, опубликованных с помощью задач NuGet, NPM, Mavenи твине Authenticate (для Python) в Azure pipelines.

Статистика использования пакетов

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

Снимок экрана статистики использования пакета.

Поддержка пакетов Python

В Azure Artifacts теперь можно размещать пакеты Python: оба пакета, которые вы создаете самостоятельно, и вышестоящий пакет, сохраненный из общедоступной PyPI. Дополнительные сведения см. в записи блога о объявлениях и документах.

Теперь вы можете разместить все пакеты NuGet, NPM, Maven и Python в одном веб-канале.

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

Вышестоящее источники для Maven

Вышестоящее источники теперь доступны для веб-каналов Maven. Сюда входит основной центральный репозиторий Maven и веб-каналы Azure Artifacts. Чтобы добавить Mavenные потоки в существующий веб-канал, перейдите к параметрам веб-канала, выберите сводный источник "вышестоящее источники", а затем щелкните Добавить вышестоящий источник.

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

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

  • Npm@1 (' NPM ' в конструкторе)
  • NuGetCommand@2 (' NuGet ' в конструкторе): только команды RESTORE и Push
  • DotNetCoreCLI@2 (' .NET Core ' в конструкторе): только команды RESTORE и push-уведомлений NuGet
  • NpmAuthenticate@0, PipAuthenticate@0 и TwineAuthenticate@0 (' [тип] Проверка подлинности ' в конструкторе). Эти задачи поддерживают прокси-серверы во время приобретения токенов проверки подлинности, но все равно необходимо настроить все последующие задачи, скрипты и средства для использования прокси. Другими словами, эти задачи не настраивают прокси для базового средства (NPM, PIP, твине).
  • NuGetToolInstaller@0, NodeTool@0 , DotNetCoreInstaller@0 ("[тип] установщик" в конструкторе)

Все типы пакетов артефактов, поддерживаемые в выпусках

До настоящего момента поддерживаются только пакеты NuGet в типе артефакта Azure Artifacts в выпусках конвейеров. В этом обновлении поддерживаются все типы пакетов Azure Artifacts-Maven, NPM и Python.

Представления артефактов, поддерживаемые в выпусках

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

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

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

Делегирование, которое может управлять веб-каналами

В Azure Artifacts Администраторы коллекции проектов (пкас) всегда могли администрировать все веб-каналы на сервере DevOps Azure. Благодаря этому обновлению Пкас также может предоставить эту возможность другим пользователям и группам, тем самым делегируя возможность управлять любым каналом.

Вики

Шаблоны Markdown для формул и видео

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

Снимок экрана, показывающий развернутое контекстное меню со следующими параметрами: оглавление, видео, тег YAML и формулы.

Внедрение результатов запроса Azure Boards на вики-сайте

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

Снимок экрана внедренных Azure Boards результатов запроса, отображаемых на вики-сайте.

Результаты запроса можно добавить в два этапа:

  1. Нажмите кнопку "результаты запроса" на панели инструментов "Изменить".

Снимок экрана, показывающий развернутое контекстное меню с вызываемым параметром результатов запроса.

  1. Выберите требуемый запрос и нажмите кнопку "вставить".

Теперь результаты запроса можно просмотреть в виде таблицы после сохранения страницы.

Снимок экрана: диалоговое окно "результаты запроса".

НеMarkdownый шрифт для Wiki-редактора

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

Снимок экрана вики-страницы со шрифтом с пробелом.

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

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

Отображение состояния рабочего элемента на вики-страницах

В этом обновлении мы улучшили упоминания рабочих элементов на вики-страницах, добавляя состояние рабочего элемента на страницу вместе с его ИДЕНТИФИКАТОРом и названием.

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

Для ссылок на рабочие элементы в комментариях и на досках запроса на вытягивание также отображается состояние.

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

@mention Пользователи и группы

Теперь @mention Пользователи и группы можно на вики-странице. Это делает документы, такие как страница контактов команды, документы руководств и документы с богатыми знаниями. На приведенном ниже рисунке показан пример ретроспективы спринта с задачами и ответственным лицом.

Снимок экрана, показывающий, как он выглядит при создании @mention пользователей и групп.

Кроме того, можно выбрать пользователя или группу из автоподбора, введя "@" на странице "Редактирование" вики-сайта. Указанное лицо также будет уведомлено по почте.

Снимок экрана с автопредложениями, отображаемыми при начале ввода @mention .

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

<a name="notifications-on-wiki-pages">Уведомления на вики-страницах

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

![Снимок экрана вики-страницы Azure DevOps с вызываемым параметром "Далее".](media/150_03.png "Вики-страница")

Приоритет этой функции зависит от этого запроса предложения. Дополнительные сведения см. внашей документации.

Поддержка HTML-тегов

Теперь на вики-сайте можно создать более насыщенное содержимое с помощью тегов HTML. Узнайте, что можно делать с HTML-тегами ниже.

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

    Снимок экрана, показывающий свертываемые разделы, созданные с помощью тегов Details и Summary.

    Дополнительные сведения о теге Details см. в этой документации.

    Это было назначено по приоритету на основе этого запроса предложения.

    Примечание

    Этот тег не поддерживается в обозревателях пограничных и Internet Explorer.

Улучшено создание и редактирование таблиц

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

  1. Создание таблицы из таблицы

    Вам больше не нужно запоминать синтаксис таблицы Markdown. Теперь можно легко создать таблицу Markdown, выбрав из таблицы 15 X 15. Просто выберите необходимое число столбцов и строк, чтобы вставить таблицу одним щелчком мыши.

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

    Приоритет этой функции зависит от следующих билетов:

  2. Улучшенная удобочитаемость таблиц

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

    Снимок экрана вики-страницы с параметром переноса по словам и горизонтальной полосой прокрутки.

  3. Автоформатировать таблицы Markdown

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

    Отчеты

    Расширение аналитики больше не требуется для использования аналитики

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

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

    Вот как клиенты могут включить аналитику:

    1. Перейдите к разделу Параметры коллекции проектов:

    Снимок экрана, на котором показано, где найти параметр аналитики.

    1. Щелкните включить аналитику .

    Снимок экрана, показывающий параметр "включить аналитику".

    Вот и все! Для коллекции будет включено взаимодействие с Power Analytics.

    В новых коллекциях, созданных в коллекциях Update 1 и Azure DevOps Server 2019 с установленным расширенным расширением аналитики, по умолчанию будет включена аналитика.

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


    Отзывы

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


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