Novo widget de burndown de sprint e segurança de pipelines aprimorada – Atualização do Sprint 160
Na Atualização do Sprint 160 do Azure DevOps, adicionamos um novo widget de burndown de sprint que dá suporte à queima por pontos de história, contagem de tarefas e somando campos personalizados. Além disso, melhoramos a segurança de pipelines restringindo o escopo dos tokens de acesso.
Confira a lista Recursos abaixo para obter mais informações.
Novidades no Azure DevOps
Recursos
Azure Repos:
Azure Pipelines:
- UX de pipelines de vários estágios
- Orquestrar a estratégia de implantação canário no ambiente para Kubernetes
- Políticas de aprovação para pipelines YAML
- ACR como um recurso de pipeline de primeira classe
- Metadados de recursos de pipeline como variáveis predefinidas
- Rastreabilidade de pipelines e recursos do ACR
- Autorização simplificada de recursos em pipelines YAML
- Melhorar a segurança do pipeline restringindo o escopo dos tokens de acesso
- Avaliar marcar de artefato
- Suporte a Markdown em mensagens de erro de teste automatizadas
- Diagnosticando agendas cron no YAML
- Atualizações à tarefa de implantação de modelo do ARM
- Segurança em nível de projeto para conexões de serviço
- Pool do Ubuntu 18.04
- Implantações canário baseadas na Interface de Malha de Serviço na tarefa KubernetesManifest
- ReviewApp in Environment
Azure Artifacts:
- Atualização da experiência conectar-se ao feed
- Os feeds públicos agora estão em disponibilidade geral com suporte upstream
- Criar feeds no escopo do projeto por meio do portal
Emissão de relatórios:
Wiki:
Azure Repos
Administração de política de branch entre repositórios
As políticas de branch são um dos recursos avançados do Azure Repos que ajudam você a proteger branches importantes. Embora a capacidade de definir políticas no nível do projeto exista na API REST, não havia nenhuma interface do usuário para ela. Agora, os administradores podem definir políticas em um branch específico ou no branch padrão em todos os repositórios em seu projeto. Por exemplo, um administrador pode exigir dois revisores mínimos para todas as solicitações de pull feitas em cada branch main em cada repositório em seu projeto. Você pode encontrar o recurso Adicionar proteção de branch nas Configurações do Projeto do Repos.
Azure Pipelines
UX de pipelines de vários estágios
Estamos trabalhando em uma experiência de usuário atualizada para gerenciar seus pipelines. Essas atualizações tornam a experiência de pipelines moderna e consistente com a direção do Azure DevOps. Além disso, essas atualizações reúnem pipelines de build clássicos e pipelines YAML de vários estágios em uma única experiência. Por exemplo, os seguintes recursos estão incluídos na nova experiência; exibição e gerenciamento de vários estágios, aprovação de execuções de pipeline, capacidade de rolar todo o caminho de volta nos logs enquanto um pipeline ainda está em andamento e integridade por branch de um pipeline.
Obrigado a todos que experimentaram a nova experiência. Se você ainda não experimentou, habilite pipelines de vários estágios nos recursos de versão prévia. Para saber mais sobre pipelines de vários estágios, consulte a documentação aqui .
Graças aos seus comentários, abordamos o seguinte nas duas últimas atualizações.
- Detectabilidade da exibição de pastas.
- Jumpiness na exibição de logs.
- Mostre prontamente os logs das tarefas anteriores e atuais, mesmo quando uma execução estiver em andamento.
- Facilite a navegação entre tarefas ao revisar logs.
Observação
Na próxima atualização, planejamos ativar esse recurso por padrão para todos. Você ainda terá a opção de recusar a versão prévia. Algumas semanas depois disso, o recurso será disponibilizado em geral.
Orquestrar a estratégia de implantação canário no ambiente para Kubernetes
Uma das principais vantagens da entrega contínua de atualizações de aplicativos é a capacidade de enviar atualizações por push rapidamente para produção para microsserviços específicos. Isso oferece a capacidade de responder rapidamente às alterações nos requisitos de negócios. O ambiente foi introduzido como um conceito de primeira classe, permitindo a orquestração de estratégias de implantação e facilitando versões de tempo de inatividade zero. Anteriormente, damos suporte à estratégia runOnce , que executou as etapas uma vez sequencialmente. Com suporte para estratégia canário em pipelines de vários estágios, agora você pode reduzir o risco distribuindo lentamente a alteração para um subconjunto pequeno. À medida que você ganha mais confiança na nova versão, pode começar a distribuí-la para mais servidores em sua infraestrutura e rotear mais usuários para ela.
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...
A estratégia canário para Kuberenetes implantará primeiro as alterações com 10% de pods seguidos por 20% enquanto monitora a integridade durante postRouteTraffic. Se tudo correr bem, promoverá para 100%.
Estamos procurando comentários antecipados sobre o suporte para o recurso de VM em ambientes e a execução da estratégia de implantação sem interrupção em vários computadores. Entre em contato conosco para se inscrever.
Políticas de aprovação para pipelines YAML
Em pipelines YAML, seguimos uma configuração de aprovação controlada pelo proprietário do recurso. Os proprietários de recursos configuram aprovações no recurso e em todos os pipelines que usam a pausa de recursos para aprovações antes do início do estágio que consome o recurso. É comum que os proprietários de aplicativos baseados em SOX restrinjam que o solicitante da implantação aprove suas próprias implantações.
Agora você pode usar opções avançadas de aprovação para configurar políticas de aprovação, como o solicitante não deve aprovar, exigir aprovação de um subconjunto de usuários e tempo limite de aprovação.
ACR como um recurso de pipeline de primeira classe
Se você precisar consumir uma imagem de contêiner publicada no ACR (Registro de Contêiner do Azure) como parte do pipeline e disparar o pipeline sempre que uma nova imagem for publicada, você poderá usar o recurso de contêiner do 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
Além disso, os metadados de imagem do ACR podem ser acessados usando variáveis predefinidas. A lista a seguir inclui as variáveis do ACR disponíveis para definir um recurso de contêiner do ACR em seu pipeline.
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
Metadados de recursos de pipeline como variáveis predefinidas
Adicionamos variáveis predefinidas para recursos de pipelines YAML no pipeline. Aqui está a lista das variáveis de recurso de pipeline disponíveis.
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
Rastreabilidade de pipelines e recursos do ACR
Garantimos a rastreabilidade completa do E2E quando pipelines e recursos de contêiner do ACR são usados em um pipeline. Para cada recurso consumido pelo pipeline yaml, você pode rastrear de volta para confirmações, itens de trabalho e artefatos.
Na exibição de resumo da execução do pipeline, você pode ver:
A versão do recurso que disparou a execução. Agora, seu pipeline pode ser disparado após a conclusão de outra execução de pipeline do Azure ou quando uma imagem de contêiner é enviada por push para o ACR.
Os commits que são consumidos pelo pipeline. Você também pode encontrar o detalhamento das confirmações por cada recurso consumido pelo pipeline.
Os itens de trabalho associados a cada recurso consumido pelo pipeline.
Os artefatos que estão disponíveis para serem usados pela execução.
Na exibição de implantações do ambiente, você pode ver os commits e os itens de trabalho para cada recurso implantado no ambiente.
Autorização simplificada de recursos em pipelines YAML
Um recurso é qualquer coisa usada por um pipeline que está fora do pipeline. Os recursos devem ser autorizados para que possam ser usados. Anteriormente, ao usar recursos não autorizados em um pipeline yaml, ele falhava com um erro de autorização de recurso. Você teve que autorizar os recursos da página de resumo da execução com falha. Além disso, o pipeline falhou se ele estava usando uma variável que fazia referência a um recurso não autorizado.
Agora estamos facilitando o gerenciamento de autorizações de recursos. Em vez de falhar na execução, a execução aguardará permissões nos recursos no início do estágio que consome o recurso. Um proprietário de recurso pode exibir o pipeline e autorizar o recurso na página Segurança.
Melhorar a segurança do pipeline restringindo o escopo dos tokens de acesso
Cada trabalho executado no Azure Pipelines obtém um token de acesso. O token de acesso é usado pelas tarefas e pelos scripts para chamar de volta para o Azure DevOps. Por exemplo, usamos o token de acesso para obter código-fonte, carregar logs, resultados de teste, artefatos ou fazer chamadas REST no Azure DevOps. Um novo token de acesso é gerado para cada trabalho e expira quando o trabalho é concluído. Com essa atualização, adicionamos os seguintes aprimoramentos.
Impedir que o token acesse recursos fora de um projeto de equipe
Até agora, o escopo padrão de todos os pipelines era a coleção de projetos de equipe. Você pode alterar o escopo para ser o projeto de equipe em pipelines de build clássicos. No entanto, você não tinha esse controle para a versão clássica ou pipelines YAML. Com essa atualização, estamos introduzindo uma configuração de organização para forçar cada trabalho a obter um token no escopo do projeto, independentemente do que esteja configurado no pipeline. Também adicionamos a configuração no nível do projeto. Agora, cada novo projeto e organização que você criar terá essa configuração ativada automaticamente.
Observação
A configuração da organização substitui a configuração do projeto.
Ativar essa configuração em projetos e organizações existentes pode fazer com que determinados pipelines falhem se os pipelines acessarem recursos que estão fora do projeto de equipe usando tokens de acesso. Para atenuar falhas de pipeline, você pode conceder explicitamente acesso à Conta de Serviço de Build do Project para o recurso desejado. É altamente recomendável que você ative essas configurações de segurança.
Remover determinadas permissões para o token de acesso
Por padrão, concedemos várias permissões ao token de acesso, uma destas permissões é Compilações de fila. Com essa atualização, removemos essa permissão para o token de acesso. Se os pipelines precisarem dessa permissão, você poderá concedê-la explicitamente à Conta de Serviço de Build do Projeto ou à Conta de Serviço de Build de Coleção de Projetos , dependendo do token usado.
Avaliar marcar de artefato
Agora você pode definir um conjunto de políticas e adicionar a avaliação de política como um marcar em um ambiente para artefatos de imagem de contêiner. Quando um pipeline é executado, a execução é pausada antes de iniciar um estágio que usa o ambiente. A política especificada é avaliada em relação aos metadados disponíveis para a imagem que está sendo implantada. O marcar passa quando a política é bem-sucedida e marca o estágio como com falha se o marcar falhar.
Suporte ao Markdown em mensagens de erro de teste automatizadas
Agora damos suporte ao Markdown em mensagens de erro para testes automatizados. Você pode formatar facilmente mensagens de erro para execução de teste e resultado de teste para melhorar a legibilidade e facilitar a solução de problemas da falha no Azure Pipelines. A sintaxe markdown com suporte pode ser encontrada aqui.
Diagnosticar agendamentos cron no YAML
Vimos um aumento constante no uso da sintaxe cron para especificar agendamentos em seus pipelines YAML. Enquanto ouvimos seus comentários, ouvimos que era difícil para você determinar se o Azure Pipelines havia processado sua sintaxe corretamente. Anteriormente, você teria que aguardar o tempo real da execução agendada para depurar problemas de agendamento. Para ajudá-lo a diagnosticar erros de ramificação/sintaxe, adicionamos um novo menu de ação para pipeline. As execuções agendadas no menu Executar pipeline fornecerão uma visualização das próximas execuções agendadas para seu pipeline para ajudá-lo a diagnosticar erros com seus agendamentos cron.
Atualizações para a tarefa de implantação de modelo do ARM
Anteriormente, não filtramos as conexões de serviço na tarefa de implantação de modelo do ARM. Isso poderá fazer com que a implantação falhe se você estiver selecionando uma conexão de serviço de escopo inferior para executar implantações de modelo do ARM em um escopo mais amplo. Agora, adicionamos a filtragem de conexões de serviço para filtrar conexões de serviço com escopo inferior com base no escopo de implantação escolhido.
Segurança no nível do projeto para conexões de serviço
Com essa atualização, adicionamos segurança no nível do hub para conexões de serviço. Agora, você pode adicionar/remover usuários, atribuir funções e gerenciar o acesso em um local centralizado para todas as conexões de serviço.
Pool do Ubuntu 18.04
O Azure Pipelines agora dá suporte à execução de seus trabalhos no Ubuntu 18.04. Atualizamos o pool do Azure Pipelines hospedado pela Microsoft para incluir a imagem Ubuntu-18.04. Agora, quando você referencia ubuntu-latest o pool em seus pipelines YAML, isso significará ubuntu-18.04 e não ubuntu-16.04. Você ainda pode direcionar 16,04 imagens em seus trabalhos usando ubuntu-16.04 explicitamente.
Implantações canárias baseadas na Interface de Malha de Serviço na tarefa KubernetesManifest
Anteriormente, quando a estratégia canário era especificada na tarefa KubernetesManifest, a tarefa criava cargas de trabalho de linha de base e canário cujas réplicas eram iguais a uma porcentagem das réplicas usadas para cargas de trabalho estáveis. Isso não foi exatamente o mesmo que dividir o tráfego até a porcentagem desejada no nível da solicitação. Para resolver isso, adicionamos suporte para implantações canárias baseadas em Interface de Malha de Serviço à tarefa KubernetesManifest.
A abstração da Interface de Malha de Serviço permite a configuração de plug-and-play com provedores de malha de serviço, como Linkerd e Istio. Agora, a tarefa KubernetesManifest tira o trabalho árduo de mapear objetos TrafficSplit do SMI para os serviços estáveis, de linha de base e canário durante o ciclo de vida da estratégia de implantação. A divisão percentual desejada do tráfego entre estável, linha de base e canário é mais precisa, pois a divisão de tráfego percentual é controlada nas solicitações no plano de malha de serviço.
Veja a seguir um exemplo de execução de implantações canárias baseadas em SMI de maneira contínua.
- 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 no Ambiente
O ReviewApp implanta cada solicitação de pull do repositório Git em um recurso de ambiente dinâmico. Os revisores podem ver a aparência dessas alterações, bem como trabalhar com outros serviços dependentes antes de serem mescladas no branch main e implantadas na produção. Isso facilitará a criação e o gerenciamento de revisõesAplicativos de aplicativo e se beneficiará de todos os recursos de rastreamento e diagnóstico dos recursos de ambiente. Usando o reviewApp palavra-chave, você pode criar um clone de um recurso (criar dinamicamente um novo recurso com base em um recurso existente em um ambiente) e adicionar o novo recurso ao ambiente.
Veja a seguir um snippet yaml de exemplo de uso de reviewApp em ambientes.
jobs:
- deployment:
environment:
name: smarthotel-dev
resourceName: $(System.PullRequest.PullRequestId)
pool:
name: 'ubuntu-latest'
strategy:
runOnce:
pre-deploy:
steps:
- reviewApp: MasterNamespace
Azure Artifacts
Atualização da experiência conectar-se ao feed
A caixa de diálogo Conectar-se ao feed é a entrada para usar o Azure Artifacts; ele contém informações sobre como configurar clientes e repositórios para enviar pacotes por push e pull de feeds no Azure DevOps. Atualizamos a caixa de diálogo para adicionar informações detalhadas de configuração e expandimos as ferramentas para as qual fornecemos instruções.
Os feeds públicos agora estão em disponibilidade geral com suporte upstream
A visualização pública dos feeds públicos recebeu ótima adoção e comentários. Nesta atualização, estendemos recursos adicionais à disponibilidade geral. Agora, você pode definir um feed público como uma fonte de upstream de um feed privado. Você pode manter seus arquivos de configuração simples, podendo upstream de e para feeds privados e com escopo de projeto.
Criar feeds no escopo do projeto do portal
Quando lançamos feeds públicos, também lançamos feeds no escopo do projeto. Até agora, os feeds no escopo do projeto podiam ser criados por meio de APIs REST ou criando um feed público e, em seguida, tornando o projeto privado. Agora, você pode criar feeds com escopo de projeto diretamente no portal de qualquer projeto se tiver as permissões necessárias. Você também pode ver quais feeds são projeto e quais têm escopo de organização no seletor de feed.
Relatórios
Um widget do Sprint Burndown com tudo o que você tem pedido
O novo widget Sprint Burndown dá suporte à queima por Pontos de História, contagem de Tarefas ou somando campos personalizados. Você pode até mesmo criar um burndown de sprint para Recursos ou Epics. O widget exibe burndown médio, % concluído e aumento de escopo. Você pode configurar a equipe, permitindo exibir burndowns de sprint para várias equipes no mesmo dashboard. Com todas essas ótimas informações a serem exibidas, permitimos redimensioná-la até 10x10 no dashboard.
Para experimentá-lo, você pode adicioná-lo do catálogo de widgets ou editando a configuração do widget existente do Sprint Burndown e marcando a caixa Experimentar a nova versão agora .
Observação
O novo widget usa o Analytics. Mantivemos o Sprint Burndown herdado caso você não tenha acesso ao Analytics.
Wiki
Rolagem síncrona para edição de páginas wiki
A edição de páginas wiki agora é mais fácil com a rolagem síncrona entre a edição e o painel de visualização. Rolar de um lado rolará automaticamente o outro lado para mapear as seções correspondentes. Você pode desabilitar a rolagem síncrona com o botão de alternância.
Observação
O estado da alternância de rolagem síncrona é salvo por usuário e organização.
Visitas de página para páginas wiki
Agora você pode obter informações sobre as visitas à página para páginas wiki. A API REST permite acessar as informações de visitas à página nos últimos 30 dias. Você pode usar esses dados para criar relatórios para suas páginas wiki. Além disso, você pode armazenar esses dados em sua fonte de dados e criar painéis para obter insights específicos, como as páginas mais exibidas.
Você também verá uma contagem de visitas de página agregada para os últimos 30 dias em cada página.
Observação
Uma visita de página é definida como uma exibição de página por um determinado usuário em um intervalo de 15 minutos.
Próximas etapas
Observação
Esses recursos serão distribuídos nas próximas duas a três semanas.
Acesse o Azure DevOps e dê uma olhada.
Como fornecer comentários
Adoraríamos ouvir o que você pensa sobre esses recursos. Use o menu de ajuda para relatar um problema ou fornecer uma sugestão.
Você também pode obter conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.
Obrigada,
Jeff Beehler
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de