Новое мини-приложение очистки спринта и улучшенная безопасность конвейеров — обновление Sprint 160
В обновлении Sprint 160 Azure DevOps мы добавили новое мини-приложение спринта, которое поддерживает сжигание по точкам истории, подсчету задач и суммированию настраиваемых полей. Кроме того, мы повысили уровень безопасности конвейеров, ограничив область маркеров доступа.
Дополнительные сведения см. в списке функций ниже.
Новые возможности Azure DevOps
Функции
Azure Repos.
Azure Pipelines.
- пользовательский интерфейс многоэтапных конвейеров;
- оркестрация стратегии "канареечного" развертывания в среде для Kubernetes;
- политики утверждения для конвейеров YAML;
- ACR в качестве ресурса конвейера первого класса
- метаданные ресурсов конвейеров как предварительно определенные переменные;
- Возможность трассировки для конвейеров и ресурсов ACR
- упрощенная авторизация ресурсов в конвейерах YAML;
- повышение уровня безопасности конвейеров за счет ограничения области маркеров доступа;
- оценка проверки артефактов;
- поддержка Markdown в отправляемых автоматически сообщениях об ошибках проверки;
- диагностика расписаний Cron в YAML;
- Обновления задачи развертывания шаблона ARM
- безопасность на уровне проекта для подключений служб;
- пул Ubuntu 18.04;
- "канареечные" развертывания на базе Service Mesh Interface в задании KubernetesManifest;
- ReviewApp в среде.
Azure Artifacts:
- обновленное подключение к веб-каналу;
- общедоступная версия открытых веб-каналов с поддержкой вышестоящих источников;
- создание веб-каналов в рамках проекта с помощью портала.
Отчеты —
Вики
Azure Repos
администрирование политики ветвей между репозиториями.
Политики ветви — это одна из мощных функций Azure Repos, которые помогают защитить важные ветви. Хотя возможность задать политики на уровне проекта существует в REST API, для него не было пользовательского интерфейса. Теперь администраторы могут задавать политики в определенной ветви или ветвь по умолчанию во всех репозиториях в своем проекте. Например, администратор может требовать двух минимальных рецензентов для всех запросов на вытягивание, сделанных в каждую ветвь в каждом репозитории в своем проекте. Функцию "Добавить ветвь" можно найти в параметрах проекта Repos.
Azure Pipelines
пользовательский интерфейс многоэтапных конвейеров;
Мы работали над обновленным интерфейсом пользователя для управления конвейерами. Эти обновления делают конвейеры современными и согласованными с направлением Azure DevOps. Кроме того, эти обновления объединяют классические конвейеры сборки и многоэтапные конвейеры YAML в единый интерфейс. Например, следующие возможности включены в новый интерфейс; просмотр и управление несколькими этапами, утверждение запусков конвейера, возможность прокрутки всего пути обратно в журналах во время выполнения конвейера и работоспособности конвейера на ветвь.
Спасибо всем, кто пробовал новый опыт. Если вы не попробовали его, включите многоэтапные конвейеры в предварительных версиях . Дополнительные сведения о многоэтапных конвейерах см. в документации.
Благодаря вашему отзыву мы рассмотрели следующие два обновления.
- Возможность обнаружения представлений папок.
- Прыжок в представлении журналов.
- Легко отображать журналы из предыдущих и текущих задач, даже если выполняется выполнение.
- Упростить переход между задачами при просмотре журналов.
Примечание.
В следующем обновлении мы планируем включить эту функцию по умолчанию для всех. Вы по-прежнему сможете отказаться от предварительной версии. Через несколько недель после этого функция станет общедоступной.
оркестрация стратегии "канареечного" развертывания в среде для Kubernetes;
Одним из ключевых преимуществ непрерывной доставки обновлений приложений является возможность быстро отправлять обновления в рабочую среду для конкретных микрослужб. Это дает возможность быстро реагировать на изменения бизнес-требований. Среда была представлена в качестве концепции первого класса, которая позволяет оркестрировать стратегии развертывания и упрощать выпуски нулевого времени простоя. Ранее мы поддерживали стратегию runOnce , которая выполняла шаги последовательно. С поддержкой канарной стратегии в многоэтапных конвейерах теперь можно уменьшить риск, медленно развертывая изменение в небольшом подмножестве. По мере повышения уверенности в новой версии вы можете начать развертывание на большее количество серверов в инфраструктуре и направить к нему больше пользователей.
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'
postRouteTraffic:
pool: server
steps:
- script: echo monitor application health...
on:
failure:
steps:
- script: echo clean-up, rollback...
success:
steps:
- script: echo checks passed, notify...
Стратегия канаречного использования Kubernetes сначала развернет изменения с 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. В этом обновлении мы представляем параметр организации, чтобы принудительно принудить каждое задание получить маркер области проекта независимо от того, что настроено в конвейере. Мы также добавили параметр на уровне проекта. Теперь каждый новый проект и организация, которые вы создаете, автоматически включает этот параметр.
Примечание.
Параметр организации переопределяет параметр проекта.
Включение этого параметра в существующих проектах и организациях может привести к сбою определенных конвейеров, если конвейеры получают доступ к ресурсам вне командного проекта с помощью маркеров доступа. Чтобы устранить сбои конвейера, можно явно предоставить учетной записи службы сборки проекта доступ к требуемому ресурсу. Настоятельно рекомендуется включить эти параметры безопасности.
Удаление определенных разрешений для маркера доступа
По умолчанию мы предоставляем ряд разрешений маркеру доступа, одно из этих разрешений — сборки очередей. При этом обновлении мы удалили это разрешение на маркер доступа. Если для конвейеров требуется это разрешение, вы можете явно предоставить его учетной записи службы сборки проекта или учетной записи службы сборки коллекции проектов в зависимости от используемого маркера.
оценка проверки артефактов;
Теперь можно определить набор политик и добавить оценку политики в качестве проверки среды для артефактов образа контейнера. При запуске конвейера выполнение приостанавливается перед началом этапа, использующего среду. Указанная политика вычисляется по доступным метаданным для развернутого образа. Проверка проходит при успешном выполнении политики и помечает этап как сбой, если проверка завершается ошибкой.
поддержка 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 образом.
"канареечные" развертывания на базе Service Mesh Interface в задании KubernetesManifest;
Ранее, когда в задаче KubernetesManifest была указана канарская стратегия, задача создаст базовые и канаровые рабочие нагрузки, реплики которых равны проценту реплик, используемых для стабильных рабочих нагрузок. Это было не совсем так же, как разделение трафика до требуемого процента на уровне запроса. Для решения этой проблемы мы добавили поддержку канарских развертываний на основе интерфейса сетки службы в задачу KubernetesManifest.
Абстракция интерфейса сетки службы позволяет настраивать конфигурацию подключаемых модулей и воспроизведения с поставщиками сетки служб, такими как Компоновщик и 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 в среде.
ReviewApp развертывает каждый запрос на вытягивание из репозитория Git в динамический ресурс среды. Рецензенты могут видеть, как эти изменения выглядят, а также работают с другими зависимыми службами, прежде чем они объединены в основную ветвь и развернуты в рабочей среде. Это позволит вам легко создавать ресурсы 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; Он содержит сведения о настройке клиентов и репозиториев для отправки и извлечения пакетов из веб-каналов в Azure DevOps. Мы обновили диалоговое окно, чтобы добавить подробные сведения о настройке и расширили инструменты, для которые мы предоставляем инструкции.
общедоступная версия открытых веб-каналов с поддержкой вышестоящих источников;
Общедоступная предварительная версия общедоступных веб-каналов получила большое внедрение и отзыв. В этом обновлении мы расширили дополнительные функции для общедоступной доступности. Теперь вы можете настроить общедоступный веб-канал в качестве вышестоящего источника из частного веб-канала. Файлы конфигурации можно сохранить простыми, используя возможность переходить как на частные, так и на веб-каналы с областью проекта.
создание веб-каналов в рамках проекта с помощью портала.
Когда мы выпустили общедоступные веб-каналы, мы также выпустили веб-каналы с областью действия проекта. До сих пор веб-каналы с областью действия проекта можно создавать с помощью REST API или путем создания общедоступного веб-канала, а затем переключив частный проект. Теперь вы можете создавать веб-каналы с областью проекта непосредственно на портале из любого проекта, если у вас есть необходимые разрешения. Вы также можете увидеть, какие веб-каналы являются проектом и которые являются областью действия организации в средство выбора веб-каналов.
Отчетность
Мини-приложение Sprint Burndown со всем, что вы просили
Новое мини-приложение Sprint Burndown поддерживает сжигание по точкам истории, количеству задач или суммированию настраиваемых полей. Вы можете даже создать спринт сгореть для функций или эпических элементов. В мини-приложении отображается среднее число сгора, % завершения и увеличение области. Вы можете настроить команду, позволяя отображать спринты сгорание для нескольких команд на одной панели мониторинга. Со всеми большими сведениями, которые будут отображаться, мы позволяем изменять размер до 10x10 на панели мониторинга.
Чтобы попробовать его, вы можете добавить его из каталога мини-приложений или изменить конфигурацию существующего мини-приложения Sprint Burndown и проверить новую версию.
Примечание.
В новом мини-приложении используется аналитика. Мы сохранили устаревшую версию Sprint Burndown, если у вас нет доступа к Analytics.
Вики
синхронная прокрутка для редактирования вики-страниц;
Редактирование вики-страниц теперь проще с синхронной прокруткой между изменением и панелью предварительного просмотра. Прокрутка на одной стороне автоматически прокрутит другую сторону, чтобы сопоставить соответствующие разделы. Вы можете отключить синхронную прокрутку с помощью кнопки переключателя.
Примечание.
Состояние синхронного переключателя прокрутки сохраняется на пользователя и организацию.
посещения вики-страниц.
Теперь вы можете получить аналитические сведения о посещениях страниц для вики-страниц. REST API позволяет получить доступ к сведениям о посещении страниц за последние 30 дней. Эти данные можно использовать для создания отчетов для вики-страниц. Кроме того, эти данные можно хранить в источнике данных и создавать панели мониторинга для получения конкретных аналитических сведений, таких как top-n наиболее просматриваемых страниц.
Вы также увидите совокупное количество посещений страниц за последние 30 дней на каждой странице.
Примечание.
Посещение страницы определяется как представление страницы определенным пользователем в 15-минутном интервале.
Следующие шаги
Примечание.
Эти функции будут развернуты в течение следующих двух-трех недель.
Перейдите к Azure DevOps и посмотрите.
Отправка отзыва
Мы хотели бы услышать то, что вы думаете об этих функциях. Используйте меню справки, чтобы сообщить о проблеме или указать предложение.
Вы также можете получить советы и ваши вопросы, ответы сообщества на Stack Overflow.
Thanks,
Джефф Билер