Compartilhar via

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

  • Artigo

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 soma de campos personalizados. Além disso, melhoramos a segurança dos pipelines restringindo o escopo dos tokens de acesso.

Confira a lista de recursos abaixo para saber mais.

Novidades no Azure DevOps

Recursos

Azure Repos:

Azure Pipelines:

Azure Artifacts:

Emissão de relatórios:

Wiki:

Azure Repos

Administração da política de branch entre repositórios

As políticas de branch são um dos recursos avançados do Azure Repos que ajudam a proteger branches importantes. Embora a capacidade de definir políticas no nível do projeto exista na API REST, não havia 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 principal em cada repositório em seu projeto. Você pode encontrar o recurso Adicionar proteção de branch nas Configurações do Projeto Repos.

Administração de política de branch entre repos.

Azure Pipelines

Experiência do usuário com 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 dos 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; Visualizar e gerenciar vários estágios, aprovar 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 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 ao seu feedback, abordamos o seguinte nas duas últimas atualizações.

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

Recursos incluídos na nova experiência.

Observação

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 disso, o recurso será disponibilizado ao público 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 rapidamente 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 a orquestração de estratégias de implantação e facilita as liberações com tempo de inatividade zero. Anteriormente, dávamos suporte à estratégia runOnce , que executava 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 implementando lentamente a alteração em um pequeno subconjunto. À 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'
      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ário para Kubernetes primeiro implantará as alterações com 10% de pods seguidos por 20% enquanto monitora a integridade durante postRouteTraffic. Se tudo correr bem, será promovido a 100%.

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 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 disparar o pipeline sempre que uma nova imagem for publicada, 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 da imagem 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 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 para pipelines e recursos ACR

Garantimos a rastreabilidade total do E2E quando pipelines e recursos de contêiner 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.

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.

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

  • As confirmações que são consumidas 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 execução.

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

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

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

Autorização de recursos simplificada 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ê 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 de recursos simplificada em pipelines YAML.

Melhoria da segurança dos pipelines 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 por 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 fazer chamadas REST para Azure DevOps. Um novo token de acesso é gerado para cada trabalho e expira quando o trabalho é concluído. Com esta 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 pipelines de versão clássica ou 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 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á 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 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 acesso à Conta de Serviço de Build do Project ao 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 dessas 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 Project ou à Conta de Serviço de Build da Coleção de Projetos, dependendo do token usado.

Avaliar verificação de artefato

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 é aprovada quando a política é bem-sucedida e marca o estágio como reprovado se a verificação falhar.

Avalie a verificação de artefatos.

Suporte de markdown em mensagens de erro de teste automatizado

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

Suporte a Markdown em mensagens de erro de teste automatizadas.

Diagnosticar agendas de cron no YAML

Vimos um aumento constante no uso da sintaxe cron para especificar agendamentos em seus pipelines YAML. Ao ouvirmos 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 a hora 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 o pipeline para ajudá-lo a diagnosticar erros com seus agendamentos cron.

Diagnosticando agendas cron no YAML.

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

Anteriormente, não filtrávamos as conexões de serviço na tarefa de implantação do modelo do 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 do ARM em um escopo mais amplo. Agora, adicionamos 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 em nível de 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.

Segurança no nível do projeto para 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 do Ubuntu-18.04. Agora, quando você fizer referência ao ubuntu-latest pool em seus pipelines YAML, isso significará ubuntu-18.04 e não ubuntu-16.04. Você ainda pode direcionar imagens 16.04 em seus trabalhos usando ubuntu-16.04 explicitamente.

Implantações canário baseadas na interface da malha do 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 era 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ário baseadas na Interface do Service Mesh à tarefa KubernetesManifest.

A abstração da interface do Service Mesh permite a configuração plug-and-play com provedores de service mesh, como Linkerd e Istio. Agora, a tarefa KubernetesManifest elimina o trabalho árduo de mapear os objetos TrafficSplit do 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.

Veja a seguir um exemplo de execução de implantações canário 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 todas as solicitações 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 mesclados no branch 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.

Veja a seguir um exemplo de snippet YAML do 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

Experiência Conectar-se ao feed atualizada

A caixa de diálogo Conectar ao feed é a entrada para usar o Azure Artifacts; ele contém informações sobre como configurar clientes e repositórios para enviar e receber pacotes 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 quais damos instruções.

Os feeds públicos já estão em disponibilidade geral com suporte ao upstream

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 fazer upstream de e para feeds privados e no escopo do projeto.

Crie feeds com o escopo do projeto no 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 no escopo do projeto diretamente no portal de qualquer projeto se tiver as permissões necessárias. Você também pode ver quais feeds são de projeto e quais estão no escopo da organização no seletor de feeds.

Relatório

Um widget de Burndown do Sprint com tudo o que você está pedindo

O novo widget Sprint Burndown dá suporte à queima por Story Points, contagem de tarefas ou soma de campos personalizados. Você pode até mesmo criar um burndown de sprint para Recursos ou Épicos. O widget exibe burndown médio, % concluída 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 essas ótimas informações para exibir, permitimos que você redimensione até 10x10 no painel.

Widget Burndown do Sprint.

Para experimentá-lo, você pode adicioná-lo do catálogo de widgets ou editando a configuração do widget Sprint Burndown existente 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 editar páginas do wiki

A edição de páginas wiki agora é mais fácil com a rolagem síncrona entre o painel de edição e visualização. A rolagem de um lado 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.

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 n páginas mais visualizadas.

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

Visitas à página para páginas wiki.

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 lançados nas próximas duas a três semanas.

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

Ir para o Azure DevOps

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.

Fazer uma sugestão

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

Obrigada,

Jeff Beehler