Partilhar via

Novo widget de burndown de sprint e segurança de pipelines aprimorada - Atualização do Sprint 160

  • Artigo

Na Atualização do Sprint 160 do Azure DevOps, adicionamos um novo widget de burndown de sprint que oferece suporte à gravação por pontos de história, contagem de tarefas e soma de campos personalizados. Além disso, melhorámos a segurança de pipelines ao restringir o âmbito dos tokens de acesso.

Confira a lista de recursos abaixo para saber mais.

O que há de novo no Azure DevOps

Funcionalidades

Repositórios do Azure:

Azure Pipelines:

Artefactos do Azure:

Relatórios:

Wiki:

Repositórios do Azure

Administração de políticas de ramo de repositório cruzado

As políticas de filial são um dos recursos poderosos do Azure Repos que ajudam a proteger ramificações importantes. Embora a capacidade de definir políticas no nível do projeto exista na API REST, não havia interface de usuário para ela. Agora, os administradores podem definir políticas em uma ramificação específica ou na ramificação 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 pull feitas em cada ramificação principal em cada repositório em seu projeto. Você pode encontrar o recurso Adicionar proteção de ramificação nas Configurações do projeto Repos.

Administração de políticas de recompra cruzada.

Azure Pipelines

Experiência de Utilizador de pipelines com 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 dos pipelines moderna e consistente com a direção do Azure DevOps. Além disso, essas atualizações reúnem pipelines de construção 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; visualização e gerenciamento de vários estágios, aprovação de execuções de pipeline, capacidade de rolar todo o caminho de volta em logs enquanto um pipeline ainda está em andamento e integridade por ramificação de um pipeline.

Obrigado a todos que experimentaram a nova experiência. Se você ainda não experimentou, habilite os pipelines de vários estágios nos recursos de visualização. Para saber mais sobre pipelines de vários estágios, consulte a documentação aqui .

UX de pipelines de vários estágios.

Graças aos seus comentários, abordamos o seguinte nas duas últimas atualizações.

  1. Capacidade de descoberta da visualização de pastas.
  2. Jumpiness na visualização de logs.
  3. Mostre prontamente os logs de tarefas anteriores e atuais, mesmo quando uma execução estiver em andamento.
  4. Facilite a navegação entre tarefas ao revisar logs.

Capacidades incluídas na nova experiência.

Nota

Na próxima atualização, planejamos ativar esse recurso por padrão para todos. Você ainda terá a opção de desativar a visualização. Algumas semanas depois, o recurso estará disponível para o público em geral.

Orquestrar uma estratégia de implementação de proteção no ambiente para o Kubernetes

Uma das principais vantagens da entrega contínua de atualizações de aplicativos é a capacidade de enviar rapidamente atualizações para a produção de microsserviços específicos. Isso lhe dá a capacidade de responder rapidamente às mudanças nos requisitos de negócios. O ambiente foi introduzido como um conceito de primeira classe que permite orquestrar estratégias de implantação e facilitar lançamentos sem tempo de inatividade. Anteriormente, suportamos a estratégia runOnce , que executava as etapas uma vez sequencialmente. Com o suporte para a estratégia canária em pipelines de vários estágios, agora você pode reduzir o risco implementando lentamente a alteração em um pequeno subconjunto. À medida que ganha mais confiança na nova versão, pode começar a implementá-la em mais servidores na sua infraestrutura e encaminhar mais utilizadores para a mesma.

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...

A estratégia canária para Kubernetes implantará primeiro as mudanças com 10% de pods seguidos por 20% enquanto monitora a saúde durante o postRouteTraffic. Se tudo correr bem, vai subir a 100%.

Políticas de aprovação para pipelines YAML

Nos 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 todos os pipelines que usam a pausa do recurso 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 o solicitante da implantação de aprovar 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.

Políticas de aprovação para pipelines YAML.

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 acionar o pipeline sempre que uma nova imagem for publicada, poderá usar o recurso de contêiner 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 da imagem ACR podem ser acessados usando variáveis predefinidas. A lista a seguir inclui as variáveis ACR disponíveis para definir um recurso de contêiner 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 dos 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 oleodutos e recursos ACR

Garantimos total rastreabilidade E2E quando pipelines e recursos de contêineres ACR são usados em um pipeline. Para cada recurso consumido pelo pipeline YAML, você pode rastrear as confirmações, itens de trabalho e artefatos.

No modo de exibição resumo de execução do pipeline, você pode ver:

  • A versão do recurso que disparou a execução. Agora, seu pipeline pode ser acionado 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.

    Versão do recurso que disparou a execução.

  • Os commits que são consumidos pelo pipeline. Você também pode encontrar o detalhamento das confirmações por cada recurso consumido pelo pipeline.

    Confirmações que são consumidas pelo pipeline.

  • Os itens de trabalho associados a cada recurso consumido pelo pipeline.

  • Os artefatos que estão disponíveis para serem usados pela corrida.

    Artefatos que estão disponíveis para serem usados pela corrida.

Na visualização de implantações do ambiente, você pode ver as confirmações e os itens de trabalho para cada recurso implantado no ambiente.

Confirmações e itens de trabalho para cada recurso implantado no ambiente.

Autorização de recursos simplificada nos pipelines YAML

Um recurso é qualquer coisa usada por um pipeline que está fora do pipeline. Os recursos devem ser autorizados antes de poderem ser utilizados. Anteriormente, ao usar recursos não autorizados em um pipeline YAML, ele falhou com um erro de autorização de recurso. Você tinha que autorizar os recursos da página de resumo da execução com falha. Além disso, o pipeline falhava se estivesse 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.

Autorização simplificada de recursos em pipelines YAML.

Melhor segurança de pipelines ao restringir o âmbito dos tokens de acesso

Cada trabalho executado no Azure Pipelines recebe um token de acesso. O token de acesso é usado pelas tarefas e pelos seus 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 para fazer chamadas REST no Azure DevOps. Um novo token de acesso é gerado para cada trabalho e expira quando o trabalho é concluído. Com esta atualização, adicionámos as seguintes melhorias.

  • 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 projeto de equipe. Você pode alterar o escopo para ser o projeto de equipe em pipelines de construção clássicos. No entanto, você não tinha esse controle para pipelines de liberação clássica ou YAML. Com esta atualização, estamos introduzindo uma configuração da organização para forçar cada trabalho a obter um token com escopo de projeto, independentemente do que estiver 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á automaticamente essa configuração ativada.

    Nota

    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 seus pipelines acessarem recursos que estão fora do projeto de equipe usando tokens de acesso. Para atenuar falhas de pipeline, você pode conceder explicitamente à Conta de Serviço de Criação do Projeto acesso ao recurso desejado. Recomendamos vivamente que ative estas definições de segurança.

  • Remover determinadas permissões para o token de acesso

    Por padrão, concedemos várias permissões para o token de acesso, uma dessas permissões é compilações de fila. Com esta atualização, removemos essa permissão para o token de acesso. Se seus pipelines precisarem dessa permissão, você poderá concedê-la explicitamente à Conta de Serviço de Compilação do Project ou à Conta de Serviço de Compilação da Coleção de Projetos, dependendo do token usado.

Avaliar a verificação de artefactos

Agora você pode definir um conjunto de políticas e adicionar a avaliação de política como uma verificação 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. A verificação passa quando a política é bem-sucedida e marca o estágio como falhado se a verificação falhar.

Avalie a verificação de artefatos.

Suporte de markdown nas mensagens de erro dos testes automatizados

Agora suportamos 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 de falha no Azure Pipelines. A sintaxe Markdown suportada pode ser encontrada aqui.

Suporte a Markdown em mensagens de erro de teste automatizado.

Diagnosticar agendas cron no YAML

Temos visto um aumento constante no uso da sintaxe cron para especificar agendas em seus pipelines YAML. Enquanto ouvíamos seus comentários, ouvimos que era difícil para você determinar se o Azure Pipelines havia processado sua sintaxe corretamente. Anteriormente, você teria que esperar 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 lhe darão uma visualização das próximas execuções agendadas para seu pipeline para ajudá-lo a diagnosticar erros com suas agendas cron.

Diagnóstico de horários cron no YAML.

Atualizações para a tarefa de implantação de modelo ARM

Anteriormente, não filtrávamos as conexões de serviço na tarefa de implantação do modelo ARM. Isso pode resultar na falha da implantação se você estiver selecionando uma conexão de serviço de escopo inferior para executar implantações de modelo ARM para um escopo mais amplo. Agora, adicionamos filtragem de conexões de serviço para filtrar conexões de serviço com escopo mais baixo com base no escopo de implantação escolhido.

Segurança ao nível do projeto para ligações de serviço

Com esta atualização, adicionamos segurança em nível de 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.

Segurança em nível de projeto para conexões de serviço.

Conjunto do Ubuntu 18.04

O Azure Pipelines agora suporta a execução de seus trabalhos no Ubuntu 18.04. Atualizamos o pool de Pipelines do Azure hospedado pela Microsoft para incluir a imagem do Ubuntu-18.04. Agora, quando você faz referência ubuntu-latest ao pool em seus pipelines YAML, isso significará ubuntu-18.04 e não ubuntu-16.04. Você ainda pode segmentar imagens 16.04 em seus trabalhos usando ubuntu-16.04 explicitamente.

Implementações baseadas em proteção da Interface de Malha do serviço na tarefa KubernetesManifest

Anteriormente, quando a estratégia canary era especificada na tarefa KubernetesManifest, a tarefa criava cargas de trabalho de linha de base e canary cujas réplicas equivaliam a uma porcentagem das réplicas usadas para cargas de trabalho estáveis. Isso não era exatamente o mesmo que dividir o tráfego até a porcentagem desejada no nível de solicitação. Para resolver isso, adicionamos suporte para implantações canárias baseadas na Interface de Malha de Serviço à tarefa KubernetesManifest.

A abstração da interface de malha de serviço permite a configuração plug-and-play com provedores de malha de serviços, como Linkerd e Istio. Agora, a tarefa KubernetesManifest elimina o trabalho árduo de mapear os objetos TrafficSplit da SMI para os serviços estáveis, de linha de base e canários 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 percentual do tráfego é controlada nas solicitações no plano de malha de serviço.

A seguir está um exemplo de execução de implantações canárias baseadas em SMI de forma 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 pull do seu 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 mesclados na ramificação principal e implantados na produção. Isso facilitará a criação e o gerenciamento de recursos do reviewApp e se beneficiará de toda a capacidade de rastreabilidade e diagnóstico dos recursos do ambiente. Usando a palavra-chave reviewApp , 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.

A seguir está um trecho YAML de exemplo de uso do reviewApp em ambientes.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MasterNamespace

Artefactos do Azure

Experiência de ligação ao feed atualizada

A caixa de diálogo Conectar ao feed é a porta de entrada para usar os Artefatos do Azure; ele contém informações sobre como configurar clientes e repositórios para enviar e extrair pacotes de feeds no Azure DevOps. Atualizámos a caixa de diálogo para adicionar informações detalhadas de configuração e expandimos as ferramentas para as quais damos instruções.

Os feeds públicos estão agora em disponibilidade geral com suporte de origem

A visualização pública de feeds públicos recebeu grande adoção e feedback. Nesta atualização, estendemos recursos adicionais para disponibilidade geral. Agora, você pode definir um feed público como uma fonte upstream de um feed privado. Você pode manter seus arquivos de configuração simples, sendo capaz de upstream de e para feeds privados e com escopo de projeto.

Criar feeds do âmbito do projeto a partir do portal

Quando lançamos feeds públicos, também lançamos feeds com escopo de projeto. Até agora, os feeds com escopo de 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 a partir de qualquer projeto, se tiver as permissões necessárias. Você também pode ver quais feeds são do projeto e quais têm o escopo da organização no seletor de feeds.

Relatórios

Um widget Sprint Burndown com tudo o que você tem pedido

O novo widget Sprint Burndown suporta a gravação por Pontos de História, contagem de Tarefas ou somando campos personalizados. Você pode até criar um burndown de sprint para Recursos ou Épicos. O widget exibe burndown médio, % concluído e aumento de escopo. Você pode configurar a equipe, permitindo que você exiba burndowns de sprint para várias equipes no mesmo painel. Com todas estas fantásticas informações para apresentar, permitimos redimensioná-las até 10x10 no painel de instrumentos.

Widget Sprint Burndown.

Para experimentá-lo, você pode adicioná-lo a partir do catálogo de widgets ou editando a configuração do widget Sprint Burndown existente e marcando a caixa Experimente a nova versão agora .

Nota

O novo widget usa o Analytics. Mantivemos o Sprint Burndown legado caso você não tenha acesso ao Analytics.

Wiki

Deslocamento síncrono para editar páginas wiki

Editar páginas wiki agora é mais fácil com a rolagem síncrona entre o painel de edição e o painel de visualização. Rolar de um lado irá rolar automaticamente o outro lado para mapear as seções correspondentes. Você pode desativar a rolagem síncrona com o botão de alternância.

Rolagem síncrona para edição de páginas wiki.

Nota

O estado da alternância de rolagem síncrona é salvo por usuário e organização.

Visitas para páginas wiki

Agora você pode obter informações sobre as visitas de páginas wiki. A API REST permite que você acesse 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 informações específicas, como as páginas mais visualizadas.

Você também verá uma contagem agregada de visitas à página nos últimos 30 dias em cada página.

Visitas a páginas wiki.

Nota

Uma visita à página é definida como uma visualização de página por um determinado usuário em um intervalo de 15 minutos.

Próximos passos

Nota

Esses recursos serão lançados nas próximas duas a três semanas.

Vá até o Azure DevOps e dê uma olhada.

Ir para Azure DevOps

Como fornecer feedback

Gostaríamos muito de ouvir o que você pensa sobre esses recursos. Use o menu Ajuda para relatar um problema ou fornecer uma sugestão.

Faça uma sugestão

Você também pode obter conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.

Obrigado,

Joaquim Beehler