Criar um dashboard sem uma equipe – Atualização do Sprint 162

Na Atualização do Sprint 162 do Azure DevOps, estamos felizes em anunciar que você pode criar uma dashboard sem associá-la a uma equipe. O dashboard ficará visível para todos no projeto e você poderá decidir quem pode editá-lo/gerenciá-lo.

Além disso, adicionamos a miniatura de burndown de sprint. Agora você pode configurá-lo para burndown com base em histórias, pontos de história ou por contagem de tarefas.

Confira a lista Recursos abaixo para obter mais informações.

Recursos

Azure Repos:

• Novas páginas de aterrissagem de conversão da plataforma Web
• Suporte para a linguagem Kotlin

Azure Pipelines:

• Interface do usuário de pipelines de vários estágios atualizada
• A opção TestResultsDirectory do VSTest está disponível na interface do usuário da tarefa
• O uso estende palavra-chave em pipelines
• Suporte a Markdown em mensagens de erro de teste automatizadas
• Coletar metadados automáticos e especificados pelo usuário do pipeline
• Atualizações à interface do usuário de conexões de serviço
• Implantações de VM com ambientes
• Ignorando estágios em um pipeline YAML

Emissão de relatórios:

• Miniatura de burndown de sprint embutido
• Criar um dashboard sem uma equipe

Azure Repos

Novas páginas de aterrissagem de conversão da plataforma Web

Atualizamos a experiência do usuário das páginas de aterrissagem do Repos para torná-la moderna, rápida e amigável para dispositivos móveis. Aqui estão dois exemplos das páginas que foram atualizadas, continuaremos a atualizar outras páginas em atualizações futuras.

Experiência na Web:

Experiência móvel:

Suporte para a linguagem Kotlin

Estamos felizes em anunciar que agora damos suporte ao realce da linguagem Kotlin no editor de arquivos. Realçar melhorará a legibilidade do arquivo de texto Kotlin e ajudará você a verificar rapidamente para encontrar erros. Priorizamos esse recurso com base em uma sugestão do Developer Community.

Azure Pipelines

Interface do usuário de pipelines de vários estágios atualizada

Uma versão atualizada da interface do usuário de pipelines de vários estágios agora está disponível por padrão. A experiência de pipelines de vários estágios traz melhorias e facilidade de uso para a interface do usuário do portal do pipeline. Você pode exibir e gerenciar seus pipelines escolhendo Pipelines no menu à esquerda. Além disso, você pode fazer drill down e exibir detalhes do pipeline, detalhes da execução, análise de pipeline, detalhes do trabalho, logs e muito mais.

Para saber mais sobre a experiência do usuário de pipelines de vários estágios, consulte a documentação aqui.

A opção TestResultsDirectory do VSTest está disponível na interface do usuário da tarefa

A tarefa VSTest armazena resultados de teste e arquivos associados na $(Agent.TempDirectory)\TestResults pasta . Adicionamos uma opção à interface do usuário da tarefa para permitir que você configure uma pasta diferente para armazenar os resultados do teste. Agora, todas as tarefas subsequentes que precisam dos arquivos em um local específico podem usá-las.

O uso estende palavra-chave em pipelines

Atualmente, os pipelines podem ser fatorados em modelos, promovendo a reutilização e reduzindo o texto clichê. A estrutura geral do pipeline ainda foi definida pelo arquivo YAML raiz. Com essa atualização, adicionamos uma maneira mais estruturada de usar modelos de pipeline. Um arquivo YAML raiz agora pode usar o palavra-chave estende para indicar que a estrutura do pipeline main pode ser encontrada em outro arquivo. Isso coloca você no controle de quais segmentos podem ser estendidos ou alterados e quais segmentos são fixos. Também aprimoramos os parâmetros de pipeline com tipos de dados para deixar claro os ganchos que você pode fornecer.

Este exemplo ilustra como você pode fornecer ganchos simples para o autor do pipeline usar. O modelo sempre executará um build, executará opcionalmente etapas adicionais fornecidas pelo pipeline e, em seguida, executará uma etapa de teste opcional.

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

Suporte a Markdown em mensagens de erro de teste automatizadas

Adicionamos suporte ao Markdown a mensagens de erro para testes automatizados. Agora você pode formatar facilmente mensagens de erro para execução de teste e resultado de teste para melhorar a legibilidade e facilitar a experiência de solução de problemas de falha de teste no Azure Pipelines. A sintaxe markdown com suporte pode ser encontrada aqui.

Coletar metadados automáticos e especificados pelo usuário do pipeline

Agora você pode habilitar a coleta de metadados automática e especificada pelo usuário de tarefas de pipeline. Você pode usar metadados para impor a política de artefato em um ambiente usando o artefato de avaliação marcar.

Atualizações à interface do usuário de conexões de serviço

Estamos trabalhando em uma experiência de usuário atualizada para gerenciar suas conexões de serviço. Essas atualizações tornam a experiência de conexão de serviço moderna e consistente com a direção do Azure DevOps. Apresentamos a nova interface do usuário para conexões de serviço como uma versão prévia do recurso no início deste ano. Obrigado a todos que experimentaram a nova experiência e forneceram seus comentários valiosos para nós.

Juntamente com a atualização da experiência do usuário, também adicionamos dois recursos que são essenciais para o consumo de conexões de serviço em pipelines YAML: autorizações e aprovações e verificações de pipeline.

A nova experiência do usuário será ativada por padrão com essa atualização. Você ainda terá a opção de recusar a versão prévia.

Observação

Planejamos introduzir o Compartilhamento entre projetos de Conexões de Serviço como uma nova funcionalidade. Você pode encontrar mais detalhes sobre a experiência de compartilhamento e as funções de segurança aqui.

Implantações de VM com ambientes

Um dos recursos mais solicitados em Ambientes foram as implantações de VM. Com essa atualização, estamos habilitando o recurso de Máquina Virtual em Ambientes. Agora você pode orquestrar implantações em vários computadores e executar atualizações sem interrupção usando pipelines YAML. Você também pode instalar o agente em cada um dos servidores de destino diretamente e conduzir a implantação sem interrupção para esses servidores. Além disso, você pode usar o catálogo de tarefas completo em seus computadores de destino.

Uma implantação sem interrupção substitui instâncias da versão anterior de um aplicativo por instâncias da nova versão do aplicativo em um conjunto de computadores (conjunto sem interrupção) em cada iteração.

Por exemplo, a implantação sem interrupção abaixo atualiza até cinco destinos em cada iteração. maxParallel determinará o número de destinos que podem ser implantados em paralelo. A seleção é responsável pelo número de destinos que devem permanecer disponíveis a qualquer momento, excluindo os destinos que estão sendo implantados. Ele também é usado para determinar as condições de êxito e falha durante a implantação.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTraffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Observação

Com essa atualização, todos os artefatos disponíveis do pipeline atual e dos recursos de pipeline associados são baixados apenas no deploy gancho de ciclo de vida. No entanto, você pode optar por baixar especificando a tarefa Baixar Artefato do Pipeline. Há algumas lacunas conhecidas nesse recurso. Por exemplo, quando você tentar novamente uma fase, ele executará novamente a implantação em todas as VMs, não apenas em destinos com falha. Estamos trabalhando para fechar essas lacunas em atualizações futuras.

Ignorando estágios em um pipeline YAML

Ao iniciar uma execução manual, às vezes, convém ignorar alguns estágios em seu pipeline. Por exemplo, se você não quiser implantar na produção ou se quiser ignorar a implantação em alguns ambientes em produção. Agora você pode fazer isso com seus pipelines YAML.

O painel de pipeline de execução atualizado apresenta uma lista de estágios do arquivo YAML e você tem a opção de ignorar um ou mais desses estágios. Você deve ter cuidado ao ignorar estágios. Por exemplo, se o primeiro estágio produzir determinados artefatos necessários para estágios subsequentes, você não deverá ignorar o primeiro estágio. O painel de execução apresenta um aviso genérico sempre que você ignora estágios que têm dependências downstream. Cabe a você saber se essas dependências são verdadeiras dependências de artefato ou se elas estão apenas presentes para sequenciamento de implantações.

Ignorar um estágio é equivalente a religar as dependências entre estágios. Todas as dependências downstream imediatas do estágio ignorado são feitas para depender do upstream pai do estágio ignorado. Se a execução falhar e se você tentar executar novamente um estágio com falha, essa tentativa também terá o mesmo comportamento de ignorar. Para alterar quais estágios são ignorados, você precisa iniciar uma nova execução.

Relatórios

Miniatura de burndown de sprint embutido

O Sprint Burndown está de volta! Há alguns sprints, removemos o burndown de sprint no contexto dos cabeçalhos Burndown e Taskboard do Sprint. Com base em seus comentários, melhoramos e reintroduzimos a miniatura do sprint burndown.

Clicar na miniatura exibirá imediatamente uma versão maior do gráfico com uma opção para exibir o relatório completo na guia Análise. Todas as alterações feitas no relatório completo serão refletidas no gráfico exibido no cabeçalho . Portanto, agora você pode configurá-lo para burndown com base em histórias, pontos de história ou por contagem de tarefas, em vez de apenas a quantidade de trabalho restante.

Criar um dashboard sem uma equipe

Agora você pode criar uma dashboard sem associá-la a uma equipe. Ao criar um dashboard, selecione o tipo Painel do Projeto.

Um Painel de Projeto é como um Painel de Equipe, exceto que ele não está associado a uma Equipe e você pode decidir quem pode editar/gerenciar o dashboard. Assim como um Painel de Equipe, ele é visível para todos no projeto.

Todos os widgets do Azure DevOps que exigem um contexto de equipe foram atualizados para permitir que você selecione uma equipe em sua configuração. Você pode adicionar esses widgets aos Painéis do Projeto e selecionar a equipe específica desejada.

Observação

Para widgets personalizados ou de terceiros, um Painel de Projeto passará o contexto da equipe padrão para esses widgets. Se você tiver um widget personalizado que depende do contexto da equipe, atualize a configuração para permitir que você selecione uma equipe.

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.

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.

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

Obrigada,

Jeff Beehler