O Azure Artifacts simplifica a integração com outros serviços

Com essa atualização, facilitamos a autenticação do Azure Artifacts com outros gerenciadores de pacotes populares. Encontre mais detalhes sobre a implementação real abaixo.

Features

Azure Boards

• Adicionar o filtro "Item de Trabalho Pai" ao quadro de tarefas e à lista de pendências de sprint
• Aprimorar a experiência no tratamento de erros – campos obrigatórios em Bug/Tarefa

Azure Pipelines

• Visualização dos agentes do conjunto de escalas
• Ubuntu 20.04 em versão prévia para pools hospedados do Azure Pipelines
• Suporte para pacotes do GitHub em pipelines YAML

Azure Artifacts

• Notificações para fontes upstream desabilitadas
• Expressões de licença e licenças inseridas
• Tarefas de autenticação leve

Azure Boards

Adicione o filtro "Item de Trabalho Pai" ao painel de tarefas e à lista de pendências do sprint

Adicionamos um novo filtro tanto ao quadro Sprint quanto ao backlog da Sprint. Isso permite filtrar itens de lista de pendências no nível dos requisitos (primeira coluna à esquerda) pelo pai. Por exemplo, na captura de tela abaixo, filtramos a exibição para mostrar apenas histórias de usuário em que o pai é "Meu grande recurso".

Aprimoramento na experiência de tratamento de erro – campos obrigatórios em Bug/Tarefa

Historicamente, no quadro Kanban, ao mover um item de trabalho de uma coluna para outra onde a mudança de estado acionava regras de campo, o cartão apenas mostraria uma mensagem de erro vermelha que obrigaria você a abrir o item de trabalho para entender a causa do problema. No sprint 170, melhoramos a experiência para que agora você possa clicar na mensagem de erro vermelha para ver os detalhes do erro sem precisar abrir o item de trabalho em si.

Azure Pipelines

Versão prévia dos agentes do conjunto de dimensionamento

Estamos apresentando uma prévia de um novo recurso chamado agentes de conjunto de dimensionamento que combina a capacidade elástica e a conveniência dos agentes hospedados pela Microsoft com o controle e a flexibilidade dos agentes auto-hospedados. Com esta versão prévia, agora habilitamos você a gerenciar agentes para sua especificação, completamente automatizada, em sua assinatura do Azure. Talvez você queira considerar o uso de agentes de conjuntos de dimensionamento em vez de agentes hospedados pela Microsoft ou auto-hospedados nos seguintes casos:

• precisa de mais memória, mais processador, mais armazenamento ou mais E/S do que o que oferecemos em agentes nativos hospedados pela Microsoft
• não deseja permitir a lista de um grande número de endereços IP em seu firewall corporativo para permitir que agentes hospedados pela Microsoft se comuniquem com seus servidores
• precisa de mais agentes hospedados pela Microsoft do que podemos fornecer para atender às suas necessidades de grande escala
• precisa da capacidade de particionar trabalhos paralelos hospedados pela Microsoft para projetos individuais ou equipes em sua organização
• não deseja executar agentes dedicados 24 horas por dia, mas, em vez disso, deseja desprovisionar computadores de agente que não estão sendo utilizados ativamente

Para usar agentes do conjunto de dimensionamento, primeiro você criará um conjunto de dimensionamento de VMs em sua assinatura do Azure e, em seguida, criará um pool de agentes no Azure Pipelines para apontar para esse conjunto de dimensionamento. O Azure Pipelines dimensionará automaticamente esse pool com base no número de trabalhos pendentes e no número de computadores ociosos que você deseja manter o tempo todo. O Azure Pipelines também instalará o agente para você nessas máquinas virtuais. Para obter mais informações, consulte agentes do conjunto de escalonamento. Ao visualizar o recurso, inclua seus comentários na página de documentação.

Ubuntu 20.04 em versão prévia para pools hospedados do Azure Pipelines

A imagem do Ubuntu 20.04 agora está disponível em versão prévia para pools hospedados do Azure Pipelines. Para usar essa imagem, atualize o arquivo YAML para incluir vmImage: 'ubuntu-20.04' . Observe que o rótulo de imagem mais recente do ubuntu continuará apontando para ubuntu-18.04 até que o ubuntu-20.04 saia da versão prévia ainda este ano.

Observe que, como a imagem do ubuntu 20.04 está em versão prévia, ela atualmente não dá suporte a todas as ferramentas disponíveis no ubuntu-18.04. Saiba mais

Suporte para pacotes do GitHub em pipelines YAML

Recentemente, introduzimos um novo tipo de recurso chamado pacotes que adiciona suporte para consumir pacotes NuGet e npm do GitHub como um recurso em pipelines YAML. Como parte desse recurso, agora você pode especificar o tipo de pacote (NuGet ou npm) que deseja consumir do GitHub. Você também pode habilitar gatilhos de pipeline automatizados após o lançamento de uma nova versão do pacote. Hoje, o suporte só está disponível para consumir pacotes do GitHub, mas, seguindo em frente, planejamos estender o suporte para consumir pacotes de outros repositórios de pacotes, como NuGet, npm, AzureArtifacts e muito mais. Consulte o exemplo abaixo para obter detalhes:

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # GitHub service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the package to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Observação: hoje os pacotes do GitHub dão suporte apenas à autenticação baseada em PAT, o que significa que a conexão de serviço do GitHub no recurso de pacote deve ser do tipo PAT. Depois que essa limitação for levantada, forneceremos suporte para outros tipos de autenticação.

Por padrão, os pacotes não são baixados automaticamente em seus trabalhos, portanto, por isso introduzimos uma macro getPackage que permite consumir o pacote definido no recurso. Consulte o exemplo abaixo para obter detalhes:

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

Azure Artifacts

Notificações para origens de upstream desabilitadas

A interface da Web do Azure Artifacts agora notifica você quando uma ou mais das fontes upstream do feed não estão funcionando. As fontes upstream permitem que você aponte um feed (Feed A) para outro feed (Feed B) e permita que os consumidores do Feed A acessem pacotes do Feed B sem precisar se conectar diretamente a ele. Para obter mais informações sobre fontes upstream, consulte a documentação do Azure Artifacts. As fontes upstream poderão não funcionar se estiverem desabilitadas na origem, por exemplo, se o Feed B for excluído silenciosamente, os clientes não poderão buscar pacotes por meio do Feed A. No passado, essa situação poderia acontecer sem aviso e levar a problemas operacionais difíceis de diagnosticar, como quebras repentinas de build devido a dependências ausentes (ou seja, pacotes originados do Feed B no exemplo acima). Agora, o Azure Artifacts fornecerá um aviso quando houver problemas com quaisquer fontes upstream de seus feeds. Quando houver um problema, você verá uma faixa (seta vermelha abaixo) na página de detalhes do feed do Azure Artifacts.

Clicar no link no banner abrirá uma página que mostra o status de cada fonte upstream do feed. Além das informações sobre cada fonte upstream para o feed atual, você pode ver o status atual na coluna "Última sincronização". As fontes ascendentes que estão funcionando corretamente mostrarão um sinal de verificação verde com a última vez que o estado da fonte foi verificado. As fontes de origem que estão quebradas mostrarão um X vermelho junto com a hora em que foram verificadas. As fontes upstream que estão em verificação pendente mostrarão um ícone de informações azul.

Quando você clicar no horário da última sincronização de uma fonte upstream quebrada, uma caixa de diálogo será aberta, fornecendo mais detalhes sobre a causa raiz do problema (se disponível). Por exemplo, na imagem abaixo, a fonte upstream em questão não está funcionando porque o feed de destino foi excluído. A caixa de diálogo também contém um link para o log de auditoria, para ajudá-lo a entender quem fez alterações relevantes recentemente. Links para as configurações de permissões e a documentação do Azure Artifacts também podem ser usados para ajudar a investigar a causa raiz.

Expressões de licença e licenças incorporadas

Agora você pode ver os detalhes das informações de licença para pacotes NuGet armazenados no Azure Artifacts durante a navegação de pacotes no Visual Studio. Isso se aplica a licenças que são representadas usando expressões de licença ou licenças inseridas. Agora você pode ver um link para as informações de licença na página de detalhes do pacote do Visual Studio (seta vermelha na imagem abaixo).

Clicar no link levará você para uma página da Web em que você pode exibir os detalhes da licença. Essa experiência é a mesma para expressões de licença e licenças inseridas, portanto, você pode ver detalhes de licença para pacotes armazenados no Azure Artifacts em um só lugar (para pacotes que especificam informações de licença e têm suporte do Visual Studio).

Tarefas de autenticação leves

Agora você pode se autenticar com gerenciadores de pacotes populares do Azure Pipelines usando tarefas de autenticação leves. Isso inclui NuGet, npm, PIP, Twine e Maven. Anteriormente, você poderia autenticar com esses gerenciadores de pacotes usando tarefas que forneceram uma grande quantidade de funcionalidade, incluindo a capacidade de publicar e baixar pacotes. No entanto, isso exigia o uso dessas tarefas para todas as atividades que interagiram com os gerenciadores de pacotes. Se você tivesse seus próprios scripts para executar tarefas como publicar ou baixar pacotes, não seria capaz de usá-los em seu Pipeline. Agora, você pode usar scripts de sua própria criação no YAML do seu pipeline e executar a autenticação com essas novas tarefas simplificadas. Um exemplo usando o npm:

O uso do comando "ci" e "publish" nesta ilustração é arbitrário, você pode usar todos os comandos compatíveis com o YAML do Azure Pipelines. Isso permite que você tenha controle completo da invocação de comando e facilita o uso de scripts compartilhados na configuração do pipeline. Para obter mais informações, consulte a documentação da tarefa de autenticação NuGet, npm, PIP, Twine e Maven .

Próximas etapas

Vá até o Azure DevOps e dê uma olhada.

Como fornecer comentários

Adoraríamos ouvir o que você pensa sobre essas características. 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