Criar um dashboard sem uma equipa - Atualização do Sprint 162

Na Atualização sprint 162 do Azure DevOps, temos o entusiasmo em anunciar que pode criar um dashboard sem o associar a uma equipa. O dashboard estará visível para todas as pessoas no projeto e pode decidir quem o pode editar/gerir.

Além disso, adicionámos a miniatura de evolução do sprint. Agora, pode configurá-lo para evolução com base em histórias, pontos de história ou por contagem de tarefas.

Consulte a lista funcionalidades abaixo para obter mais informações.

Funcionalidades

Repositórios do Azure:

• Novas páginas de destino de conversão de plataforma Web
• Suporte para idioma kotlin

Azure Pipelines:

• IU dos pipelines de várias fases atualizada
• A opção TestResultsDirectory do VSTest está disponível na IU da tarefa
• Utilizar expande a palavra-chave em pipelines
• Suporte de Markdown em mensagens de erro de teste automatizadas
• Recolher metadados automáticos e especificados pelo utilizador do pipeline
• Atualizações à IU das ligações de serviço
• Implementações de VMs com Ambientes
• Ignorar fases num pipeline YAML

Relatórios:

• Miniatura de evolução do sprint inline
• Criar um dashboard sem uma equipa

Repositórios do Azure

Novas páginas de destino de conversão de plataforma Web

Atualizámos a experiência de utilizador das páginas de destino de Repositórios para torná-la moderna, rápida e compatível com dispositivos móveis. Eis dois exemplos das páginas que foram atualizadas. Continuaremos a atualizar outras páginas em atualizações futuras.

Experiência Web:

Experiência móvel:

Suporte para idioma kotlin

Temos o entusiasmo em anunciar que agora suportamos o realce da linguagem Kotlin no editor de ficheiros. Realçar irá melhorar a legibilidade do seu ficheiro de texto Kotlin e ajudá-lo a analisar rapidamente para encontrar erros. Priorizámos esta funcionalidade com base numa sugestão da Comunidade de Programadores.

Pipelines do Azure

IU dos pipelines de várias fases atualizada

Uma versão atualizada da IU dos pipelines de várias fases está agora disponível por predefinição. A experiência de pipelines de várias fases traz melhorias e facilidade de utilização na IU do portal do pipeline. Pode ver e gerir os pipelines ao selecionar Pipelines no menu esquerdo. Além disso, pode desagregar e ver detalhes do pipeline, detalhes da execução, análise de pipelines, detalhes da tarefa, registos e muito mais.

Para saber mais sobre a experiência de utilizador dos pipelines em várias fases, veja a documentação aqui.

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

A tarefa VSTest armazena os resultados do teste e os ficheiros associados na $(Agent.TempDirectory)\TestResults pasta . Adicionámos uma opção à IU da tarefa para lhe permitir configurar uma pasta diferente para armazenar os resultados dos testes. Agora, todas as tarefas subsequentes que necessitem dos ficheiros numa localização específica podem utilizá-las.

Utilizar expande a palavra-chave em pipelines

Atualmente, os pipelines podem ser contabilizados em modelos, promovendo a reutilização e reduzindo o texto automático. A estrutura geral do pipeline ainda foi definida pelo ficheiro YAML de raiz. Com esta atualização, adicionámos uma forma mais estruturada de utilizar modelos de pipeline. Um ficheiro YAML de raiz pode agora utilizar a palavra-chave expandida para indicar que a estrutura do pipeline principal pode ser encontrada noutro ficheiro. Isto coloca-o no controlo dos segmentos que podem ser expandidos ou alterados e que segmentos são fixos. Também melhorámos os parâmetros do pipeline com tipos de dados para tornar claros os hooks que pode fornecer.

Este exemplo ilustra como pode fornecer hooks simples para o autor do pipeline utilizar. O modelo executará sempre uma compilação, executará opcionalmente passos adicionais fornecidos pelo pipeline e, em seguida, executará um passo 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 de Markdown em mensagens de erro de teste automatizadas

Adicionámos suporte de Markdown a mensagens de erro para testes automatizados. Agora, pode formatar facilmente mensagens de erro para a execução de testes e o resultado do teste para melhorar a legibilidade e facilitar a experiência de resolução de problemas de falhas de teste no Azure Pipelines. A sintaxe markdown suportada pode ser encontrada aqui.

Recolher metadados automáticos e especificados pelo utilizador do pipeline

Agora, pode ativar a coleção de metadados automática e especificada pelo utilizador a partir de tarefas de pipeline. Pode utilizar metadados para impor a política de artefactos num ambiente com a verificação de artefactos de avaliação.

Atualizações à IU das ligações de serviço

Temos estado a trabalhar numa experiência de utilizador atualizada para gerir as suas ligações de serviço. Estas atualizações tornam a experiência de ligação do serviço moderna e consistente com a direção do Azure DevOps. Introduzimos a nova IU para ligações de serviço como uma funcionalidade de pré-visualização no início deste ano. Graças a todos os que experimentaram a nova experiência e nos forneceram os seus valiosos comentários.

Juntamente com a atualização da experiência do utilizador, também adicionámos duas capacidades que são essenciais para consumir ligações de serviço em pipelines YAML: autorizações de pipeline e aprovações e verificações.

A nova experiência de utilizador será ativada por predefinição com esta atualização. Continuará a ter a opção de optar ativamente por não participar na pré-visualização.

Nota

Planeamos introduzir a Partilha entre projetos de Ligações de Serviço como uma nova capacidade. Pode encontrar mais detalhes sobre a experiência de partilha e as funções de segurança aqui.

Implementações de VMs com Ambientes

Uma das funcionalidades mais pedidas em Ambientes foi a implementação de VMs. Com esta atualização, estamos a ativar o recurso de Máquina Virtual em Ambientes. Agora pode orquestrar implementações em várias máquinas e executar atualizações sem interrupção com pipelines YAML. Também pode instalar o agente em cada um dos servidores de destino diretamente e impulsionar a implementação sem interrupção para esses servidores. Além disso, pode utilizar o catálogo de tarefas completo nos computadores de destino.

Uma implementação sem interrupção substitui as instâncias da versão anterior de uma aplicação por instâncias da nova versão da aplicação num conjunto de máquinas (conjunto sem interrupção) em cada iteração.

Por exemplo, a implementação sem interrupção abaixo atualiza até cinco destinos em cada iteração. maxParallel irá determinar o número de destinos que podem ser implementados em paralelo. A seleção representa o número de destinos que têm de permanecer disponíveis em qualquer altura, excluindo os destinos em que estão a ser implementados. Também é utilizado para determinar as condições de êxito e falha durante a implementaçã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...

Nota

Com esta atualização, todos os artefactos disponíveis do pipeline atual e dos recursos de pipeline associados são transferidos apenas no deploy ciclo de vida. No entanto, pode optar por transferir ao especificar a tarefa Transferir Artefacto do Pipeline. Existem algumas lacunas conhecidas nesta funcionalidade. Por exemplo, quando repetir uma fase, esta executará novamente a implementação em todas as VMs e não apenas em destinos falhados. Estamos a trabalhar para colmatar estas lacunas em futuras atualizações.

Ignorar fases num pipeline YAML

Quando inicia uma execução manual, por vezes poderá querer ignorar algumas fases no pipeline. Por exemplo, se não quiser implementar na produção ou se quiser ignorar a implementação em alguns ambientes em produção. Agora pode fazê-lo com os seus pipelines YAML.

O painel do pipeline de execução atualizado apresenta uma lista de fases do ficheiro YAML e tem a opção de ignorar uma ou mais dessas fases. Tem de ter cuidado ao ignorar fases. Por exemplo, se a primeira fase produzir determinados artefactos necessários para as fases subsequentes, não deve ignorar a primeira fase. O painel de execução apresenta um aviso genérico sempre que ignorar fases que tenham dependências a jusante. Cabe-lhe a si decidir se essas dependências são verdadeiras dependências de artefactos ou se estão apenas presentes para sequenciação de implementações.

Ignorar uma fase é equivalente a rewiring as dependências entre fases. Todas as dependências imediatas a jusante da fase ignorada são feitas para depender do elemento principal a montante da fase ignorada. Se a execução falhar e se tentar executar novamente uma fase com falha, essa tentativa também terá o mesmo comportamento de ignorar. Para alterar as fases que são ignoradas, tem de iniciar uma nova execução.

Relatórios

Miniatura de evolução do sprint inline

O Sprint Burndown está de volta! Há alguns sprints, removemos a evolução do sprint no contexto dos cabeçalhos Sprint Burndown e Taskboard. Com base nos seus comentários, melhorámos e reintroduzimos a miniatura da evolução do sprint.

Clicar na miniatura apresentará imediatamente uma versão maior do gráfico com uma opção para ver o relatório completo no separador Análise. Todas as alterações efetuadas ao relatório completo serão refletidas no gráfico apresentado no cabeçalho. Assim, agora pode configurá-lo para evolução 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 equipa

Agora pode criar um dashboard sem o associar a uma equipa. Ao criar um dashboard, selecione o tipo de Dashboard do Projeto .

Um Dashboard de Projeto é como um Dashboard de Equipa, exceto que não está associado a uma Equipa e pode decidir quem pode editar/gerir o dashboard. Tal como um Dashboard de Equipa, é visível para todas as pessoas no projeto.

Todos os widgets do Azure DevOps que requerem um contexto de equipa foram atualizados para permitir que selecione uma equipa na respetiva configuração. Pode adicionar estes widgets aos Dashboards do Project e selecionar a equipa específica que pretende.

Nota

Para widgets personalizados ou de terceiros, um Dashboard de Projeto transmitirá o contexto da equipa predefinida a esses widgets. Se tiver um widget personalizado que depende do contexto de equipa, deve atualizar a configuração para permitir que selecione uma equipa.

Passos seguintes

Nota

Estas funcionalidades serão implementadas nas próximas duas a três semanas.

Aceda ao Azure DevOps e dê uma vista de olhos.

Aceda ao Azure DevOps

Como fornecer comentários

Gostaríamos de saber o que pensa sobre estas funcionalidades. Utilize o menu de ajuda para comunicar um problema ou fornecer uma sugestão.

Também pode obter conselhos e as suas perguntas respondidas pela comunidade no Stack Overflow.

Obrigado,

Jeff Beehler