Новые отчеты аналитики и приложение Azure Boards для Slack — обновление Sprint 155

В обновлении Azure DevOps для спринта 155 мы представляем новые отчеты Azure Boards, в которых можно просто отслеживать важные метрики команды. Новые отчеты отображаются на вкладке Analytics в центрах "Доски", "Невыполненная работа" и "Спринт". Эти отчеты полностью интерактивны, и их можно настраивать в соответствии со своими требованиями.

Кроме того, мы с радостью представляем новое приложение Azure Boards для Slack. Оно поможет вам отслеживать активность рабочих элементов и создавать их в канале Slack.

Дополнительные сведения см. в списке функций ниже.

Новые возможности Azure DevOps

Функции

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

Azure Boards:

Azure Repos.

Azure Artifacts:

Azure Pipelines.

   Многоступенчатые конвейеры YAML:

Размещенные виртуальные машины

Kubernetes

Тест

Возможности Azure

Интеграции

Общие

приглашение участников совместной работы GitHub в Azure DevOps.

Теперь вы можете пригласить участников совместной работы из GitHub в Azure DevOps при входе с помощью удостоверения GitHub. Вы можете искать и приглашать других пользователей GitHub на домашней странице Project и на странице "Пользователи" в параметрах организации.

Invite GitHub collaborators into Azure DevOps.

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

Enable for existing organizations.

Примечание.

Эта функция недоступна для пользователей, отличных от GitHub, даже если политика включена.

Дополнительные сведения о приглашении участников группы см. здесь. Если у вас возникли проблемы с подключением к Azure DevOps с помощью GitHub, ознакомьтесь с часто задаваемыми вопросами об проверке подлинности и приглашении пользователей GitHub.

Azure Boards

получение аналитических сведений о работоспособности команды из трех новых отчетов Azure Boards;

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

Три новых интерактивных отчета: Бернdown, накопительная схема потоков (CF) и скорость. Отчеты можно просмотреть на новой вкладке аналитики.

Метрики, такие как спринт сгорание, поток работы и скорости команды дают вам видимость прогресса вашей команды и помочь ответить на такие вопросы, как:

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

Примечание.

Ранее диаграммы, отображаемые в заголовках, были заменены этими расширенными отчетами.

Новые отчеты полностью интерактивны и позволяют настраивать их в соответствии с вашими потребностями. Новые отчеты можно найти на вкладке "Аналитика" в каждом концентраторе.

  • Диаграмма сожжения находится в центре Sprints .

    Analytics tab in Sprint hub.

  • Доступ к отчетам ПО CF и Скорость можно получить на вкладке "Аналитика" в разделе "Доски и невыполненные работы", щелкнув соответствующий карта.

    CFD and velocity reports in boards.

С новыми отчетами у вас есть больше контроля и сведений о вашей команде. Далее приводятся некоторые примеры.

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

Ниже приведен пример отчета ПО CF, показывающего поток за последние 30 дней невыполненной работы.

Example of the CFD report.

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

Example of a velocity report.

приложение Azure Boards для Slack;

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

Приложение позволяет настраивать подписки на события и управлять ими, включая создание и обновления рабочих элементов, а также получать уведомления об этих событиях в канале Slack. Беседы в канале Slack можно использовать для создания рабочих элементов. При назначении рабочих элементов вы также получите личные уведомления. Кроме того, предварительные версии URL-адресов рабочих элементов позволяют инициировать обсуждения.

Azure Boards app for Slack.

Чтобы установить приложение Azure Boards, щелкните здесь.

Настройка столбцов панели задач

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

Чтобы настроить столбцы на панели задач, перейдите в раздел "Параметры столбца".

Customizing columns on the taskboard.

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

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

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

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

Show or hide child items on the backlog.

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

Activate the instant search box.

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

Search for a board name.

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

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

Most recent used tags displayed when tagging a work item.

Azure Repos

улучшенные параметры фильтрации при поиске кода;

Ранее поиск кода поддерживал 39 фильтров поиска кода, таких как комментарий: и def:. Данные предположили, что было много фильтров, которые не используются, поэтому мы удаляем несколько фильтров и объединяем других. В этом обновлении мы сократили число фильтров до 19. Это поможет сделать запросы поиска кода более эффективными и уменьшить беспорядок в интерфейсе.

Code search filter options.

Например, теперь func: сопоставляется с методом:, т. е. если вы ищете func:Account Администратор, результаты будут сопоставлены с методом:Account Администратор. Аналогично макродеф: и макроref: сопоставляются с макрос:. С другой стороны, фильтры, такие как объединение: и организация: устарели из-за отсутствия использования.

метрики объема протестированного кода и политика ветви для запросов на вытягивание;

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

Code coverage metrics and branch policy for pull requests

View details of coverage information for every code line that is changed.

Кроме того, владельцы репозитория теперь могут устанавливать политики покрытия кода и предотвращать объединение больших, непроверенных изменений в ветвь. Требуемые пороговые значения покрытия можно определить в azurepipelines-coverage.yml файле параметров, который проверка в корне репозитория и политики покрытия, можно определить с помощью существующей политики настройки политики ветвей для дополнительных возможностей служб в Azure Repos.

Define coverage thresholds.

фильтрация уведомлений о комментариях в запросах на вытягивание;

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

Filter comment notifications from pull requests.

Filter comment notifications in User settings.

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

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

Service hooks for pull request comments.

Azure Artifacts

предоставление общего доступа к пакетам с помощью общедоступных каналов (предварительная версия).

Теперь вы можете создавать и хранить пакеты в общедоступных веб-каналах. Пакеты, хранящиеся в общедоступных веб-каналах, доступны всем пользователям в Интернете без проверки подлинности, независимо от того, находятся ли они в вашей организации или даже вошли в организацию Azure DevOps. Узнайте больше о общедоступных веб-каналах в документации по веб-каналам или перейдите прямо в наше руководство по совместному использованию пакетов.

Share your packages with public feeds.

Azure Pipelines

kustomize и kompose как варианты моделирования в задаче KubernetesManifest;

kustomize (часть Kubernetes sig-cli) позволяет настраивать необработанные файлы YAML без шаблонов для нескольких целей и оставлять исходные YAML неоткрытыми. Параметр kustomize добавлен в действие выпечки задачи KubernetesManifest, чтобы любая папка, содержащая файлы kustomization.yaml, можно использовать для создания файлов манифеста, используемых в действии развертывания задачи KubernetesManifest.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

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

kompose преобразует файлы Docker Compose в ресурс Kubernetes.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

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

поддержка учетных данных администратора кластера в задаче HelmDeploy.

Ранее задача HelmDeploy использовала учетные данные пользователя кластера для развертываний. Это привело к интерактивным запросам входа и сбоям конвейеров для кластера с поддержкой RBAC в Azure Active Directory. Для решения этой проблемы мы добавили проверка box, который позволяет использовать учетные данные администратора кластера вместо учетных данных пользователя кластера.

Package and deploy Helm charts showing the use cluster admin credentials checkbox.

управление переменными конвейера в редакторе YAML;

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

Manage pipeline variables in YAML editor.

новые предопределенные переменные в конвейере YAML;

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

  • Environment.Id — идентификатор среды.
  • Environment.Name — имя среды, предназначенной для задания развертывания.
  • Environment.ResourceId — идентификатор ресурса в среде, предназначенной для задания развертывания.
  • Environment.ResourceName — имя ресурса в среде, предназначенной для задания развертывания.

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

отмена этапа в запущенном многоэтапном конвейере YAML;

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

утверждения в многоступенчатых конвейерах YAML;

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

Approvals in multi-stage YAML pipelines.

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

Pipeline runs deploying to dev will stop for approval.

обновления для образов размещенных конвейеров;

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

  • Для VS2017 и VS2019:

  • Для Ubuntu 16.04:

    • Обновлен helm, чтобы всегда вытягивать последние (больше не закреплены в версии 2.14.0)
    • Добавлено несколько популярных контейнеров Docker
    • Обновлен Python до версий 2.7.16, 3.4.10, 3.5.7, 3.6.9, 3.7.4
    • Изменены пути по умолчанию Rust и переменные среды
  • Для всех образов добавлена переменная ImageVersion среды для версии образа.

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

улучшения проекта DevOps для виртуальной машины.

В этом обновлении мы улучшили рабочий процесс виртуальной машины DevOps Projects, чтобы включить виртуальные машины, которые не соответствуют ограничению квоты расположения. Ранее вам пришлось выбрать виртуальную машину по имени и предложению. Теперь у вас есть представление по запросу с дополнительными сведениями о предложениях виртуальных машин, таких как стоимость/месяц, ОЗУ, диски данных и т. д. Это упрощает выбор нужной виртуальной машины.

Enhancements to DevOps Project for virtual machine.

Отдельный размещенный пул

В последнем спринте мы сообщили о том, что мы развертываем новый размещенный пул с именем Azure Pipelines, чтобы заменить все остальные размещенные пулы : Hosted, Hosted VS2017, Hosted Ubuntu 1604, Hosted Windows 2019 with VS2019, Hosted macOS и Hosted macOS High Sierra. Это изменение будет реализовано с помощью этого выпуска.

Наличие нескольких размещенных пулов может быть запутанным в разы. Вы не получите точное представление о том, где используется параллелизм. Например, если у вас есть параллелизм 10 параллельных заданий, вы увидите 10 виртуальных агентов в каждом из размещенных пулов, которые не точны. Когда задание ожидает определенного размещенного пула (например, размещенного VS2017) со всеми агентами простоя, вы можете подумать, что служба Azure Pipelines нарушена, не зная, что параллелизм может использоваться в других размещенных пулах (например, размещенной Ubuntu 1604).

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

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

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

встроенная поддержка управления ненадежными тестами.

Тесты Flaky могут повлиять на производительность разработчиков, так как сбои тестов могут не быть связаны с изменениями в тесте. Они также могут повлиять на качество отправленного кода. Именно поэтому мы добавили поддержку в продукте для управления тестами flaky. Эта функция поддерживает комплексный жизненный цикл с обнаружением, отчетом и разрешением. Управление тестами Flaky поддерживает системное и настраиваемое обнаружение.

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

In-product support for flaky test management.

Ниже приведен пример отчета с сводкой теста.

Example of a report with the test summary.

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

Усовершенствования Центра развертывания для WebApp в портал Azure

Мы улучшили Центр развертывания для WebApp в портал Azure с поддержкой конвейеров с несколькими артефактами. Теперь, если в веб-приложении развернут не основной артефакт Azure Pipelines, вы получите соответствующие сведения из портал Azure. Вы также будете иметь глубокую ссылку на развернутый репозиторий, чтобы перейти непосредственно к репозиторию из портал Azure. Репозиторий можно разместить в Azure Repos или в GitHub.

триггеры непрерывной интеграции для новых ветвей;

Это был длинный ожидающий запрос, чтобы не запускать сборки CI при создании новой ветви и когда эта ветвь не имеет изменений. Рассмотрим следующие примеры:

  • Веб-интерфейс используется для создания новой ветви на основе существующей ветви. Это сразу же активирует новую сборку CI, если фильтр ветви соответствует имени новой ветви. Это нежелательно, так как содержимое новой ветви совпадает при сравнении с существующей ветвью.
  • У вас есть репозиторий с двумя папками — приложением и документами. Вы настроили фильтр путей для CI, соответствующий приложению. Другими словами, вы не хотите создавать новую сборку, если изменения были отправлены в документы. Вы создаете новую ветвь локально, вносите некоторые изменения в документы, а затем отправляете эту ветвь на сервер. Мы использовались для активации новой сборки CI. Это нежелательно, так как вы явно попросили не искать изменения в папке документов. Тем не менее, из-за того, как мы обрабатывали новое событие ветви, казалось бы, как если бы изменения были сделаны в папку приложения, а также.

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

интеграция Terraform с Azure Pipelines;

Terraform — это средство с открытым исходным кодом для разработки, изменения и управления версиями инфраструктуры безопасно и эффективно. Terraform кодифицирует API в декларативные файлы конфигурации, позволяющие определять и подготавливать инфраструктуру с помощью языка высокоуровневой конфигурации. Расширение Terraform можно использовать для создания ресурсов для всех основных поставщиков инфраструктуры: Azure, Amazon Web Services (AWS) и Google Cloud Platform (GCP).

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

Terraform integration with Azure Pipelines.

интеграция с Google Analytics.

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

Расширение экспериментов Google Analytics для Azure DevOps добавляет шаги экспериментирования в конвейеры сборки и выпуска, чтобы вы могли непрерывно итерировать, изучать и развертывать в ускоренном темпе, управляя экспериментами на постоянной основе при получении всех преимуществ DevOps от Azure Pipelines.

Вы можете скачать расширение экспериментов Google Analytics из Marketplace.

Integration with Google Analytics.

кэширование конвейера (общедоступная предварительная версия).

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

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

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

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

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

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

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

При создании конвейеров иногда требуется создать и зафиксировать ФАЙЛ YAML, а не активировать запуск конвейера, так как это может привести к сбоям из-за различных причин. Инфраструктура не готова или не требуется создавать и обновлять группы переменных или переменных и т. д. С помощью Azure DevOps CLI теперь можно пропустить первый автоматизированный запуск конвейера при создании конвейера, включив параметр --skip-first-run. Дополнительные сведения см. в документации по команде az pipeline create.

Улучшение команды конечной точки службы

Команды CLI конечной точки службы поддерживают только конечную точку службы azure rm и github. Однако с этим выпуском команды конечной точки службы позволяют создавать любую конечную точку службы, предоставляя конфигурацию через файл и предоставляя оптимизированные команды — az devops service-endpoint github и az devops service-endpoint azurerm, которые обеспечивают поддержку первого класса для создания конечных точек служб этих типов. Дополнительные сведения см. в документации по командам.

Следующие шаги

Примечание.

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

Перейдите к Azure DevOps и посмотрите.

Отправка отзыва

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

Make a suggestion

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

Thanks,

Сэм Guckenheimer