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

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

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

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

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

---

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

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

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

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

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

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

• CVE-2023-36869: уязвимость Azure DevOps Server спуфингом.
• Обновите службу SSH для поддержки SHA2-256 и SHA2-512. Если у вас есть SSH-файлы конфигурации, жестко закодированные для использования RSA, следует выполнить обновление до SHA2 или удалить запись.
• Исправлена ошибка бесконечного цикла в CronScheduleJobExtension.

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

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

• Исправлена ошибка, которая мешала отправке пакетов при обновлении с версии 2018 или более ранней версии.

Azure DevOps Server 2019 г. Обновление 1.2. Дата выпуска обновления 2: 13 декабря 2022 г.

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

• Исправлены сбои в задании "Аналитика синхронизации параллелизма учетных записей".

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

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

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

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

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

Примечание

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

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

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

Azure DevOps Server 2019 с обновлением 1.1, обновление 13 Дата выпуска: 26 января 2022 г.

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

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

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

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

Примечание

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

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

Хэш SHA-256: DB762E391F9DF8E71E58D6FAA169CA44DFBE996AE6567B55F772CBA9E3DA2AB3

Azure DevOps Server 2019 обновление 1.1, обновление 12 Дата выпуска: 15 сентября 2021 г.

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

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

Azure DevOps Server 2019 обновление 1.1. Обновление 11 Дата выпуска: 14 сентября 2021 г.

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

• Устраните проблему, которая была обнаружена в этом Сообщество разработчиков отзыве.

Azure DevOps Server 2019 г. Обновление 1.1 Дата выпуска исправления 10: 10 августа 2021 г.

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

• Исправлена проблема с заданиями доставки электронной почты для некоторых типов рабочих элементов.

Azure DevOps Server 2019 обновление 1.1, обновление 9 Дата выпуска: 15 июня 2021 г.

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

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

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

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

• CVE-2021-27067 : раскрытие информации
• Устранение проблемы, о чем сообщалось в этом Сообщество разработчиков запросе на отзыв | Не удалось зарегистрировать сведения об итерации результатов теста в Azure DevOps Server 2019 г.

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

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

Если у вас Azure DevOps Server 2019 с обновлением 1.1, необходимо установить Azure DevOps Server 2019 с обновлением 1.1 с обновлением 8.

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

• Вариант 1. Запустите 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 с обновлением 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

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

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

~$ tfx login
Copyright Microsoft Corporation

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

6. Выполните следующую команду, чтобы отправить задачу на сервер. Используйте путь к извлеченному ZIP-файлу из шага 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019 г. обновление 1.1. Обновление 7 Дата выпуска: 12 января 2021 г.

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

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

Azure DevOps Server 2019 г. обновление 1.1. Обновление 6 Дата выпуска: 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 с обновлением 6.

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

• Вариант 1. Запустите 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, исправление 6, версия будет 17.153.30723.5.

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

Примечание

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

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

1. Установите Azure PowerShell модуль Az 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

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

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

~$ tfx login
Copyright Microsoft Corporation

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

6. Выполните следующую команду, чтобы отправить задачу на сервер. Путь к извлечению пакета будет иметь следующий формат : D:\tasks\AzurePowerShellv4.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

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

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

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

Azure DevOps Server 2019 г. обновление 1.1. Обновление 4 Дата выпуска: 14 июля 2020 г.

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

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

Azure DevOps Server 2019 г. обновление 1.1. Обновление 3 Дата выпуска: 9 июня 2020 г.

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

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

Azure DevOps Server 2019 г. обновление 1.1. Обновление 2 Дата выпуска: 14 апреля 2020 г.

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

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

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

Azure DevOps Server 2019 г. обновление 1.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

• В уведомлениях конвейеров такие поля, как Длительность, могут иметь значение NULL в некоторых языковых стандартах.
• Путь к шаблону может не указывать на допустимый JSON-файл в конвейере, который включает развертывание группы ресурсов Azure.
• Страница параметров хранения на уровне коллекции отображается на страницах параметров проекта.

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

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

Общее

• Коллекции не сортируются в алфавитном порядке.

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

• Высокая загрузка памяти.
• Серверам с конфигурациями подсистемы балансировки нагрузки пришлось явно добавить открытый источник в запись реестра AllowedOrigins.
• Пользователи, устанавливающие SQL Azure, не видят диалоговое окно "Завершить пробную версию".
• При установке расширений возникает ошибка "Сообщение об ошибке Отсутствует вклад (ms.vss-dashboards-web.widget-sdk-version-2)".
• При настройке эластичного поиска возникает ошибка "Пользователь не авторизован".
• Сбои индексирования и запросов в эластичном поиске при обновлении TFS 2018 с обновлением 2 или более поздней версии.
• Шаг "Создать хранилище" завершается сбоем при настройке Azure DevOps Server.

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

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

---

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

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

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

---

Azure DevOps Server 2019 г. Обновление 1 Дата выпуска: 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 представлено множество новых функций. Вот некоторые из них:

• Новый базовый процесс
• Запрос работы относительно начала дня, недели, месяца или года
• Принятие и выполнение проблем в GitHub при планировании в Azure Boards
• Повторный запуск сборки с истекшим сроком действия для автоматического завершения запросов на вытягивание
• Новые типы слияния для выполнения запросов на вытягивание
• Активация конвейеров YAML с тегами
• Помощник задач для редактирования файлов YAML
• Веб-редактор с IntelliSense для конвейеров YAML
• Управление выпусками GitHub с помощью конвейеров
• Мини-приложение тренда результатов теста (дополнительно)
• Сведения о происхождении пакетов
• Поддержка пакетов Python
• Вышестоящие источники для Maven
• Внедрение результатов запроса Azure Boards на вики-сайте
• Постоянные ссылки для вики-страниц
• Уведомления на вики-страницах
• Расширение аналитики больше не требуется для использования Аналитики

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

• Общие сведения
• Boards
• Repos
• Конвейеры
• Test Plans
• Артефакты
• Вики
• Отчеты

---

Общее

Темная тема

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

Boards

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

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

Новый базовый процесс предоставляет три типа рабочих элементов ("Эпики", "Проблемы" и "Задачи") для планирования и отслеживания работы. Мы рекомендуем использовать проблемы для отслеживания таких вещей, как пользовательские истории, ошибки и функции, а с помощью epics — группировать проблемы в более крупные единицы работы. По мере выполнения работы перемещайте элементы по простому рабочему процессу состояния To Do, Doing и Done.

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

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

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

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

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

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

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

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

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

Файл сведений репозитория часто является домом, к которому обращается проектная группа, чтобы получить сведения о том, как участвовать в разработке решения и использовать его. Теперь, как и с состоянием сборки или развертывания в Azure Pipelines, вы можете добавить в файл сведений эмблему для доски команды в Azure Boards. Вы можете настроить индикатор событий так, чтобы отображались только столбцы In Progress или все столбцы, и даже сделать индикатор общедоступным, если проект открытый код.

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

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

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

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

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

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

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

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

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

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

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

Переход к Azure Boards рабочих элементов непосредственно из упоминаний в любом комментарии GitHub

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

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

Принятие и выполнение проблем в GitHub при планировании в Azure Boards

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

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

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

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

Repos

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

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

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

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

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

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

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

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

Примечание

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

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

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

Новые типы слияния для выполнения запросов на вытягивание

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

Теперь в диалоговом окне "Завершить запрос на вытягивание " вы увидите следующие новые параметры:

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перейти к поддержке команд в Azure Repos

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

Pipelines

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

Если вы используете YAML для определения конвейеров, теперь вы можете воспользоваться новыми возможностями редактора, представленными в этом выпуске. Независимо от того, создаете ли вы новый конвейер YAML или редактируете существующий конвейер YAML, вы сможете изменить файл YAML в веб-редакторе конвейера. При редактировании YAML-файла используйте клавиши CTRL+ПРОБЕЛ для поддержки IntelliSense. Вы увидите выделенные синтаксические ошибки, а также получите помощь по исправлению этих ошибок.

Помощник задач для редактирования файлов YAML

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

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

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

Вы можете указать, какие теги следует включить и исключить. Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки на определенные строки в журнале сборки

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

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

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

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

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

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

Ниже приведены два балла о вкладе.

1. Кнопка "Пользовательское действие" на панели инструментов

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

   

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

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

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

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

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

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

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

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

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

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

Перехватчик службы примечаний Grafana

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

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

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

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

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

Задача установщика Интерфейса командной строки Docker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подключение к реестру контейнеров Azure в службе реестра Docker

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

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

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

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

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

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

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

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

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

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

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

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

• Стратегия развертывания. Выбор канарной стратегии с действием развертывания приводит к созданию требуемого процента рабочих нагрузок с суффиксами -baseline и -canary , чтобы их можно было сравнить во время 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, чтобы упростить процесс разработки конвейера. Теперь команду buildAndPush можно использовать для создания нескольких тегов для определенного репозитория контейнеров и отправки их в несколько реестров контейнеров за один шаг. Задача может использовать подключения службы реестра 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 , такие как "v1.14.0", принимаются в качестве допустимых значений для входных данных спецификации версии Kubectl.

Улучшения интеграции ServiceNow

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

Поддержка 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. Дополнительные сведения о переходе с модуля Azure RM на Azure PowerShell модуле Az см. здесь.

Примечание

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

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

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

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

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

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

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

Теперь вы можете указать Azure Pipelines игнорировать фиксацию и пропустить запуск конвейера, который обычно активируется фиксацией. Просто включите [skip ci] в сообщение о фиксации HEAD фиксации, и 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

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

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

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

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

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

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

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

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

Уровни общего доступа включают:

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

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

Artifacts

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

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

Сведения о происхождении пакетов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вики

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

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

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

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

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

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

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

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

Шрифт monospaced для редактора Markdown вики-сайта

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

Постоянные ссылки для вики-страниц

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

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

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

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

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

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

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

@упоминание пользователей и групп". />

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

@упоминание". />

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

Уведомления на вики-страницах

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

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

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

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

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

   

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

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

   Примечание

   Этот тег не поддерживается в браузерах Edge и Internet Обозреватель.

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

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

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

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

   

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

   • Представление таблицы для вики-сайта
   • Упрощение вставки таблиц на вики-сайте

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

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

   

3. Автоформатирование таблиц Markdown

   Больше не нужно добавлять пробелы для выравнивания столбцов Markdown. С помощью кнопки Формат таблиц таблицы Markdown автоматически форматируются путем добавления пробелов в ячейки для выравнивания столбцов. Если у вас большие таблицы, используйте их с отключением переноса по словам , чтобы упростить чтение таблиц.

   

   Вы также можете использовать сочетание клавиш CTRL+SHIFT+F для форматирования таблиц.

Отчеты

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

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

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

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

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

2. Щелкните Включить аналитику.

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

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

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

• Дополнительные сведения о включении аналитики см. в этой статье.
• Ознакомьтесь с документацией по обзору аналитики.
• Ознакомьтесь с основными функциями: Мини-приложения аналитики, отчет о наиболее неудачных тестах, интеграция Power BI и конечная точка OData.
• Просмотрите это видео channel 9 в Azure DevOps Analytics.

---

Отзывы

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

---

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