Новое мини-приложение спринта и улучшенная безопасность конвейеров — обновление Sprint 160
В обновлении Azure DevOps для Sprint 160 мы добавили новое мини-приложение спринта, которое поддерживает запись по точкам истории, количеству задач и суммированию настраиваемых полей. Кроме того, мы улучшили безопасность конвейеров, ограничив область маркеров доступа.
Дополнительные сведения см. в списке функций ниже.
Новые возможности Azure DevOps
Компоненты
Azure Repos:
Azure Pipelines:
- Взаимодействие с многоэтапными конвейерами
- Оркестрация стратегии развертывания канареечного развертывания в среде для Kubernetes
- Политики утверждения для конвейеров YAML
- ACR как ресурс конвейера первого класса
- Метаданные ресурса конвейера в виде предопределенных переменных
- Возможность трассировки для конвейеров и ресурсов ACR
- Упрощенная авторизация ресурсов в конвейерах YAML
- Повышение безопасности конвейера путем ограничения область маркеров доступа
- Оценка проверка артефактов
- Поддержка Markdown в сообщениях об автоматических тестах
- Диагностика расписаний cron в YAML
- Обновления задачи развертывания шаблона ARM
- Безопасность на уровне проекта для подключений к службам
- Пул Ubuntu 18.04
- Развертывание канареек на основе интерфейса сетки службы в задаче KubernetesManifest
- ReviewApp in Environment
Azure Artifacts:
- Обновлен интерфейс подключения к веб-каналу
- Общедоступные веб-каналы теперь общедоступны с поддержкой вышестоящий
- Создание веб-каналов с областью проекта на портале
Отчеты:
Вики-сайт:
Azure Repos
Администрирование политики ветвей между репозиторием
Политики ветвей — это одна из мощных функций Azure Repos, которые помогают защитить важные ветви. Хотя возможность задавать политики на уровне проекта существует в REST API, для нее не было пользовательского интерфейса. Теперь администраторы могут устанавливать политики для определенной ветви или ветвь по умолчанию во всех репозиториях в своем проекте. Например, администратор может потребовать двух минимальных рецензентов для всех запросов на вытягивание, выполняемых в каждой ветви main в каждом репозитории в своем проекте. Функцию Добавить защиту ветвей можно найти в параметрах проекта Repos.
Azure Pipelines
Взаимодействие с многоэтапными конвейерами
Мы работаем над обновленным пользовательским интерфейсом для управления конвейерами. Эти обновления делают конвейеры современными и совместимыми с направлением Работы с Azure DevOps. Кроме того, эти обновления объединяют классические конвейеры сборки и многоэтапные конвейеры YAML в единый интерфейс. Например, в новый интерфейс включены следующие возможности. просмотр нескольких этапов и управление ими, утверждение запусков конвейера, возможность прокрутить весь путь назад в журналах во время выполнения конвейера, а также работоспособность конвейера для каждой ветви.
Спасибо всем, кто пробовал новый опыт. Если вы еще не пробовали, включите многоэтапные конвейеры в предварительной версии функций. Дополнительные сведения о многоэтапных конвейерах см. в документации здесь .
Благодаря вашим отзывам в последних двух обновлениях мы рассмотрели следующее.
- Возможность обнаружения представления папок.
- Прыжок в представлении журналов.
- Легко отображать журналы из предыдущих и текущих задач, даже если выполняется выполнение.
- Упростите навигацию между задачами при просмотре журналов.
Примечание
В следующем обновлении мы планируем включить эту функцию по умолчанию для всех пользователей. Вы по-прежнему сможете отказаться от предварительной версии. Через несколько недель после этого функция станет общедоступной.
Оркестрация стратегии развертывания канареечного развертывания в среде для Kubernetes
Одним из ключевых преимуществ непрерывной поставки обновлений приложений является возможность быстро отправлять обновления в рабочую среду для конкретных микрослужб. Это дает возможность быстро реагировать на изменения в бизнес-требованиях. Среда была представлена в качестве первоклассной концепции, позволяющей оркестрировать стратегии развертывания и упрощать выпуски с нулевым временем простоя. Ранее мы поддерживали стратегию runOnce , которая выполняла шаги один раз последовательно. Благодаря поддержке стратегии canary в многоэтапных конвейерах теперь можно снизить риск, медленно развертывая изменения в небольшом подмножестве. По мере повышения уверенности в новой версии вы можете приступить к развертыванию на большем количество серверов в вашей инфраструктуре и направить на нее больше пользователей.
jobs:
- deployment:
environment: musicCarnivalProd
pool:
name: musicCarnivalProdPool
strategy:
canary:
increments: [10,20]
preDeploy:
steps:
- script: initialize, cleanup....
deploy:
steps:
- script: echo deploy updates...
- task: KubernetesManifest@0
inputs:
action: $(strategy.action)
namespace: 'default'
strategy: $(strategy.name)
percentage: $(strategy.increment)
manifests: 'manifest.yml'
postRouteTaffic:
pool: server
steps:
- script: echo monitor application health...
on:
failure:
steps:
- script: echo clean-up, rollback...
success:
steps:
- script: echo checks passed, notify...
Стратегия canary для Kuberenetes сначала развертывает изменения с 10 % модулей pod, а затем 20 % при мониторинге работоспособности во время postRouteTraffic. Если все пойдет хорошо, он будет продвигаться до 100%.
Мы ищем ранние отзывы о поддержке ресурсов виртуальной машины в средах и реализации стратегии последовательного развертывания на нескольких компьютерах. Свяжитесь с нами , чтобы зарегистрироваться.
Политики утверждения для конвейеров YAML
В конвейерах YAML мы следуем конфигурации утверждения, управляемой владельцем ресурса. Владельцы ресурсов настраивают утверждения для ресурса и всех конвейеров, использующих ресурс, приостановку для утверждений перед началом этапа, используюющего ресурс. Владельцы приложений на основе SOX часто запрещают инициатору запроса развертывания утверждать собственные развертывания.
Теперь можно использовать расширенные параметры утверждения для настройки политик утверждения, таких как запроситель не должен утверждать, требовать утверждения от подмножества пользователей и время ожидания утверждения.
ACR как ресурс конвейера первого класса
Если вам нужно использовать образ контейнера, опубликованный в ACR (Реестр контейнеров Azure), как часть конвейера, и активировать конвейер при публикации нового образа, можно использовать ресурс контейнера ACR.
resources:
containers:
- container: MyACR #container resource alias
type: ACR
azureSubscription: RMPM #ARM service connection
resourceGroup: contosoRG
registry: contosodemo
repository: alphaworkz
trigger:
tags:
include:
- production
Кроме того, доступ к метаданным изображения ACR можно получить с помощью предопределенных переменных. Следующий список содержит переменные ACR, доступные для определения ресурса контейнера ACR в конвейере.
resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location
Метаданные ресурса конвейера в виде предопределенных переменных
Мы добавили в конвейер предопределенные переменные для ресурсов конвейеров YAML. Ниже приведен список доступных переменных ресурсов конвейера.
resources.pipeline.<Alias>.projectName
resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID
Возможность трассировки для конвейеров и ресурсов ACR
Мы обеспечиваем полную трассировку E2E при использовании в конвейере конвейеров и ресурсов контейнера ACR. Для каждого ресурса, используемого конвейером YAML, можно выполнить трассировку по фиксациям, рабочим элементам и артефактам.
В представлении сводки по выполнению конвейера можно увидеть следующее:
Версия ресурса, активировав запуск. Теперь конвейер можно активировать после завершения другого запуска конвейера Azure или при отправке образа контейнера в ACR.
Фиксации, используемые конвейером. Вы также можете найти разбивку фиксаций по каждому ресурсу, используемому конвейером.
Рабочие элементы, связанные с каждым ресурсом, используемым конвейером.
Артефакты, доступные для использования при выполнении.
В представлении развертываний среды можно просмотреть фиксации и рабочие элементы для каждого ресурса, развернутого в среде.
Упрощенная авторизация ресурсов в конвейерах YAML
Ресурс — это все, что используется конвейером, который находится за пределами конвейера. Ресурсы должны быть авторизованы, прежде чем их можно будет использовать. Ранее при использовании неавторизованных ресурсов в конвейере YAML произошел сбой с ошибкой авторизации ресурса. Вам пришлось авторизовать ресурсы на странице сводки неудачного выполнения. Кроме того, конвейер завершился сбоем, если он использовал переменную, которая ссылалась на неавторизованный ресурс.
Теперь мы упростим управление авторизацией ресурсов. Вместо того, чтобы завершить выполнение сбоем, он будет ожидать разрешений на ресурсы в начале этапа, потребляющего ресурс. Владелец ресурса может просматривать конвейер и авторизовать ресурс на странице Безопасность.
Повышение безопасности конвейера путем ограничения область маркеров доступа
Каждое задание, выполняемое в Azure Pipelines, получает маркер доступа. Маркер доступа используется задачами и сценариями для обратного вызова в Azure DevOps. Например, мы используем маркер доступа для получения исходного кода, отправки журналов, результатов тестирования, артефактов или для выполнения вызовов REST в Azure DevOps. Для каждого задания создается новый маркер доступа, срок действия которого истекает после завершения задания. В этом обновлении мы добавили следующие улучшения.
Запретить маркеру доступ к ресурсам за пределами командного проекта
До сих пор область по умолчанию для всех конвейеров была коллекция командных проектов. Вы можете изменить область на командный проект в классических конвейерах сборки. Однако у вас не было этого элемента управления для классических конвейеров выпуска или YAML. В этом обновлении мы представляем параметр организации, который позволяет каждому заданию получить маркер области проекта независимо от того, что настроено в конвейере. Мы также добавили параметр на уровне проекта. Теперь каждый новый проект и организация, которые вы создаете, будет автоматически включать этот параметр.
Примечание
Параметр организации переопределяет параметр проекта.
Включение этого параметра в существующих проектах и организациях может привести к сбою некоторых конвейеров, если конвейеры получают доступ к ресурсам, которые находятся за пределами командного проекта, с помощью маркеров доступа. Чтобы устранить сбои конвейера, можно явно предоставить учетной записи службы сборки Project доступ к нужному ресурсу. Настоятельно рекомендуется включить эти параметры безопасности.
Удаление определенных разрешений для маркера доступа
По умолчанию мы предоставляем ряд разрешений для маркера доступа, одно из которых — сборки очередей. В этом обновлении мы удалили это разрешение для маркера доступа. Если конвейерам требуется это разрешение, его можно явно предоставить учетной записи службы сборки Project или учетной записи службы сборки коллекции проектов в зависимости от используемого маркера.
Оценка проверка артефактов
Теперь можно определить набор политик и добавить оценку политики в качестве проверка в среде для артефактов образов контейнеров. При выполнении конвейера выполнение приостанавливается перед началом этапа, использующего среду. Указанная политика оценивается на основе доступных метаданных развертываемого образа. При успешном выполнении политики проверка помечает этап как сбой в случае сбоя проверка.
Поддержка Markdown в сообщениях об ошибках автоматического тестирования
Теперь мы поддерживаем Markdown в сообщениях об ошибках для автоматических тестов. Вы можете легко форматировать сообщения об ошибках для тестового запуска и результата теста, чтобы повысить удобочитаемость и упростить устранение неполадок в Azure Pipelines. Поддерживаемый синтаксис Markdown можно найти здесь.
Диагностика расписаний cron в YAML
Мы наблюдаем постоянное увеличение использования синтаксиса cron для указания расписаний в конвейерах YAML. Когда мы слушали ваши отзывы, мы услышали, что вам было трудно определить, правильно ли Azure Pipelines обработал ваш синтаксис. Ранее для отладки проблем с расписанием необходимо было дождаться фактического времени запланированного запуска. Чтобы упростить диагностику ошибок ветви или синтаксиса, мы добавили новое меню действий для конвейера. Запланированные запуски в меню Запуск конвейера предоставляют предварительный просмотр нескольких запланированных запусков конвейера, которые помогут диагностировать ошибки с помощью расписаний cron.
Обновления в задачу развертывания шаблона ARM
Ранее мы не фильтруем подключения служб в задаче развертывания шаблона ARM. Это может привести к сбою развертывания, если выбрано более низкое подключение службы область для выполнения развертывания шаблонов ARM в более широком область. Теперь мы добавили фильтрацию подключений служб, чтобы отфильтровать подключения служб с более низкой областью на основе выбранного область развертывания.
Безопасность на уровне проекта для подключений к службам
В этом обновлении мы добавили безопасность на уровне концентратора для подключений к службам. Теперь вы можете добавлять и удалять пользователей, назначать роли и управлять доступом в централизованном месте для всех подключений к службе.
Пул Ubuntu 18.04
Azure Pipelines теперь поддерживает выполнение заданий в Ubuntu 18.04. Мы обновили размещенный в Майкрософт пул Azure Pipelines, включив образ Ubuntu-18.04. Теперь, когда вы ссылаетесь на ubuntu-latest пул в конвейерах YAML, это будет означать ubuntu-18.04 , а не ubuntu-16.04. Вы по-прежнему можете использовать изображения 16,04 в заданиях, используя ubuntu-16.04 явно.
Canary deployments in KubernetesManifest task in KubernetesManifest
Ранее, когда в задаче KubernetesManifest была указана канареечная стратегия, задача создавала базовые и канарееарные рабочие нагрузки, реплики которых составляли процент от реплик, используемых для стабильных рабочих нагрузок. Это не совсем то же самое, что разделение трафика до требуемого процента на уровне запроса. Чтобы решить эту проблему, мы добавили поддержку канареечного развертывания на основе интерфейса сетки службы в задачу KubernetesManifest.
Абстракция интерфейса сетки службы позволяет настраивать подключаемые модули с поставщиками сетки служб, такими как Linkerd и Istio. Теперь задача KubernetesManifest берет на себя трудную работу по сопоставлению объектов SMI TrafficSplit со стабильными, базовыми и канарееическими службами в течение жизненного цикла стратегии развертывания. Требуемое процентное разделение трафика между стабильным, базовым и канарееарным является более точным, так как разделение трафика в процентах контролируется в запросах в плоскости сетки служб.
Ниже приведен пример последовательного выполнения канареечного развертывания на основе SMI.
- deployment: Deployment
displayName: Deployment
pool:
vmImage: $(vmImage)
environment: ignite.smi
strategy:
canary:
increments: [25, 50]
preDeploy:
steps:
- task: KubernetesManifest@0
displayName: Create/update secret
inputs:
action: createSecret
namespace: smi
secretName: $(secretName)
dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
deploy:
steps:
- checkout: self
- task: KubernetesManifest@0
displayName: Deploy canary
inputs:
action: $(strategy.action)
namespace: smi
strategy: $(strategy.name)
trafficSplitMethod: smi
percentage: $(strategy.increment)
baselineAndCanaryReplicas: 1
manifests: |
manifests/deployment.yml
manifests/service.yml
imagePullSecrets: $(secretName)
containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
postRouteTraffic:
pool: server
steps:
- task: Delay@1
inputs:
delayForMinutes: '2'
Просмотр приложений в среде
ReviewApp развертывает каждый запрос на вытягивание из репозитория Git в ресурс динамической среды. Рецензенты могут видеть, как выглядят эти изменения, а также работать с другими зависимыми службами, прежде чем они будут объединены в ветвь main и развернуты в рабочей среде. Это позволит легко создавать ресурсы reviewApp и управлять ими, а также пользоваться всеми возможностями трассировки и диагностики функций среды. С помощью ключевое слово reviewApp можно создать клон ресурса (динамически создать новый ресурс на основе существующего ресурса в среде) и добавить новый ресурс в среду.
Ниже приведен пример фрагмента YAML по использованию reviewApp в средах.
jobs:
- deployment:
environment:
name: smarthotel-dev
resourceName: $(System.PullRequest.PullRequestId)
pool:
name: 'ubuntu-latest'
strategy:
runOnce:
pre-deploy:
steps:
- reviewApp: MasterNamespace
Azure Artifacts
Обновлен интерфейс подключения к веб-каналу
Диалоговое окно Подключение к веб-каналу — это начальный путь к использованию Azure Artifacts. Он содержит сведения о том, как настроить клиенты и репозитории для отправки и извлечения пакетов из веб-каналов в Azure DevOps. Мы обновили диалоговое окно, чтобы добавить подробные сведения о настройке, и расширили инструменты, для которые мы предоставляем инструкции.
Общедоступные веб-каналы теперь общедоступны с поддержкой вышестоящий
Общедоступная предварительная версия общедоступных веб-каналов получила большое внедрение и отзывы. В этом обновлении мы расширили доступность дополнительных функций. Теперь можно задать общедоступный веб-канал в качестве источника вышестоящий из частного веб-канала. Вы можете упростить файлы конфигурации, позволяя вышестоящий как к частным веб-каналам, так и к веб-каналам уровня проекта.
Создание веб-каналов в области проекта на портале
Когда мы выпускали общедоступные веб-каналы, мы также выпускали веб-каналы для области проекта. До сих пор веб-каналы на уровне проекта можно было создавать с помощью REST API или путем создания общедоступного веб-канала, а затем превращения проекта в частный. Теперь вы можете создавать веб-каналы для области проекта непосредственно на портале из любого проекта, если у вас есть необходимые разрешения. Вы также можете просмотреть, какие веб-каналы являются проектом, а какие — областью организации, в средство выбора веб-каналов.
Отчеты
Мини-приложение Sprint Burndown со всем, что вы просили
Новое мини-приложение Sprint Burndown поддерживает запись по точкам истории, количеству задач или суммированию настраиваемых полей. Вы даже можете создать спринт для функций или epics. Мини-приложение отображает среднее сгорание, процент завершения и увеличение область. Вы можете настроить команду, позволяя отображать спринт прогона для нескольких команд на одной панели мониторинга. Благодаря всем этим замечательным сведениям мы можем изменить размер до 10x10 на панели мониторинга.
Чтобы опробовать его, можно добавить его из каталога мини-приложений или изменить конфигурацию существующего мини-приложения Sprint Burndown и установить флажок Попробовать новую версию.
Примечание
В новом мини-приложении используется аналитика. Мы сохранили устаревшую версию Sprint Burndown на случай, если у вас нет доступа к Аналитике.
Вики
Синхронная прокрутка для редактирования вики-страниц
Редактирование вики-страниц стало проще благодаря синхронной прокрутке между областью редактирования и предварительного просмотра. Прокрутка с одной стороны автоматически прокрутит другую сторону для сопоставления соответствующих разделов. Вы можете отключить синхронную прокрутку с помощью переключателя.
Примечание
Состояние переключателя синхронной прокрутки сохраняется для каждого пользователя и организации.
Посещения страниц для вики-страниц
Теперь вы можете получить аналитические сведения о посещениях страниц для вики-страниц. REST API позволяет получать доступ к сведениям о посещениях страниц за последние 30 дней. Эти данные можно использовать для создания отчетов для вики-страниц. Кроме того, эти данные можно хранить в источнике данных и создавать панели мониторинга для получения определенных аналитических сведений, таких как наиболее просматриваемые страницы.
Вы также увидите агрегированное количество посещений страниц за последние 30 дней на каждой странице.
Примечание
Посещение страницы определяется определенным пользователем как представление страницы с 15-минутным интервалом.
Дальнейшие действия
Примечание
Эти функции будут развернуты в течение следующих двух-трех недель.
Перейдите в Azure DevOps и посмотрите.
Отправка отзыва
Мы хотели бы услышать, что вы думаете об этих функциях. Используйте меню справки, чтобы сообщить о проблеме или предоставить предложение.
Вы также можете получить советы и ответы на свои вопросы от сообщества на Сайте Stack Overflow.
Thanks,
Джефф Билер
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по