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

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:

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

Azure Pipelines:

• Experiência de Utilizador de pipelines com vários estágios
• Orquestrar uma estratégia de implementação canário no ambiente de Kubernetes
• Políticas de aprovação para pipelines YAML
• ACR como um recurso de pipeline de primeira classe
• Metadados dos recursos de pipeline como variáveis predefinidas
• Rastreabilidade de oleodutos e recursos ACR
• Autorização de recursos simplificada nos pipelines YAML
• Melhore a segurança dos pipelines restringindo o âmbito dos tokens de acesso
• Avaliar a inspeção de artefactos
• Suporte de markdown nas mensagens de erro dos testes automatizados
• Diagnosticar agendas cron no YAML
• Atualizações para a tarefa de implantação de modelo ARM
• Segurança ao nível do projeto para ligações de serviço
• Pool do Ubuntu 18.04
• Implementações canárias baseadas na Interface de Malha de Serviço na tarefa KubernetesManifest
• ReviewApp no Ambiente

Artefactos do Azure:

• Experiência de ligação ao feed atualizada
• Os feeds públicos estão agora em disponibilidade geral com suporte de origem
• Criar feeds com abrangência de projeto no portal

Relatórios:

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

Wiki:

• Deslocamento síncrono para editar páginas wiki
• Visitas a páginas wiki

Repositórios do Azure

Administração de políticas de ramo entre repositórios

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.

Azure Pipelines (Pipelines do Azure)

Experiência do Utilizador em Pipelines de Dados 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 retroceder nos logs completamente enquanto um pipeline ainda está em andamento e verificar o estado de saúde de um pipeline por ramo.

Obrigado a todos que experimentaram a nova experiência. Se ainda não experimentaste, habilita pipelines multiestágio nas funcionalidades de pré-visualização. 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.

1. Capacidade de descoberta da visualização de pastas.
2. Instabilidade na visualização de registos.
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.

Orquestrar uma estratégia de implementação em canário 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á as alterações primeiro com 10% dos pods, seguidos por 20%, enquanto monitoriza a saúde durante 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 utilizam o recurso são pausados 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.

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

Adicionámos variáveis predefinidas para recursos de pipelines YAML nos pipelines. Aqui está a lista das variáveis dos recursos do 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 visualização do resumo de execução do pipeline, é possível 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.

  

• Os commits que são consumidos pelo pipeline. Você também pode encontrar o detalhamento dos commits por 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 visualização de implantações do ambiente, você pode ver as confirmações e os 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 a execução, a execução aguardará permissões nos recursos no início da etapa de consumir o recurso. Um proprietário de recurso pode exibir o pipeline e autorizar o recurso na página Segurança.

Melhorar a segurança dos pipelines restringindo 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 projetos de equipa. 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 a introduzir uma definição na organização para garantir que cada tarefa obtenha um token em âmbito de 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á automaticamente essa configuração ativada.

  Nota

  A configuração da organização substitui a configuração do projeto.

  Ativar esta configuração em projetos e organizações existentes pode fazer com que determinados pipelines falhem se, usando tokens de acesso, os seus pipelines acederem a recursos que estão fora do projeto da equipa. Para atenuar falhas de pipeline, pode conceder explicitamente acesso de Conta de Serviço de Criação do Projeto 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 os seus pipelines precisarem desta permissão, pode concedê-la explicitamente à Conta de Serviço de Compilação do Projeto ou à Conta de Serviço de Compilação da Coleção de Projetos, dependendo do token que utilizar.

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.

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.

Diagnóstico de tarefas cron no YAML

Temos observado um aumento constante no uso da sintaxe cron para especificar agendas nos 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.

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.

Repositório 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 de canário baseadas na Interface de Malha de Serviço na tarefa KubernetesManifest

Anteriormente, quando a estratégia de canário era especificada na tarefa KubernetesManifest, a tarefa criava cargas de trabalho de referência e de canário cujas réplicas equivaliam a uma porcentagem das réplicas utilizadas para as cargas de trabalho estáveis. Isso não era exatamente o mesmo que distribuir o tráfego na porcentagem desejada ao nível da solicitação. Para abordar isso, adicionamos suporte para Service Mesh Interface em implantações canárias na 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, base e canário é mais precisa, pois essa divisão é controlada pelas 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 visualizar essas alterações e trabalhar com outros serviços dependentes antes de serem integrados ao ramo principal e implantados em produção. Isso facilitará a criação e o gerenciamento de recursos do reviewApp para que possa beneficiar-se de toda a capacidade de rastreabilidade e diagnóstico das funcionalidades 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: MainNamespace

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 geralmente disponíveis com suporte upstream

A pré-visualização pública dos feeds públicos foi amplamente adotada e recebeu avaliações positivas. Nesta atualização, expandimos recursos adicionais para utilização geral. Agora, você pode definir um feed público como uma fonte upstream de um feed privado. Você pode simplificar seus arquivos de configuração, tendo a capacidade de enviar e receber dados de feeds privados e feeds 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 redução por Pontos de Estória, contagem de Tarefas ou pela soma de 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.

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 .

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

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.

Próximos passos

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

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.

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

Obrigado,

Joaquim Beehler