Melhorias ao Dashboard de Cópia
Estamos entusiasmados por anunciar algumas melhorias há muito esperadas para a pré-visualização do Dashboard de Cópia. Agora, pode copiar um dashboard para uma equipa diferente, para a mesma equipa ou para um projeto diferente e a configuração da equipa e da consulta é atualizada no novo dashboard. Isto minimiza ainda mais o trabalho necessário para criar dashboards semelhantes do zero para várias equipas.
Consulte as seguintes descrições de funcionalidades para obter detalhes.
Geral
Pipelines do Azure
- Repetições automáticas de uma tarefa
- Consumir entradas de outra tarefa num decorador
- Melhorias no histórico de utilização de ligações de serviço
- A especificação do agente predefinida para pipelines clássicos é agora o Windows-2019
Relatórios
Geral
Atribuir a função de Administrador do Azure DevOps a um grupo de Azure AD
A função de Administrador do Azure DevOps, necessária para configurar Azure AD políticas de inquilino no Azure DevOps, pode agora ser atribuída a um Azure AD grupos. Saiba mais sobre como utilizar grupos de Azure AD para gerir atribuições de funções no Azure AD.
Pipelines do Azure
Repetições automáticas de uma tarefa
Quando tem uma tarefa escamosa que falha intermitentemente num pipeline, poderá ter de executar novamente o pipeline para que seja bem-sucedido. Na maioria dos casos, a melhor forma de abordar uma tarefa ou script escamoso é ao corrigir a tarefa ou o próprio script. Por exemplo, se a tarefa de teste falhar num pipeline devido a testes escamosos, é sempre boa ideia corrigir os testes escamosos e torná-los mais fiáveis. Da mesma forma, se o script falhar de vez em quando, é melhor corrigir o script, por exemplo, introduzindo repetições no script.
No entanto, existem alguns casos em que poderá querer repetir a tarefa. Um caso de utilização comum é uma tarefa que transfere um pacote (por exemplo, NuGet, npm, etc.). Observámos frequentemente que estas tarefas são suscetíveis a falhas de rede e às falhas transitórias nos servidores de alojamento de pacotes. Ouvimos o seu feedback de que seria melhor repetir automaticamente tais tarefas falhadas sem ter de reiniciar todo o pipeline novamente.
Com base nos seus comentários, adicionámos uma funcionalidade para repetir automaticamente uma tarefa num pipeline quando esta falhar. Se utilizar pipelines YAML, pode definir esta entrada da seguinte forma:
- task: <name of task>
retryCountOnTaskFailure: <max number of retries>
...
Ao utilizar pipelines de compilação ou versão clássicos, pode definir esta propriedade nas opções de controlo da tarefa.
Seguem-se alguns aspetos a ter em conta ao utilizar repetições:
- A tarefa com falhas é repetida imediatamente.
- Não há nenhuma suposição sobre a idempotência da tarefa. Se a tarefa tiver efeitos colaterais (por exemplo, se tiver criado parcialmente um recurso externo), poderá falhar na segunda vez que for executada.
- Não existem informações sobre a contagem de repetições disponibilizadas à tarefa.
- É adicionado um aviso aos registos de tarefas que indicam que falhou antes de ser repetido.
- Todas as tentativas de repetição de uma tarefa são apresentadas na IU como parte do mesmo nó de tarefa.
Nota
Requer a versão 2.194.0 ou posterior do agente. Não suportado para tarefas sem agente.
Consumir entradas de outra tarefa num decorador
Adicionámos recentemente uma funcionalidade para injetar uma tarefa automaticamente num pipeline antes de outra tarefa de destino nesse pipeline. Estamos agora a melhorar essa funcionalidade ao permitir-lhe personalizar essa tarefa injetada com os parâmetros de entrada da tarefa de destino. A sintaxe para escrever um decorador para o fazer é a seguinte:
{
"contributions": [
{
"id": <my-required-task>,
"type": "ms.azure-pipelines.pipeline-decorator",
"targets": [
"ms.azure-pipelines-agent-job.pre-task-tasks",
"ms.azure-pipelines-agent-job.post-task-tasks"
],
"properties": {
"template": "my-decorator.yml",
"targettask": <target-task-id>,
"targettaskinputs": ["<name of input>"]
}
}
],
...
}
Esta funcionalidade só funciona quando utiliza pre-task-tasks ou post-task-tasks como destino para injeção e especifica a targettask na secção de propriedades da contribuição. Em seguida, pode adicionar uma propriedade adicional chamada targettaskinputs e especificar uma lista de nomes de parâmetros de entrada aceites pela tarefa de destino. Estas entradas são agora disponibilizadas para a tarefa injetada.
Um caso de utilização comum que pode ser realizado por tal cenário é o seguinte. Digamos que pretende injetar uma tarefa que irá registar automaticamente o nome do artefacto que está a ser publicado por uma compilação. O nome do artefacto é uma entrada para a PublishBuildArtifacts tarefa. A tarefa injetada pode agora obter o mesmo parâmetro de entrada e utilizá-la para o registo.
Melhorias no histórico de utilização de ligações de serviço
Quando um pipeline utiliza uma ligação de serviço, essa utilização é registada no histórico da ligação. Os administradores da ligação de serviço podem rever o histórico de utilização ao navegar para as definições do projeto e selecionar a ligação de serviço adequada. Ocorreu alguns problemas com o histórico de utilização das ligações de serviço que foram corrigidos com esta atualização. As correções incluem o seguinte:
- Quando uma ligação de serviço é utilizada numa tarefa de implementação (em vez de uma tarefa normal), essa utilização não estava a ser registada.
- Se utilizasse várias ligações de serviço em várias fases de um pipeline, todas as ligações de serviço mostrariam um registo no histórico de utilização, apesar de algumas das fases terem sido ignoradas.
A especificação do agente predefinida para pipelines clássicos é agora o Windows-2019
Nas últimas notas de versão, anunciámos uma agenda de preterição para vs2017-win2016 imagens alojadas. Em preparação para isso, estamos agora a alterar a especificação predefinida do agente ao criar novos pipelines em Pipelines clássicos para windows-2019.
Relatórios
Melhorias no Dashboard de Cópia
Estamos entusiasmados por anunciar a pré-visualização pública da fase 2 do Dashboard de Cópia! As consultas e a configuração são agora transmitidas com a operação de cópia. Obrigado pela sua paciência, pois demorou um pouco mais do que o esperado para resolver alguns dos problemas.
A pré-visualização está ativada por predefinição com o sinalizador de funcionalidade Copiar Experiência do Dashboard (em funcionalidades de pré-visualização).
Para copiar um dashboard, aceda primeiro ao dashboard que pretende copiar. Em segundo lugar, clique no menu para apresentar o Dashboard de Cópia e, em seguida, clique no mesmo.
Em seguida, forneça o nome e a descrição do novo dashboard e, em seguida, selecione o tipo de dashboard, Equipa ou Projeto. Ao selecionar um Dashboard de Equipa, o novo projeto e a equipa são selecionados nas respetivas caixas pendentes. Para um dashboard do Project, só é necessário o projeto.
Será levado para o dashboard criado recentemente depois de clicar no botão Criar . Os widgets e o esquema permanecem os mesmos.
Nos bastidores, é criada uma pasta com o nome do novo dashboard em Consultas Partilhadas. Todas as consultas do novo dashboard são copiadas para essa pasta. Os nomes das consultas permanecem os mesmos. Os widgets com uma configuração de Equipa são atualizados com a nova equipa. Os Widgets com uma configuração de Equipa a ser copiada de um dashboard de Equipa para um Dashboard de Projeto mantêm a configuração original.
Filtrar os valores nulos no widget do gráfico de evolução
Agora, pode filtrar um valor nulo ao utilizar Critérios de Campo no widget do gráfico de evolução. Este comportamento é agora consistente com uma consulta com os mesmos critérios de campo.
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.
Como fornecer comentários
Gostaríamos de ouvir 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,
Aaron Hallberg