Experiência aprimorada de solicitação pull
Neste sprint, estamos adicionando uma série de aprimoramentos à experiência de solicitação pull. Isso inclui tornar as verificações opcionais mais visíveis, habilitar cliques Ctrl para abrir uma nova guia, adicionar local às anotações e melhorar o layout de filtragem de comentários.
Confira a lista de recursos abaixo para obter detalhes.
Recursos
Azure Boards
Azure Repos
Azure Pipelines
- Atualizando o nó no agente do Azure Pipelines
- Salvar um agente não íntegro para investigação em agentes de conjunto de escala
- Ubuntu-pipelines mais recentes em breve usará o Ubuntu-20.04
Azure Boards
Removendo a regra "Atribuído a" no tipo de item de trabalho de Bug
Há várias regras de sistema ocultas em todos os diferentes tipos de item de trabalho no Agile, Scrum e CMMI. Essas regras existem há mais de uma década e, em geral, funcionaram bem sem reclamações. No entanto, há algumas regras que se esgotaram. Uma regra em particular causou muita dor para clientes novos e existentes e decidimos que era hora de removê-la. Essa regra existe no tipo de item de trabalho Bug no processo Agile.
"Defina o valor Atribuído como Criado por quando o estado for alterado para Resolvido"
Recebemos muitos comentários sobre essa regra. Em resposta, fomos em frente e removemos essa regra do tipo de item de trabalho Bug no processo Agile. Essa mudança afetará todos os projetos que usam um Agile herdado ou um processo Agile herdado personalizado. Para os clientes que gostam e dependem dessa regra atual, consulte nossa postagem no blog sobre as etapas que você pode seguir para adicionar novamente a regra usando regras personalizadas.
Azure Repos
Um lote de melhorias na experiência de solicitação pull
A nova experiência de solicitação pull está em pré-visualização há alguns meses. Temos abordado o feedback que recebemos de muitos de vocês. Temos o prazer de anunciar as seguintes melhorias que você verá com a implantação desta sprint:
Tornar as verificações opcionais mais visíveis
Os clientes usam verificações opcionais para chamar a atenção de um desenvolvedor para possíveis problemas. Na experiência anterior, costumava ser óbvio quando essas verificações falham. No entanto, esse não é o caso na experiência de visualização. Uma grande marca de seleção verde nas verificações obrigatórias mascara as falhas nas verificações opcionais. Os usuários só podiam descobrir que as verificações opcionais falharam abrindo o painel de verificações. Os desenvolvedores não costumam fazer isso quando não há indicação de um problema. Nessa implantação, tornamos o status das verificações opcionais mais visível no resumo.
Clique com a tecla Ctrl pressionada nos itens de menu
Os menus de tabulação num PR não suportavam o clique com a tecla Ctrl pressionada. Os usuários geralmente abrem novas guias do navegador enquanto revisam uma solicitação pull. Esse problema foi corrigido.
Localização da anotação [+]
A listagem em árvore de arquivos em um PR mostra uma anotação [+] para ajudar os autores e revisores a identificar novos arquivos. Como a anotação era posterior às reticências, muitas vezes não era visível para nomes de arquivo mais longos.
Atualizações de RP lista suspensa recuperar informações de tempo
A lista suspensa para selecionar, atualizar e comparar arquivos em um PR perdeu um elemento importante na experiência de visualização. Ele não mostrou quando essa atualização foi feita. Esse problema foi corrigido.
Layout de filtro de comentário aprimorado
Ao filtrar comentários na página de resumo de uma solicitação pull, a lista suspensa estava à direita, mas o texto estava alinhado à esquerda. Esse problema foi corrigido.
Temos mais melhorias planejadas para as próximas duas sprints.
Azure Pipelines
Atualizando o nó no agente do Azure Pipelines
Atualização do que foi publicado originalmente: Devido a uma incompatibilidade com o Red Hat Enterprise Linux 6 e o Node 14, suspendemos o trabalho no Node 14 e primeiro nos concentraremos em chegar ao Node 10.
Nesta versão, começamos nossa mudança do Nó 6 para uma versão de Nó com suporte como o tempo de execução preferencial para tarefas do Azure Pipelines. Atualizamos o primeiro lote de tarefas prontas para uso a serem executadas no Nó 10. Essa alteração marca o início de um processo para remover o Nó 6 do agente por padrão. O nó 6 saiu do suporte de longo prazo e é frequentemente sinalizado como um risco de segurança por scanners automatizados. Embora acreditemos que nosso uso do Node 6 provavelmente não esteja sujeito à maioria das possíveis falhas, é importante para nós colocar as tarefas em um tempo de execução suportado. No ano civil de 2021, planejamos começar a enviar uma versão do agente sem o Nó 6.
Se você usar qualquer uma das tarefas habilitadas para o Nó 10, seus agentes auto-hospedados se atualizarão para executar as novas versões das tarefas. Fora isso, não deve haver impacto para a maioria dos clientes. Por outro lado, se você for o autor de alguma tarefa, deverá começar a atualizá-las para serem executadas no Nó 10. No , task.jsonem execution, você pode atualizar de Node para Node10. Se você precisar oferecer suporte a versões mais antigas do servidor, poderá deixar seu Node ponto de entrada. As instâncias do Azure DevOps que entendem o manipulador do Nó 10 o escolherão por padrão, e as que não entenderem retornarão à sua implementação do Nó 6.
Salvar um agente não íntegro para investigação em agentes de conjunto de escala
Quando você usa agentes de conjunto de escala, o Azure Pipelines gerencia a expansão para cima e para baixo das instâncias do agente. Quando o Azure Pipelines detecta uma VM não íntegra no conjunto de escala, ele registrará o problema na interface do usuário do Pool Diagnostics e tentará excluir a VM. Há muitas razões pelas quais uma VM pode não estar íntegra: a configuração de rede do conjunto de escala pode ter impedido que a extensão do Azure Pipelines baixe o agente mais recente, sua extensão de script personalizada pode ter falhado ou a imagem da VM do conjunto de escala pode ter uma reinicialização pendente ou atualizações do Windows pendentes.
Ao excluir VMs não íntegras, o Azure Pipelines mantém seu pool de agentes otimizado para executar trabalhos de CI/CD. Em alguns casos, você poderá usar a página de diagnóstico do Azure Pipelines (mostrada acima) ou a página de diagnóstico do Azure para depurar esse problema. No entanto, em muitos casos, a melhor maneira de diagnosticar o problema é fazer logon na VM e revisar os logs do agente e os logs do visualizador de eventos. No momento, isso não é fácil de fazer, já que a VM não íntegra é excluída automaticamente.
Com esta versão, aprimoramos a capacidade de diagnóstico de VMs não íntegras, oferecendo a você a capacidade de salvar um agente não íntegro para investigação.
Quando um agente não íntegro é salvo, você pode se conectar à máquina virtual, depurar e recuperar os logs necessários. Quando terminar, você poderá liberar o agente e a VM associada. Para obter mais informações, consulte a seção sobre solução de problemas de agentes não íntegros.
ubuntu-latest pipelines em breve usará o Ubuntu-20.04
O Ubuntu 20.04 em breve será a versão padrão para o ubuntu-latest rótulo no Azure Pipelines. Essa mudança será implementada em um período de várias semanas a partir de 30 de novembro.
Se você vir quaisquer problemas com seus pipelines do Ubuntu:
- Arquivar um problema no repositório de ambientes virtuais
- Volte para o Ubuntu 18.04 especificando
ubuntu-18.04como ovmImageem seu pipeline. Continuaremos a oferecer suporte ao Ubuntu 18.04.
Observe que ubuntu-18.04 e ubuntu-20.04 pode diferir em ambas as ferramentas pré-instaladas e as versões padrão das ferramentas. Para obter informações sobre todas as diferenças, consulte https://github.com/actions/virtual-environments/issues/1816.
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 obter conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.
Obrigada,
Matt Cooper