Melhorias no Painel de Cópia
Estamos felizes em anunciar algumas melhorias aguardadas para a versão prévia do Painel de Cópia. Agora você pode copiar um dashboard para uma equipe diferente, a mesma equipe ou um projeto diferente , e a configuração de equipe e consulta é atualizada no novo dashboard. Isso minimiza ainda mais o trabalho necessário para criar painéis semelhantes do zero para várias equipes.
Confira as descrições de recursos a seguir para obter detalhes.
Geral
Azure Pipelines
- Repetições automáticas para uma tarefa
- Consumir entradas de outra tarefa em um decorador
- Melhorias no histórico de uso de conexões de serviço
- A especificação de agente padrão para pipelines clássicos agora é Windows-2019
Relatórios
Geral
Atribuir a função de Administrador do Azure DevOps a um grupo de Azure AD
A função administrador do Azure DevOps, necessária para configurar Azure AD políticas de locatário no Azure DevOps, agora pode ser atribuída a um grupo de Azure AD. Saiba mais sobre como usar grupos de Azure AD para gerenciar atribuições de função em Azure AD.
Azure Pipelines
Repetições automáticas para uma tarefa
Quando você tem uma tarefa irregular que falha intermitentemente em um pipeline, talvez seja necessário executar novamente o pipeline para que ele tenha êxito. Na maioria dos casos, a melhor maneira de lidar com uma tarefa ou script insumos é corrigindo a tarefa ou o próprio script. Por exemplo, se sua tarefa de teste falhar em um pipeline devido a testes irregulares, é sempre uma boa ideia corrigir os testes e torná-los mais confiáveis. Da mesma forma, se o script falhar de vez em quando, é melhor corrigir o script, por exemplo, introduzindo novas tentativas dentro do script.
No entanto, há alguns casos em que talvez você queira repetir a tarefa. Um caso de uso comum para isso é uma tarefa que baixa um pacote (por exemplo, NuGet, npm etc.). Muitas vezes, observamos que essas tarefas são suscetíveis a falhas de rede e a falhas transitórias nos servidores de hospedagem de pacote. Ouvimos seus comentários de que seria melhor repetir automaticamente essas tarefas com falha sem precisar reiniciar todo o pipeline novamente.
Com base em seus comentários, adicionamos um recurso para repetir automaticamente uma tarefa em um pipeline quando ela falhar. Se você usar pipelines YAML, poderá definir essa entrada da seguinte maneira:
- task: <name of task>
retryCountOnTaskFailure: <max number of retries>
...
Ao usar pipelines de build ou lançamento clássicos, você pode definir essa propriedade sob as opções de controle para a tarefa.
Aqui estão algumas coisas a serem observadas ao usar novas tentativas:
- A tarefa com falha é 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 um recurso externo parcialmente), ela poderá falhar na segunda vez em que for executada.
- Não há informações sobre a contagem de repetições disponibilizada para a tarefa.
- Um aviso é adicionado aos logs de tarefas indicando que ela falhou antes de ser repetida.
- Todas as tentativas de repetir uma tarefa são mostradas na interface do usuário como parte do mesmo nó de tarefa.
Observação
Requer a versão do agente 2.194.0 ou posterior. Não há suporte para tarefas sem agente.
Consumir entradas de outra tarefa em um decorador
Recentemente, adicionamos um recurso para injetar uma tarefa automaticamente em um pipeline antes de outra tarefa de destino nesse pipeline. Agora estamos aprimorando esse recurso permitindo que você personalize essa tarefa injetada usando os parâmetros de entrada da tarefa de destino. A sintaxe para escrever um decorador para fazer isso é 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>"]
}
}
],
...
}
Esse recurso só funciona quando você usa pre-task-tasks ou post-task-tasks como destino para injeção e especifica a targettask na seção propriedades da contribuição. Em seguida, você pode adicionar uma propriedade adicional chamada targettaskinputs e especificar uma lista de nomes de parâmetro de entrada aceitos pela tarefa de destino. Essas entradas agora são disponibilizadas para a tarefa injetada.
Um caso de uso comum que pode ser realizado por esse cenário é o seguinte. Digamos que você queira injetar uma tarefa que registrará automaticamente o nome do artefato que está sendo publicado por um build. O nome do artefato é uma entrada para a PublishBuildArtifacts tarefa. Sua tarefa injetada agora pode obter o mesmo parâmetro de entrada e usá-lo para registro em log.
Melhorias no histórico de uso de conexões de serviço
Quando um pipeline usa uma conexão de serviço, esse uso é registrado no histórico da conexão. Os administradores da conexão de serviço podem examinar o histórico de uso navegando até as configurações do projeto e selecionando a conexão de serviço apropriada. Houve alguns problemas com o histórico de uso de conexões de serviço que foram corrigidas com essa atualização. As correções incluem o seguinte:
- Quando uma conexão de serviço é usada em um trabalho de implantação (em vez de um trabalho regular), esse uso não estava sendo registrado.
- Se você usou várias conexões de serviço em vários estágios de um pipeline, todas as conexões de serviço mostrariam um registro em seu histórico de uso, mesmo que alguns dos estágios tenham sido ignorados.
A especificação de agente padrão para pipelines clássicos agora é Windows-2019
Nas últimas notas sobre a versão, anunciamos um agendamento de substituição para vs2017-win2016 imagens hospedadas. Em preparação para isso, agora estamos alterando a especificação de agente padrão ao criar novos pipelines em pipelines clássicos para windows-2019.
Relatórios
Copiar aprimoramentos do Painel
Estamos felizes em anunciar a versão prévia pública da fase 2 do Painel de Cópias! As consultas e a configuração agora são transferidas com a operação de cópia. Obrigado por sua paciência, pois demorou um pouco mais do que o esperado para resolver alguns dos problemas.
A versão prévia está ativada por padrão com o sinalizador de recurso Copiar Experiência do Painel (em recursos de versão prévia).
Para copiar um dashboard, primeiro vá para o dashboard que você deseja copiar. Em segundo lugar, clique no menu para abrir o Painel de Cópia e clique nele.
Em seguida, forneça o nome e a descrição do novo dashboard e selecione o tipo de dashboard, Equipe ou Projeto. Ao selecionar um Painel de Equipe, o novo projeto e a equipe são selecionados nas respectivas caixas suspensas. Para um project dashboard, somente o projeto é necessário.
Você será levado para o dashboard recém-criado depois de clicar no botão Criar. Os widgets e o layout permanecem os mesmos.
Nos bastidores, uma pasta com o nome do novo dashboard é criada em Consultas Compartilhadas. Todas as consultas para o novo dashboard são copiadas para essa pasta. Os nomes de consulta permanecem os mesmos. Widgets com uma configuração de equipe são atualizados com a nova equipe. Widgets com uma configuração de equipe sendo copiada de uma equipe dashboard para um Painel de Projeto mantêm a configuração original.
Filtrar valores nulos no widget do gráfico de burndown
Agora você pode filtrar um valor nulo ao usar Critérios de Campo no widget do gráfico de burndown. Esse comportamento agora é consistente com uma consulta usando os mesmos critérios de campo.
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.
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 receber conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.
Obrigada,
Aaron Hallberg