Поделиться через

Улучшения YAML в Azure Pipelines — обновление Sprint 142

В обновлении спринта 142 Azure DevOps было несколько улучшений в YAML, таких как добавление пользовательских счетчиков в сборки, указание ветвей для сборки запросов на pull и использование встроенных шаблонов. Мы также включили новую навигацию для всех пользователей, ввели темную тему и улучшили возможности связывания и вложений в Azure Boards.

См. список функций ниже для получения дополнительной информации.

Функции

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

Azure Boards:

Azure Repos.

Azure Pipelines.

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

Артефакты Azure:

Вики:

Администрация:

General

Новая навигация включена для всех пользователей.

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

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

Темная тема

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

Темная тема

Azure Boards

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

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

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

Управление зависимостями путем связывания рабочих элементов между организациями

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

Замечание

Разрешения соблюдаются в обеих организациях Azure DevOps, которые должны поддерживаться одинаковым клиентом Azure AD.

Удаленная ссылка

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

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

Azure Repos

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

Одной из проблем для автора расширения управления версиями является получение контекста репозитория, отображаемого пользователю, например имя, идентификатор и URL-адрес. Для этого мы добавили VersionControlRepositoryService в качестве службы, доступной для расширений. С помощью этого автор расширения может запрашивать сведения о текущем контексте репозитория Git в пользовательском веб-интерфейсе. В настоящее время он имеет один метод getCurrentGitRepository().

  • Если выбран репозиторий Git, объект GitRepository возвращается с основными данными о репозитории (имя, идентификатор и URL-адрес)
  • Если выбран репозиторий TFVC или доступ к службе осуществляется за пределами страниц Azure Repos, будет возвращено значение null.

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

Azure Pipelines (система конвейеров Azure)

Добавьте настраиваемые счетчики в ваши сборки.

Счетчики сборки предоставляют возможность уникально нумеровать и маркировать сборки. Ранее для этого можно использовать специальную переменную $(rev:r). Теперь вы можете определить собственные переменные счетчика в определении сборки, которые автоматически увеличиваются при каждом запуске сборки. Это можно сделать на вкладке переменных определения. Эта новая функция обеспечивает большую мощность следующими способами:

  • Можно определить настраиваемый счетчик и задать его начальное значение. Например, можно запустить счетчик с 100. $(rev:r) всегда начинается с 0.
  • Для сброса счетчика можно использовать собственную пользовательскую логику. $(rev:r) привязан к процессу генерации номеров сборок и автоматически сбрасывается при появлении нового префикса в номере сборки.
  • Можно определить несколько счетчиков для каждого определения.
  • Можно запросить значение счетчика за пределами сборки. Например, можно подсчитать количество сборок, которые выполнялись с момента последнего сброса, используя счетчик.

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

Используйте YAML для указания ветвей для сборки в pull request'ах.

Конвейеры YAML могут указать, какие ветви следует создавать для PR (запросы на вытягивание). Можно выбрать ветви для включения и исключения. Эта возможность была ранее доступна в пользовательском веб-интерфейсе. Переместив его в YAML-файл, он становится частью рабочего процесса config-as-code.

Пример использования триггеров PR может выглядеть следующим образом:

pr:
  branches:
    include:
    - features/*
    exclude:
    - features/experimental/*
  paths:
    include:
    - **/*.cs

steps:
- script: echo My PR build!

Используйте шаблоны выражений YAML в строке.

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

- task: msbuild@1
  inputs:
    solution: ${{ parameters.solution }}

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

- script: echo The solution file is ${{ parameters.solution }}

Улучшение возможностей устранения неполадок благодаря журналу инициализации конвейера.

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

Срок хранения по умолчанию для конвейеров YAML.

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

Сборка на платформах Linux, ARM и 32-разрядных платформах Windows.

Агент Azure Pipelines открытый код кроссплатформенный агент всегда поддерживается в 64-разрядной версии Windows, macOS и Linux. В этой спринте мы представляем две новые поддерживаемые платформы: Linux/ARM и Windows/32-разрядная версия. Эти новые платформы дают возможность создавать на менее распространенных, но не менее важных платформах, таких как Raspberry Pi, компьютер Linux или ARM.

Клонирование групп переменных.

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

Клонировать группу переменных

Замечание

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

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

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

Связанные источники

Поддержка функции "Run from Package" (Запуск из пакета) в развертываниях Службы приложений Azure.

Теперь задача развертывания службы приложений Azure (4.*) поддерживает RunFromPackage (ранее назывался RunFromZip).

Служба приложений поддерживает ряд различных методов развертывания файлов, таких как msdeploy (aka WebDeploy), git, ARM и многое другое. Но все эти методы имеют ограничение. Файлы развертываются в папке wwwroot (в частности d:\home\site\wwwroot), а среда выполнения запускает файлы изтуда.

С функцией 'Run From Package' больше нет этапа развертывания, который копирует отдельные файлы в wwwroot. Вместо этого вы просто указываете его на ZIP-файл, и ZIP-файл подключается к wwwroot в качестве файловой системы только для чтения. Это дает ряд преимуществ.

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

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

Версия 4.* задачи развертывания службы приложений Azure теперь поддерживает развертывание собственного пользовательского контейнера для Azure Functions в Linux.

Модель размещения Linux для Azure Functions основана на контейнерах Docker, которые обеспечивают большую гибкость как для упаковки, так и для использования специфических зависимостей приложения. Функции в Linux можно размещать в 2 разных режимах:

  1. Встроенный образ контейнера: код приложения-функции и Azure предоставляет контейнер (встроенный режим образа), поэтому не требуется никаких конкретных знаний, связанных с Docker. Это поддерживается в текущей версии задачи развертывания в службе App Service.
  2. Пользовательский образ контейнера: Мы улучшили задачу развертывания службы приложений для поддержки развертывания пользовательских образов контейнеров в Azure Functions на Linux. Если вашим функциям требуется определенная языковая версия или зависят от конкретной зависимости или конфигурации, которая не предоставляется во встроенном образе, вы можете создать и развернуть кастомный образ в Azure Functions на Linux с помощью Azure Pipelines.

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

Клиент Azure Test Runner для выполнения ручных тестов настольных приложений

Теперь можно использовать клиент запуска тестов Azure (ATR) для выполнения ручных тестов для классических приложений. Это поможет вам перейти от Microsoft Test Manager к планам тестирования Azure. Пожалуйста, ознакомьтесь с нашим руководством здесь. С помощью клиента ATR можно выполнять тесты вручную и записывать результаты теста для каждого шага теста. У вас также есть возможности сбора данных, такие как снимок экрана, журнал действий изображений и запись аудио. Если при тестировании возникла проблема, используйте Test Runner для создания ошибки с шагами тестирования, снимками экрана и примечаниями, которые автоматически включаются в ошибку.

Для ATR требуется одноразовая загрузка и установка модуля runner. Выберите Запустить для настольного приложения, как показано ниже.

Средство запуска тестов Azure

Установка Azure Test Runner

Azure Artifacts

"Артефакты конвейера" (общедоступная предварительная версия).

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

Вики

Публикация кода в виде вики-сайта с разрешениями на совместное участие.

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

Administration

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

В феврале 2017 года мы объявили о поддержке политики условного доступа Azure Active Directory (CAP), но было ограничение, что альтернативные механизмы проверки подлинности, такие как личные маркеры доступа, не будут применять CAP. Мы рады сообщить, что мы заполнили этот пробел, и Azure DevOps теперь будет учитывать политики ограждения IP-адресов CAP при использовании PATs, ключей SSH, альтернативных учетных данных проверки подлинности и OAuth. Администраторам не нужно ничего делать, чтобы воспользоваться этой функцией. Она будет автоматически применена ко всем существующим политикам.

Дальнейшие шаги

Замечание

Эти функции будут развернуты в течение следующих двух-трех недель.

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

Перейдите в Azure DevOps

Как предоставить отзыв

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

Внести предложение

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

Спасибо,

Аарон Бьорк

  • Last updated on