Notas de versão da Atualização 2 do Team Foundation Server 2018
Developer Community | Requisitos do Sistema e Compatibilidade | Termos de Licença | Blog DevOps do TFS | Hashes SHA-1 | | Notas sobre a versão mais recente do Visual Studio 2019
Observação
Se você estiver acessando esta página em uma versão de idioma que não seja o inglês e quiser ver o conteúdo mais atualizado, visite a página de Notas de Versão em inglês. Você pode alterar o idioma desta página clicando no ícone de globo no rodapé de página e selecionando o idioma desejado.
Neste artigo, você encontrará informações sobre a versão mais recente do Team Foundation Server 2018. Clique no botão para baixar.
Para saber mais sobre o Team Foundation Server 2018, consulte a página Team Foundation Server . Visite a página visualstudio.com/downloads para baixar outros produtos do TFS 2018.
O upgrade direto para o Team Foundation Server 2018 Atualização 2 é compatível desde o TFS 2012 até a versão mais recente. Se a implantação do TFS for da versão 2010 ou anterior, execute algumas etapas provisórias antes de fazer upgrade para o TFS 2018 Atualização 2. Consulte o gráfico abaixo e a página de instalação do TFS para obter mais informações.
Importante
Não é necessário fazer upgrade para o TFS 2018 RTM antes de fazê-lo para o TFS 2018 Atualização 2.
Data de lançamento do 
sobre a versão: 7 de maio de 2018
Agora você pode atualizar para o TFS 2018 Atualização 2 e continuar a conectar seus controladores XAML e executar builds XAML. Quando o suporte ao build XAML foi removido no TFS 2018 RTW e na Atualização 1, alguns de vocês não conseguiram fazer a atualização porque tinham builds XAML herdados, mas queríamos permitir que vocês a fizessem. Embora o TFS 2018 Atualização 2 dê suporte a builds XAML para os builds herdados, o build XAML foi preterido e não receberá mais nenhum investimento, portanto, é altamente recomendável convertê-lo em um formato de definição de build mais recente.
Resumo das novidades do TFS 2018 Atualização 2
Adicionamos novo valor significativo ao Team Foundation Server 2018 Atualização 2. Alguns dos destaques incluem:
- Exibir confirmação da mesclagem de solicitação de pull
- Ajudar revisores usando rótulos de solicitação de pull
- Mencionar uma solicitação de pull
- As notificações de comentário da solicitação de pull incluem o contexto do thread
- Extensibilidade de status de solicitação de pull
- Filtro de marcação e campos personalizados em notificações de acompanhamento de item de trabalho
- Opções de coluna modernizada
- Suporte adicionado para o operador Não na consulta
- Query for @MyRecentActivity and @RecentMentions
- Filtragem em planos
- Entradas de versão
- Compilar com integração contínua do GitHub Enterprise
- Aprimoramentos em builds de várias fases
- Ignorar builds agendados se nada for alterado no repositório
- Uso direto de pacotes públicos usando fontes upstream
- Políticas de retenção em feeds do TFS
- Filtragem no gerenciamento de pacote
- Pesquisa de wiki
- Itens de trabalho de referência no Wiki
- Visualizar conteúdo ao editar páginas wiki
- Colar conteúdo de wiki avançado como HTML
- Cartões de perfil
- Avatares circulares
Detalhes das novidades do TFS 2018 Atualização 2
É possível encontrar detalhes sobre os recursos em cada área:
Código
Obter um link permanente para o código
Ao exibir um arquivo, você geralmente vê a versão na extremidade do branch selecionado. A versão de um arquivo na extremidade pode ser alterada com novas confirmações. Se você copiar um link nesta exibição, os links poderão se tornar obsoletos porque a URL inclui apenas o nome do branch, não o SHA da confirmação. Agora é possível mudar facilmente a exibição Arquivos para atualizar a URL para se referir à confirmação em vez de ao branch. Se você pressionar a tecla "y", a exibição mudará para a confirmação da extremidade do branch atual. Em seguida, copie os links permanentes.
Recuperar um repositório excluído recentemente por meio da API
Às vezes podem ser cometidos erros ao limpar repositórios antigos no controle do código-fonte. Se um repositório Git tiver sido excluído nos últimos 30 dias, ele poderá ser recuperado por meio da API REST. Consulte a documentação para as operações lista e recuperar para obter mais informações.
SSH: suporte a chaves/criptografias adicionais e substituição das criptografias desatualizadas
Para melhorar a segurança e a compatibilidade, atualizamos a lista de criptografias compatíveis com o SSH. Duas novas criptografias foram adicionadas e três foram preteridas, de acordo com a direção do OpenSSH. As criptografias preteridas continuam a funcionar nesta versão. Elas serão removidas futuramente conforme o uso diminuir.
Adicionado:
- AES128 CTR
- AES256 CTR
Preterido:
- AES128
- AES192
- AES256
Evite substituições e proteja o desempenho usando as configurações do repositório
Nessa atualização, você encontrará duas novas configurações do repositório para ajudar a manter o funcionamento do Git.
Imposição de caso alterna o servidor do modo padrão que diferencia maiúsculas de minúsculas, em que "File.txt" e "file.txt" se referem ao mesmo arquivo, para um modo fácil de usar no Windows e macOS, em que “File.txt” e “file.txt” são o mesmo arquivo. Essa configuração afeta arquivos, pastas, branches e marcações. Ela também impede que colaboradores insiram acidentalmente diferenças somente de maiúsculas e minúsculas. É recomendado habilitar a imposição quando a maioria de seus colaboradores estiver executando Windows ou macOS.
Limitar tamanhos do arquivo permite impedir que arquivos novos ou atualizados excedam um limite de tamanho definido. Quanto maior o número de arquivos grandes que existem no histórico de um repositório Git, pior será o desempenho da operação de busca e clone. Essa configuração impede a inserção acidental desses arquivos.
Capacidade de filtro aprimorada para confirmações com mais de 1.000 arquivos alterados
A procura por um arquivo nas confirmações ou solicitações de pull que modificaram mais de 1.000 arquivos foi ineficiente. É necessário clicar no link Carregar mais várias vezes para localizar o arquivo no qual você estava interessado. Agora, ao filtrar o conteúdo no modo de exibição de árvore, a pesquisa do arquivo é feita em todos os arquivos na confirmação em vez de apenas pesquisando os primeiros 1.000 arquivos carregados. O desempenho da página de detalhes da confirmação também é aprimorado quando há mais de 1.000 arquivos modificados.
Localizar confirmações perdidas devido a um push de força
É possível executar um push de força do Git e atualizar uma ref remota mesmo quando não é um elemento ancestral de ref local. Isso pode causar a perda de confirmações e pode ser muito difícil identificar a causa raiz. No novo modo de exibição de push, tornamos os pushes de força perceptíveis para ajudar a solucionar problemas relacionados à falta de confirmações.
Clicar na marcação de push de força leva você até a confirmação removida.
O Blame agora tem histórico
A exibição do Blame é ótima para identificar a última pessoa que alterou uma linha de código. No entanto, às vezes, você precisa saber quem fez a alteração anterior em uma linha de código. O aprimoramento mais recente no Blame pode ajudar – Exibir o Blame antes dessa confirmação. Como o nome sugere, esse recurso permite voltar no tempo para a versão do arquivo anterior à versão que alterou uma determinada linha, bem como exibir as informações do Blame para essa versão. Você pode continuar a análise de volta no tempo olhando para cada versão do arquivo que alterou a linha de código selecionada.
Alterne a quebra automática de linha e o espaço em branco em modos de exibição de comparação
Dois novos recursos estão disponíveis no visualizador de comparação de arquivo: Ativar/desativar quebra automática de linha e Ativar/desativar espaço em branco. A primeira permite a configuração da quebra automática de linha a ser aplicada em um modo de exibição de comparação. Isso é particularmente útil para revisar PRs que contêm arquivos sem quebras de linha frequentes – arquivos markdown são um bom exemplo. A opção de alternar o espaço em branco é útil apenas quando espaços em branco são alterados em uma linha ou arquivo. Ativar/desativar essa configuração exibe e realça os caracteres de espaço em branco (pontos para espaços, setas para tabs, etc.) na comparação.
Para gerenciar essas configurações, clique na engrenagem de preferências do editor no modo de exibição de comparação ou do editor da solicitação de pull. Na exibição Arquivos, selecione a opção Preferências do usuário no menu e clique com o botão direito do mouse.
Selecione vários recursos do editor incluindo Mostrar e comparar espaço em branco, Habilitar quebra automática de linha, Habilitar dobramento de código e Mostrar minimapa.
O dobramento de código (chamado de "estrutura de tópicos" em alguns editores) também está sendo habilitado para a exibição da web. Quando o dobramento de código estiver habilitado, clique nos sinais de menos para recolher as seções do código – clique nos sinais de mais para expandir as seções recolhidas. A paleta de comandos F1 também apresenta opções para dobrar vários níveis de recuo em um arquivo inteiro, tornando mais fácil de ler e analisar arquivos grandes.
Acompanhe os pushes de código para um repositório Git para builds e versões
Agora você pode exibir o status do build e da versão de confirmações mescladas na página Pushes. Clicando no status ao lado do push, você encontrará a versão ou o build específico no qual o push está incluído para que possa verificar o êxito ou investigar a falha.
Markdown renderizado em notificações por email
O markdown é ótimo para adicionar formatação sofisticada, links e imagens em comentários e descrições de solicitação de pull (PR). As notificações por email para PRs agora exibem o markdown renderizado em vez de conteúdo bruto, o que melhora a legibilidade.
As imagens embutidas ainda não são renderizadas de forma embutida (são mostradas apenas como links), mas isso está em nossa lista de pendências para adicionar no futuro.
Executar comandos TFVC diretamente do Windows Explorer
A extensão do shell de TFVC do Windows, que proporciona uma experiência de controle de versão leve e integrada ao Explorador de Arquivos do Windows, agora é compatível com o TFS 2018. Essa ferramenta fornece acesso conveniente a vários comandos TFVC diretamente no menu de contexto do Windows Explorer.
Anteriormente parte das ferramentas TFS Power, a ferramenta foi lançada como uma ferramenta autônoma no Visual Studio Marketplace.
Controlar quem pode contribuir com solicitações de pull
Anteriormente, qualquer pessoa que pudesse exibir um repositório Git poderia trabalhar com suas solicitações de pull. Adicionamos uma nova permissão chamada Contribuir para solicitações de pull que controla o acesso à criação e à inserção de comentários nas solicitações de pull. Todos os usuários e grupos que tinham anteriormente a permissão de Leitura também receberão essa nova permissão por padrão. A introdução dessa nova permissão dá aos administradores maior flexibilidade e controle. Se precisar que seu grupo Leitores seja realmente somente leitura, você poderá negar a permissão Contribuir para solicitações de pull.
Consulte a documentação de início rápido para configurar permissões do repositório para obter mais informações.
As notificações de comentário da solicitação de pull incluem o contexto do thread
Muitas vezes, as respostas para comentários de PR são muito breves, confirmando que uma alteração será ou foi feita. Isso não é um problema ao exibir esses comentários no modo de exibição da Web, mas se você estiver lendo um comentário em uma notificação por email, o contexto do comentário original será perdido. Um simples "Corrigirei isso" não tem nenhum significado.
Agora, sempre que uma resposta for dada a um comentário de solicitação de pull, os emails de comentário incluirão as respostas anteriores no corpo da mensagem de email. Isso permite que os participantes do thread vejam todo o contexto do comentário diretamente na caixa de entrada, sem a necessidade de abrir a exibição da web.
Concluir as configurações de itens de trabalho
O recurso para concluir os itens de trabalho ao concluir as solicitações de pull agora tem uma nova configuração de repositório para controlar o comportamento padrão. A nova configuração Lembrar preferências do usuário para concluir itens de trabalho com solicitações de pull é habilitada por padrão e manterá o último estado de usuário ao concluir solicitações de pull futuras no repositório. Se a nova configuração estiver desabilitada, a opção Concluir itens de trabalho vinculados após mesclagem é desabilitada por padrão para todas as solicitações de pull no repositório. Os usuários ainda podem optar por itens de trabalho vinculados à transição ao concluir PRs, mas precisarão de consentimento sempre.
Extensibilidade de status de solicitação de pull
Usar políticas de ramificação pode ser uma ótima maneira de aumentar a qualidade do seu código. No entanto, essas políticas foram limitadas apenas às integrações nativamente fornecidas pelo TFS. Ao usar a nova API de Status de solicitação de pull e a política de branch correspondente, serviços de terceiros podem participar do fluxo de trabalho de solicitação de pull como recursos nativos do TFS.
Quando um serviço é publicado na API de status para uma solicitação de pull, ele aparece imediatamente na exibição Detalhes da solicitação de pull em uma nova seção de Status. A seção de status exibe a descrição e cria um link para a URL fornecida pelo serviço. Entradas de status também dão suporte a um menu de ação (...) que é extensível para novas ações adicionadas pelas extensões da Web.
O status em si não impede o preenchimento de uma RP – é aí que entra a política. Depois que o status de PR tiver sido publicado, uma política poderá ser configurada. Com a experiência de políticas de ramificação, uma nova política está disponível para Exigir aprovação de serviços externos. Selecione + Adicionar serviço para iniciar o processo.
Na caixa de diálogo, selecione o serviço que está publicando o status da lista e selecione as opções de política desejadas.
Assim que a política estiver ativa, o status será mostrado na seção Políticas, em Obrigatório ou Opcional conforme apropriado e o preenchimento da PR será aplicado conforme apropriado.
Para saber mais sobre a API de status e experimentar por conta própria, confira a documentação e os exemplos.
Eventos de mesclagem dos ganchos de serviço da solicitação de pull
Extensões usando ganchos de serviço de solicitação de pull agora têm mais detalhes e opções de filtragem para eventos de mesclagem. Sempre que for tentada uma mesclagem, o evento será acionado independentemente do êxito ou da falha da mesclagem. Quando uma tentativa de mesclagem resultar em uma falha, os detalhes sobre o motivo da falha serão incluídos.
Mensagens de erro aprimoradas para itens de trabalho concluídos com uma solicitação de pull
Ao tentar concluir itens de trabalho com uma solicitação de pull, é possível que o item de trabalho associado não possa ser transferido para o estado concluído. Por exemplo, um campo específico pode ser necessário e precisar de entrada do usuário antes que estado possa ser transferido. Melhoramos a experiência para informá-lo quando algo está bloqueando a transição do item de trabalho, permitindo que você adote medidas para fazer as alterações necessárias.
Mencionar uma solicitação de pull
Agora você pode mencionar solicitações de pull nos comentários de PR e discussões de item de trabalho. A experiência para mencionar uma PR é semelhante a de um item de trabalho, mas usa um ponto de exclamação ! em vez de uma marcação de hash #.
Sempre que quiser mencionar uma PR, insira um ! e você verá uma experiência interativa para seleção de uma PR da lista de PRs recentes. Insira palavras-chave para filtrar a lista de sugestões, ou insira a ID da PR que você deseja mencionar. Depois de uma PR ser mencionada, ela será renderizada de forma embutida com a ID e o título completo e, além disso, será vinculada à página de detalhes da PR.
Ajudar revisores usando rótulos de solicitação de pull
Às vezes, é importante comunicar informações extra sobre uma solicitação de pull aos revisores. Talvez a solicitação de pull ainda seja um trabalho em andamento ou um hotfix para uma versão futura. Por isso, acrescente algum texto extra no título, talvez um prefixo "[WIP]" ou "NÃO MESCLAR". Os rótulos agora fornecem uma maneira de marcar solicitações de pull com informações extras que podem ser usadas para comunicar detalhes importantes e ajudar a organizar as solicitações de pull.
Os comentários de solicitação de pull seguem os arquivos renomeados
Às vezes, os arquivos são renomeados ou movidos enquanto uma solicitação de pull está ativa. Anteriormente, se houvesse comentários sobre esses arquivos renomeados, o modo de exibição mais recente do código não os exibiria. Agora melhoramos o rastreamento de comentários para acompanhar as ações de renomear, exibindo comentários na versão mais recente dos arquivos renomeados ou movidos.
Exibir confirmação da mesclagem de solicitação de pull
Modos de exibição de comparação da solicitação de pull são ótimos para realçar as alterações introduzidas no branch de origem. No entanto, as alterações no branch de destino podem fazer com que o modo de exibição de comparação seja diferente do esperado. Um novo comando agora está disponível para exibir comparação da confirmação de mesclagem da "visualização" para a solicitação de pull – Exibir confirmação de mesclagem. Essa confirmação de mesclagem é criada para verificar se há conflitos de mesclagem e para ser usada com uma compilação de solicitação de pull e, além disso, reflete como será a confirmação de mesclagem quando a solicitação de pull eventualmente for concluída. Quando o branch de destino tiver alterações não refletidas na comparação, a comparação de confirmação de mesclagem poderá ser útil para ver as alterações mais recentes nos branches de origem e de destino.
Outro comando útil em conjunto com o comando Exibir confirmação de mesclagem é Reiniciar mesclagem (disponível no mesmo menu de comando). Se o branch de destino for alterado depois que a solicitação de pull for criada inicialmente, a execução desse comando criará uma confirmação de mesclagem de visualização, atualizando a exibição de comparação de confirmação de mesclagem.
Revisores usados recentemente
Se o código for revisado frequentemente pelas mesmas pessoas, adicionar revisores será mais fácil do que nunca. Ao adicionar revisores em solicitações de pull, uma lista de revisores adicionados recentemente é exibida automaticamente quando você direciona o foco para a caixa de entrada de revisores, sem a necessidade de pesquisar por nome. Selecione-os como faria com qualquer revisor.
Exibir critérios de política restantes para preenchimento automático da solicitação de pull
O preenchimento automático é um recurso útil para equipes que usam políticas de branch, mas, ao usar políticas opcionais, pode não ser claro o que exatamente está impedindo a conclusão de uma solicitação de pull. Agora, ao definir o preenchimento automático para uma solicitação de pull, a lista exata dos critérios de política que estão aguardando conclusão claramente é vista na caixa de texto explicativo. Como cada requisito é atendido, os itens são removidos da lista até que não existam requisitos restantes e a solicitação de pull seja mesclada.
Discutir matemática em solicitações de pull
Precisa incluir uma equação ou expressão matemática em seus comentários de solicitação de pull? Agora você pode incluir funções KaTeX em seus comentários usando comentários em bloco e embutidos. Consulte a lista de funções com suporte para obter mais informações.
Sugestões de solicitação de pull para bifurcações
Sempre que um branch do tópico é atualizado em um repositório, é mostrada uma "sugestão" para criar uma solicitação de pull (PR) para o branch do tópico. Esse recurso é muito útil para a criação de novas PRs e também o habilitamos para aqueles que trabalham em um repositório bifurcado. Se atualizar um branch de uma bifurcação, na próxima vez que visitar o hub de Código para o repositório upstream ou a bifurcação, você verá a sugestão para criar uma solicitação de pull. Se selecionar o link "Criar uma solicitação de pull", você será direcionado para a experiência de criar PR, com os branches de origem e de destino e repositórios previamente selecionados.
Filtros de caminho para políticas de solicitação de pull
Muitas vezes, um único repositório contém código que foi criado por vários pipelines de CI (integração contínua) para validar o build e executar testes. A política de compilação integrada agora dá suporte a uma opção de filtragem de caminho que torna fácil configurar vários builds de PR que podem ser necessários e acionados automaticamente para cada PR. Apenas especifique um caminho para cada build para exigir e definir as opções de gatilho e requisito conforme desejado.
Além do build, as políticas de status também têm a opção de filtragem de caminho disponível. Isso permite que políticas personalizadas ou de terceiros configurem a imposição da política para caminhos específicos.
Trabalho
Atalhos de teclado no formulário do item de trabalho
Atribua um item de trabalho a você mesmo (Alt + i), vá para a discussão (Ctrl + Alt + d) e copie um link rápido para o item de trabalho (Shift + Alt + c) usando atalhos de teclado. Para obter a lista completa dos novos atalhos, digite "?" com um formulário de item de trabalho aberto ou consulte a tabela a seguir.
Opções de coluna modernizada
A caixa de diálogo Opções de coluna usada para configurar as colunas da grade de item de trabalho nos hubs Lista de pendências, Consultas e Teste foi atualizada para usar um novo design do painel. Pesquise para localizar um campo, arraste e solte para reordenar as colunas ou remova colunas existentes que você não deseja mais.
Última execução de consulta por informações
À medida que a árvore de Consultas compartilhadas do projeto cresce, pode ser difícil determinar se uma consulta deixou de ser usada e pode ser excluída. Para ajudá-lo a gerenciar suas Consultas compartilhadas, foram adicionadas duas novas partes de metadados às APIs REST de consulta, executado pela última vez por e última data de execução, para que você possa escrever scripts de limpeza para excluir consultas obsoletas.
Marcações HTML eliminadas em grades de item de trabalho
Com base nos comentários dos clientes, atualizamos o comportamento dos campos de texto de várias linhas em exibições de resultados de consulta de item de trabalho na web, Excel e no IDE do Visual Studio para remover a formatação HTML. Quando adicionados como uma coluna à consulta, os campos de texto de várias linhas agora são exibidos como texto sem formatação. Aqui está um exemplo de um recurso com HTML na descrição.
No passado, os resultados da consulta teriam processado algo como <div><b><u>Customer Value</u>...
Suporte adicionado para o operador Não na consulta
Os campos que dão suporte ao operador de consulta “Em” agora dão suporte a "Não Em". Escreva consultas para itens de trabalho "Não em" uma lista de IDs, "Não em" uma lista de estados, e muito mais, sem precisar criar muitas cláusulas "Ou" aninhadas.
Consultar @MyRecentActivity e @RecentMentions
Apresentamos duas novas macros de consulta para o campo ID para ajudá-lo a localizar os itens de trabalho que são importantes para você. Veja em quais itens você foi mencionado nos últimos 30 dias usando @RecentMentions ou dê uma olhada nos itens de trabalho que você visualizou ou editou recentemente usando @MyRecentActivity.
Filtro de marcação e campos personalizados em notificações de acompanhamento de item de trabalho
As notificações agora podem ser definidas usando as condições em marcas e campos personalizados; não apenas quando elas forem alteradas, mas também quando determinados valores forem atendidos, além de permitir um conjunto de notificações mais robusto que pode ser definido para itens de trabalho.
Mencionado suporte para a página Meus itens de trabalho
Adicionamos um novo pivô Mencionado à página Meus itens de trabalho. Dentro desse pivô, você pode revisar os itens de trabalho nos quais foi mencionado nos últimos 30 dias. Com essa nova exibição, você pode rapidamente executar ações nos itens que exigem entrada e manter-se atualizado nas conversas que são relevantes para você.
Esse mesmo pivô também está disponível por meio de nossa experiência móvel, proporcionando consistência entre o desktop e o dispositivo móvel.
Filtragem em planos
A extensão Planos de entrega agora faz uso de nosso componente de filtragem comum, e é consistente com nossas experiências de filtragem de grade para itens de trabalho e Painéis. Esse controle de filtragem fornece usabilidade aprimorada e uma interface consistente para todos os membros da equipe.
Navegação de planos atualizada
Muitos se importam com um plano específico ou um conjunto de planos e usam o Favoritos para acesso rápido ao conteúdo. Primeiro, atualizamos o hub Planos para navegar até o plano visitado mais recentemente em vez da página do diretório. Além disso, você pode usar o seletor de Favoritos para mudar rapidamente para outro plano ou usar a trilha de navegação para navegar de volta para a página de diretório.
Expandir/recolher requisitos/pessoas no painel de tarefas
Agora você pode expandir ou recolher todos os itens no sprint Painel de tarefas com apenas um único clique.
Conceder a permissão de bypassrule a usuários específicos
Geralmente, ao migrar itens de trabalho de outra origem, as organizações desejam manter todas as propriedades originais do item de trabalho. Por exemplo, você talvez queira criar um bug que retenha as datas de criação original e criadas pelos valores do sistema de origem.
A API para atualizar um item de trabalho tem um sinalizador de bypassrule para habilitar esse cenário. Anteriormente, a identidade que fez essa solicitação de API tinha que ser um membro do grupo Administradores de coleção de projeto. Adicionamos uma permissão no nível do projeto para executar a API com o sinalizador de bypassrule.
Build e versão
Builds XAML
No TFS 2015, apresentamos um sistema de build de plataforma cruzada baseado na Web. Os builds XAML não são mais compatíveis com o TFS 2018 RTW, ou Atualização 1, mas eles foram habilitados novamente no TFS 2018 Atualização 2. Incentivamos você a migrar seus builds XAML.
Quando você atualizar para o TFS 2018 Atualização 2:
Se houver dados de build XAML em sua coleção de projetos de equipe, você receberá um aviso informando que os recursos de build XAML foram preteridos.
Você precisará usar o VS ou o Team Explorer 2017 para editar as definições de build XAML ou para colocar novos builds XAML na fila.
Se precisar criar novos agentes de build XAML, você precisará usar o instalador de agente de build do TFS 2015 para instalá-los.
Para saber mais sobre nosso plano de substituição do build XAML, consulte a postagem no blog "Aprimoramento dos recursos de automação de build do TFS/Team Services".
Aprimoramentos em builds de várias fases
Você conseguiu usar fases para organizar suas etapas de build e para direcionar diferentes agentes usando demandas diferentes para cada fase. Adicionamos vários recursos às fases de build para que, agora, seja possível:
Especificar uma fila de agentes diferente para cada fase. Isso significa que você pode, por exemplo:
- Executar uma fase de um build em um agente do macOS e outra fase em um agente do Windows. Para ver um exemplo interessante de como isso pode ser útil, assista a este vídeo do Connect(); 2017: CI/CD DevOps Pipeline for mobile apps and services (Pipeline de DevOps de CI/CD para serviços e aplicativos móveis).
- Executar etapas de build em um pool de agentes de build e etapas de teste em um pool de agentes de teste.
Executar testes mais rapidamente ao executá-los em paralelo. Qualquer fase que tenha paralelismo configurado como “vários agentes” e que contenha uma tarefa de "VSTest" agora paralelizará automaticamente a execução de teste entre a contagem de agentes configurados.
Permitir ou negar que os scripts acessem o token OAuth em cada fase. Isso significa, por exemplo, que agora você pode permitir que scripts em execução em sua fase de build se comuniquem com o VSTS por meio de APIs REST e no mesmo bloco de definição de build que os scripts que estão em execução em sua fase de teste.
Execute uma fase apenas sob condições específicas. Por exemplo, você pode configurar uma fase para execução somente quando as fases anteriores tiverem êxito ou somente quando você estiver compilando código na ramificação principal.
Para saber mais, consulte Fases no build e gerenciamento de versão.
Ignorar builds agendados se nada for alterado no repositório
Por solicitação popular, agora você pode especificar que um build agendado não seja executado quando nada tiver sido alterado no seu código. Você pode controlar esse comportamento usando uma opção no agendamento. Por padrão, não agendaremos um novo build se seu último build agendado (do mesmo agendamento) tiver sido aprovado e nenhuma alteração tiver sido feita em seu repositório.
Compilar com integração contínua do GitHub Enterprise
Agora você tem uma integração melhor para realizar builds de CI (integração contínua) se usar o GitHub Enterprise para controle de versão. Anteriormente, havia limitação na sondagem para alterações de código usando o conector Git externo, que pode ter aumentado a carga nos servidores e causado atrasos antes dos builds serem acionados. Agora, com o suporte do GitHub Enterprise oficial, os builds de CI da equipe são acionados imediatamente. Além disso, a conexão pode ser configurada usando vários métodos de autenticação, como LDAP ou contas integradas.
Arquivos seguros podem ser baixados para agentes durante o build ou a versão
A nova tarefa Baixar arquivo seguro dá suporte ao download de arquivos criptografados (para computadores de agente) da biblioteca dos Arquivos seguros do VSTS. À medida que o arquivo é baixado, ele é descriptografado e armazenado no disco do agente. Quando o build ou a versão é concluída, o arquivo é excluído do agente. Isso permite que o build ou a versão usem arquivos confidenciais, como certificados ou chaves privadas, que são criptografados e armazenados com segurança no VSTS. Para obter mais informações, consulte a Documentação dos arquivos seguros.
Os perfis de provisionamento da Apple podem ser instalados de repositórios de origem
A tarefa Instalar perfil de provisionamento da Apple já dá suporte à instalação de perfis de provisionamento (em computadores de agente) que estão armazenados na biblioteca dos Arquivos seguros do VSTS. Os perfis de provisionamento são usados pelo Xcode para assinar e empacotar aplicativos da Apple, como para iOS, macOS, tvOS e watchOS. Agora, os perfis de provisionamento podem ser instalados de repositórios de código-fonte. Embora o uso da biblioteca de arquivos seguros seja recomendado para maior segurança desses arquivos, essa melhoria aborda perfis de provisionamento já armazenados no controle do código-fonte.
Rastrear fontes do GitHub para builds usando marcações de build
Os builds do GitHub ou GitHub Enterprise já estão vinculados à confirmação relevante. É igualmente importante ser capaz de rastrear uma confirmação até os builds que fazem a compilação. Isso agora é possível ao permitir a marcação de origem no TFS. Ao escolher o repositório do GitHub em uma definição de build, selecione os tipos de builds que deseja marcar, juntamente com o formato da marcação.
Em seguida, veja as marcações do build aparecerem em seu repositório GitHub ou GitHub Enterprise.
Os JDKs (Kits de Desenvolvimento Java) podem ser instalados durante builds e versões
Para compilar determinados projetos Java, JDKs específicos podem ser necessários, mas não estão disponíveis em computadores de agente. Por exemplo, os projetos podem exigir versões mais antigas ou diferentes dos JDKs de software livre, Oracle ou IBM. A tarefa Instalador de ferramenta Java baixa e instala o JDK necessário pelo seu projeto durante um build ou versão. A variável de ambiente JAVA_HOME é definida de acordo com a duração do build ou versão. JDKs específicos podem ser disponibilizados para o Instalador de ferramenta Java usando um compartilhamento de arquivos, um repositório de código-fonte ou um Armazenamento de Blobs do Azure.
Configuração aprimorada do build do Xcode
A tarefa Xcode foi atualizada com uma nova versão principal (4.*) que melhora a configuração de compilação, teste e empacotamento do Xcode. Se seu projeto Xcode tiver um esquema compartilhado único, ele será usado automaticamente. Ajuda adicional embutida foi adicionada. Os recursos preteridos, como empacotamento xcrun, foram removidos das propriedades da tarefa do Xcode. O build existente e as definições da versão devem ser modificados para usar esta versão 4.* mais recente da tarefa do Xcode. Para novas definições, se precisar de recursos preteridos de uma versão anterior da tarefa do Xcode, poderá selecionar essa versão em sua definição.
Entradas de versão
O monitoramento contínuo é parte integrante dos pipelines do DevOps. Garantir que o aplicativo em uma versão esteja íntegro após a implantação é tão importante quanto o sucesso do processo de implantação. As empresas adotam várias ferramentas de detecção automática da integridade do aplicativo em produção e para manter o controle dos incidentes relatados pelo cliente. Até agora, os aprovadores precisavam monitorar manualmente a integridade dos aplicativos de todos os sistemas antes de promover a versão. No entanto, o Gerenciamento de versão agora dá suporte à integração de monitoramento contínuo em pipelines de lançamento. Use isso para garantir que o sistema consulte repetidamente todos os sinais de integridade para o aplicativo até que todos eles obtenham êxito ao mesmo tempo, antes de continuar a liberação.
Comece definindo entradas de pré-implantação ou pós-implantação na definição da versão. Cada entrada pode monitorar um ou mais sinais de integridade correspondentes a um sistema de monitoramento do aplicativo. Entradas integradas estão disponíveis para "alertas do monitor do Azure (insight de aplicativo)" e "Itens de trabalho". Você pode fazer a integração com outros sistemas usando a flexibilidade oferecida por meio de funções do Azure.
No momento da execução, a versão inicia a amostragem de todas as entradas e coleta os sinais de integridade de cada uma delas. Ela repetirá a amostragem a cada intervalo até que os sinais coletados de todas as entradas no mesmo intervalo sejam bem-sucedidos.
Amostras iniciais entre os sistemas de monitoramento podem não ser precisas, pois pode não haver informações suficientes disponíveis para a nova implantação. A opção "Atraso antes da avaliação" garante que a versão não progrida durante esse período, mesmo se todas as amostras tiverem êxito.
Nenhum agente ou pipeline é consumido durante a amostragem de entradas. Consulte a documentação para as entradas de versão para obter mais informações.
Implantar seletivamente com base no artefato disparando uma versão
Várias fontes de artefatos podem ser adicionadas a uma definição da versão e configuradas para disparar uma versão. Uma nova versão é criada quando um novo build está disponível para qualquer uma das fontes. O mesmo processo de implantação é executado independentemente de qual origem disparou a versão. Agora você pode personalizar o processo de implantação com base na origem do gatilho. Para versões disparadas automaticamente, a variável de versão Release.TriggeringArtifact.Alias agora é preenchida para identificar a origem do artefato que disparou a versão. Isso pode ser usado em condições de tarefas, condições de fase e parâmetros da tarefa para ajustar dinamicamente o processo. Por exemplo, se você apenas precisar implantar os artefatos que foram alterados pelos ambientes.
Gerenciar a segurança específica da entidade
Anteriormente na segurança com base em função, quando as funções de acesso de segurança foram definidas, elas foram definidas para um usuário ou grupo no nível do hub para grupos de implantação, grupos de variáveis, filas de agente e pontos de extremidade de serviço. Agora é possível ativar e desativar a herança de uma entidade específica, assim você pode configurar a segurança do modo que desejar.
Aprovar vários ambientes
Agora é mais simples gerenciar aprovações com as versões. Para pipelines com o mesmo aprovador para vários ambientes com implantação em paralelo, o aprovador atualmente precisa agir em cada uma das aprovações separadamente. Com esse recurso, agora você pode concluir várias aprovações pendentes ao mesmo tempo.
Extensibilidade do modelo de versão
Os modelos de versão permitem criar uma linha de base para começar com a definição do processo de versão. Anteriormente, era possível carregar novos em sua conta, mas agora os criadores podem incluir modelos da versão em suas extensões. Você pode encontrar um exemplo no repositório do GitHub.
Fases e tarefas de versão condicional
Semelhante às tarefas de build condicional, agora você poderá executar uma tarefa ou fase apenas se condições específicas forem atendidas. Isso ajudará na modelagem de cenários de reversão.
Se as condições internas não atenderem às suas necessidades, ou se precisar de um controle mais refinado quando a tarefa ou fase for executada, você poderá especificar condições personalizadas. Expressar a condição como um conjunto aninhado de funções. O agente avalia a função mais interna e faz o trabalho. O resultado é um valor booliano que determina se a tarefa deve ser executada.
Histórico de solicitações para pontos de extremidade de serviço
Pontos de extremidade de serviço habilitam a conexão a serviços externos e remotos para executar tarefas para um build ou implantação. Os pontos de extremidade são configurados no escopo do projeto e compartilhados entre vários builds e definições da versão. Os proprietários do ponto de extremidade de serviço agora podem obter uma exibição consolidada de builds e implantações usando um ponto de extremidade, o que pode ajudar a melhorar a auditoria e a governança.
As propriedades padrão para tipos de artefato do Git e GitHub agora são editáveis
Agora você pode editar as propriedades padrão dos tipos de artefato do Git e GitHub mesmo depois de o artefato ter sido vinculado. Isso é particularmente útil em cenários nos quais o branch para a versão estável do artefato foi alterado, e versões contínuas futuras devem usar esse branch para obter versões mais recentes do artefato.
Implantar ambientes em massa manualmente da exibição de lançamento
Agora é possível disparar manualmente uma ação de implantação em vários ambientes de uma versão ao mesmo tempo. Isso permite que você selecione vários ambientes em uma versão com as configurações com falha ou implantações e implante novamente para todos os ambientes em uma única operação.
Suporte Jenkins de pipeline de vários branches e trabalhos vinculados organizados em pastas
Consumir projetos do Jenkins ficou ainda melhor.
Primeiramente, agora é possível consumir projetos do Jenkins de pipeline de vários branches como fontes de artefatos em uma definição da versão.
Em segundo lugar, enquanto anteriormente era possível vincular projetos do Jenkins como artefatos somente na pasta raiz de um servidor Jenkins, agora os projetos Jenkins podem ser consumidos quando organizados em nível de pasta. Você vê a lista de projetos Jenkins, juntamente com os caminhos de pasta, na lista de fontes na qual é possível selecionar o projeto a ser consumido como origem do artefato.
Hub do Docker ou Registro de Contêiner do Azure como uma origem do artefato
Esse recurso permite que as versões usem imagens armazenadas em um registro de Hub do Docker ou um ACR (Registro de Contêiner do Azure). Esta é a primeira etapa para dar suporte a cenários como implantar novas alterações região a região usando o recurso de replicação geográfica de ACR ou implantando em um ambiente (por exemplo, produção) de um registro de contêiner que contém imagens somente para o ambiente de produção.
Agora você pode configurar o ACR ou o Hub do Docker como um artefato de primeira classe na experiência do artefato + Adicionar de uma definição da versão. Agora a versão deve ser disparada manualmente ou por outro artefato, mas estamos ansiosos para adicionar um gatilho com base no push de uma nova imagem para o registro em breve.
Versões do artefato padrão
Agora há várias opções de versão padrão durante a vinculação de artefatos de controle de versão para uma definição da versão. Você pode configurar uma confirmação ou um conjunto de alterações específico ou simplesmente configurar a versão mais recente que será selecionada do branch padrão. Normalmente você faz a configuração para selecionar a versão mais recente, mas isso é especialmente útil em alguns ambientes nos quais uma versão de artefato gold precisa ser especificada para todas as futuras implantações contínuas.
Aprimoramentos de branch dos gatilhos de versão
Agora é possível configurar um filtro de gatilho de versão com base no branch padrão especificado na definição de build. Isso é particularmente útil se seu branch de build padrão é alterado a cada sprint e os filtros de gatilho de versão precisam ser atualizados em todas as definições da versão. Agora você precisa apenas alterar o branch padrão na definição de build e todas as definições da versão usam automaticamente esse branch. Por exemplo, se sua equipe estiver criando branches de versão para cada payload de versão do sprint, faça a atualização na definição de build para apontar para um novo branch de versão de sprint e a versão escolherá isso automaticamente.
Gatilho de versão para um artefato de gerenciamento de pacote
Agora você pode definir um gatilho em um artefato de Gerenciamento de Pacotes em uma definição de versão para que uma nova versão seja criada automaticamente quando uma nova versão do pacote for publicada. Consulte a documentação para gatilhos em Gerenciamento de versão para obter mais informações.
Definir o escopo de um grupo de variáveis para ambientes específicos
Anteriormente, quando um grupo de variáveis era adicionado a uma definição da versão, as variáveis contidas nele estavam disponíveis para todos os ambientes na versão. Agora, você tem flexibilidade para definir o escopo dos grupos de variáveis para ambientes específicos. Isso os disponibiliza para um ambiente, mas não para outros da mesma versão. Isso é ótimo quando você tem um serviço externo, como um serviço de email SMTP, que é diferente entre ambientes.
Liberar automaticamente do Registro de Contêiner do Azure e do Hub do Docker
Ao implantar aplicativos em contêineres, a imagem de contêiner é enviada pela primeira vez para um registro de contêiner. Após o push ser concluído, a imagem de contêiner pode ser implantada para um Aplicativo Web para Contêineres ou um cluster do Kubernetes. Agora você pode habilitar a criação automática de versões em atualizações para as imagens armazenadas no Hub do Docker ou Registro de Contêiner do Azure fazendo a adição como uma origem do artefato.
Especifique uma versão padrão para artefatos do Jenkins
Quando uma versão com vários artefatos é disparada automaticamente, as versões padrão salvas na definição da versão são selecionadas para todos os artefatos. Anteriormente, os artefatos do Jenkins não tinham uma configuração de versão padrão e não era possível definir um gatilho de implantação contínua em uma versão usando o Jenkins como o artefato secundário.
Agora, é possível especificar uma versão padrão para artefatos do Jenkins, com as opções com as quais você está familiarizado:
- Última
- Especificar a hora da criação de versão
- Versão específica
Contribuir entradas de versão de extensões
As entradas de versão habilitam a adição de aprovações orientadas a informações para os pipelines de lançamento. Um conjunto de sinais de integridade é coletado repetidamente, antes ou após a implantação, para determinar se a versão deve ser promovida para o próximo estágio ou não. Um conjunto de entradas internas é fornecido, e "Invocar a função do Azure" foi recomendada até o momento como um meio para integração com outros serviços. Agora, podemos simplificar a rota para integração com outros serviços e adicionar entradas por meio de extensões do marketplace. Você pode contribuir tarefas de entrada personalizadas e fornecer aos criadores de definição de versão uma experiência aprimorada para configurar a entrada.
Saiba mais sobre criação de tarefas de entrada.
Dimensione as implantações para máquinas virtuais usando Grupos de implantação
Grupos de Implantação, que fornecem implantação robusta e pronta para vários computadores, agora estão disponíveis. Com os Grupos de Implantação, você pode orquestrar implantações em vários servidores e executar atualizações sem interrupção enquanto garante a alta disponibilidade do seu aplicativo completamente. Você também pode implantar servidores locais ou máquinas virtuais no Azure ou em qualquer nuvem, além de ter rastreabilidade de ponta a ponta de versões do artefato implantado, até o nível de servidor.
A funcionalidade de implantação com base em agente depende dos mesmos agentes de build e implantação que já estão disponíveis. Você pode usar o catálogo de tarefas completo em seus computadores de destino na fase Grupo de implantação. De uma perspectiva de extensibilidade, você também pode usar as APIs REST para grupos de implantação e destinos para acesso programático.
Pacote
Uso direto de pacotes públicos usando fontes upstream
Fontes upstream para nuget.org e npmjs.com agora estão disponíveis. Os benefícios incluem a capacidade de gerenciar (remover da lista, substituir, cancelar a publicação, excluir, etc.) pacotes salvos por meio de fontes upstream, bem como a garantia de salvar cada pacote de upstream.
Políticas de retenção em feeds do TFS
Até o momento, feeds de pacote do TFS ainda não forneciam uma maneira de limpar automaticamente versões mais antigas e não usadas do pacote. Para publicadores de pacote frequentes, isso poderia resultar em consultas de feed mais lentas no gerenciador de pacotes do NuGet e em outros clientes até que algumas versões fossem excluídas manualmente.
Agora habilitamos as políticas de retenção em feeds do TFS. As políticas de retenção excluirão automaticamente a versão mais antiga de um pacote quando o limite de retenção for atingido. Pacotes promovidos a modos de exibição são mantidos por tempo indeterminado, fornecendo a capacidade de proteger as versões que são usadas na produção ou amplamente usadas em sua organização.
Para habilitar as políticas de retenção, edite seu feed e insira um valor em Número máximo de versões por pacote na seção Políticas de retenção.
Filtragem no gerenciamento de pacote
A página Pacotes foi atualizada para usar nosso layout da página padrão, o controle da barra de comando e a nova barra de filtro padrão.
Compartilhar seus pacotes usando uma notificação
Na comunidade de software livre, é comum usar uma notificação com vínculo para a versão mais recente do seu pacote no LEIAME do repositório. Agora você pode criar notificações para pacotes em seus feeds. Apenas marque a opção Habilitar notificações de pacote nas configurações do feed, selecione um pacote e, em seguida, clique em Criar notificação. Você pode copiar a URL de notificação diretamente ou copiar o Markdown gerado previamente que vincula a notificação de volta à página de detalhes do pacote.
As versões anteriores do pacote agora são uma lista de página inteira
Recebemos muitos comentários sobre a experiência de Gerenciamento de Pacotes atualizada, na qual movemos a lista de versões anteriores do pacote em um seletor de navegação na página de detalhes do pacote. Adicionamos um novo pivô Versões que fornece mais informações sobre as versões anteriores e facilita a cópia do número de versão ou a obtenção de um link para uma versão antiga.
Exibir qualidade de uma versão do pacote na lista de pacotes
Na lista de pacotes, agora é possível ver as exibições de cada versão do pacote para determinar rapidamente a qualidade. Consulte a documentação das exibições de lançamento para obter mais informações. ) para obter mais informações.
Gulp, Yarn e mais suporte de feed autenticado
Atualmente, a tarefa npm funciona perfeitamente com feeds npm autenticados (no Gerenciamento de Pacotes ou registros externos, como npm Enterprise e Artifactory), mas até agora era desafiador usar um executor de tarefas como o Gulp ou um cliente alternativo npm como o Yarn, a menos que essa tarefa também desse suporte a feeds autenticados. Adicionamos uma nova tarefa de build Autenticação npm que adiciona credenciais ao seu .npmrc para que as tarefas subsequentes possam usar feeds autenticados com êxito.
As permissões padrão de feed do pacote agora incluem administradores do projeto
No passado, criar um feed definia o usuário de criação como o único proprietário do feed, o que poderia causar desafios de administração em grandes organizações se esse usuário trocasse de equipe ou deixasse a organização. Para remover esse ponto único de falha, agora a criação de feed usa o contexto do projeto atual do usuário para obter o grupo Administradores do projeto e também o tornar um proprietário do feed. Assim como acontece com qualquer permissão, você pode remover este grupo e personalizar ainda mais as permissões de feed usando a caixa de diálogo de configurações do feed.
Reciclar e restaurar os pacotes
Excluir pacotes não utilizados pode ajudar a manter a lista de pacotes limpa, mas, às vezes, isso pode ser feito por engano. Agora você pode restaurar da Lixeira os pacotes excluídos. Os pacotes excluídos são mantidos na lixeira por 30 dias, fornecendo bastante tempo para restauração se você precisar.
Vincular pacotes de qualquer lugar
Embora fosse possível compartilhar a URL com um pacote encontrado no hub Pacotes no passado, geralmente era difícil usar esse recurso porque era necessário incluir um projeto na URL, que podia ou não ser aplicável aos que usavam o link. Com essa atualização, agora é possível compartilhar usando uma URL que seleciona automaticamente um projeto ao qual o destinatário tem acesso.
O formato da URL é: 'https://< TFSserverURL>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package'
Todos os parâmetros, exceto '<TFSserverURL>', são opcionais, mas se você fornecer um pacote, deverá fornecer o tipo de protocolo.Teste
A tarefa de teste do Visual Studio não precisa do Visual Studio completo
A tarefa do Visual Studio Test no build/versão requer o Visual Studio no agente para executar testes. Em vez de instalar o Visual Studio para executar testes em ambientes de produção ou para simplesmente distribuir testes em vários agentes, use a nova tarefa do instalador de plataforma do Visual Studio Test. Essa tarefa adquire a plataforma de teste do nuget.org e adiciona-a ao cache de ferramentas. A tarefa do instalador satisfaz a demanda de vstest e uma tarefa subsequente do Visual Studio Test na definição pode ser executada sem a necessidade de uma instalação completa do Visual Studio no agente.
No catálogo da tarefa, adicione a tarefa do instalador em sua definição.
Configure a tarefa subsequente do Visual Studio Test para usar os bits adquiridos por meio do instalador.
Observação
Limitações: atualmente, o pacote da plataforma de teste no NuGet não dá suporte à execução do teste de IU codificado. A habilitação do suporte para teste de IU codificado está na lista de pendências. O pacote da plataforma de teste no NuGet é multiplataforma, mas a tarefa do VSTest atualmente não dá suporte à execução de testes de .NET Core. Para executar testes do .NET Core, use a tarefa 'dot net'.
As tarefas Executar testes funcionais e Implantar agente de teste foram preteridas
Ano passado, começamos a jornada para unificar os agentes nos builds, versões e testes. O objetivo foi abordar vários pontos problemáticos associados ao uso do WinRM com base nas tarefas Implantar o agente de teste e Executar testes funcionais. Isso também permite que você use a tarefa do VSTest (Visual Studio Test) para todas as suas necessidades de teste, incluindo:
- Testes de unidade
- Testes funcionais (interface do usuário/sem interface do usuário)
- Testes com base em MSTest
- Testes com base em estruturas de terceiros
- Especificação de teste com base em assembly ou execução de testes com o conjunto de testes/plano de teste
- Execução de teste único de agente, bem como distribuição de testes por vários agentes
A abordagem de agentes unificados também permite que os administradores gerenciem todos os computadores usados para CI/CD de maneira uniforme.
Fornecemos várias partes essenciais para habilitar esse recurso, incluindo:
- Os agentes podem ser configurados para teste de interface do usuário
- O instalador de plataforma do Visual Studio Test permite que a tarefa VSTest seja executada sem a necessidade do Visual Studio previamente instalado
- As definições de versão e build podem ser criadas com várias fases e ter a capacidade de usar filas de agentes diferentes para cada fase
- Casos de teste automatizados podem ser executados por meio do hub de teste usando a tarefa VSTest
Com tudo acima em funcionamento, você estará pronto para substituir essas duas tarefas. Enquanto as definições existentes que usam as tarefas preteridas continuarão a funcionar, é recomendável fazer a migração usando o VSTest para aproveitar o aprimoramento contínuo ao longo do tempo.
Filtrar resultados de teste grandes
Com o tempo, os ativos de teste acumulam e os aplicativos grandes podem facilmente chegar a milhares de testes. As equipes procuram melhores maneiras de navegar por grandes conjuntos de resultados de teste para serem produtivas ao identificar falhas de teste, a causa raiz associada ou a propriedade de problemas. Para habilitar isso, adicionamos três novos filtros na guia Testes em Compilação e versão como Nome do teste, Contêiner (DLLs) e Proprietário (proprietário do contêiner).
Além disso, o filtro Resultado existente agora fornece a capacidade de filtrar para vários resultados. Os vários critérios de filtro são cumulativos por natureza. Como usuário, quando quero ver o resultado dos meus testes para uma alteração que acabei de confirmar, posso filtrar por Contêiner (nome da DLL), Proprietário (proprietário da DLL) ou Nome do teste ou por todos eles, para obter os resultados relevantes para mim.
Identificar testes instáveis
Às vezes, os testes são instáveis. Eles falham em uma execução e aprovam outra sem quaisquer alterações. Os testes instáveis podem ser frustrantes e prejudicar a confiança na eficácia do teste, fazendo com que falhas sejam ignoradas e bugs passem despercebidos. Com essa atualização, implantamos a primeira parte de uma solução para ajudar a enfrentar o problema de testes instáveis. Agora é possível configurar a tarefa do Visual Studio Test para executar novamente os testes com falha. Os resultados do teste indicam quais testes inicialmente falharam e, em seguida, foram aprovados na nova execução. O suporte para nova execução de testes ordenados e direcionados por dados será disponibilizado posteriormente.
A tarefa do Visual Studio Test pode ser configurada para controlar o número máximo de tentativas para executar novamente os testes com falha e um percentual do limite de falhas (por exemplo, somente executar novamente os testes se menos de 20% de todos os testes falharem) para evitar a nova execução de testes em caso de falhas amplas.
Na guia Testes, em Build e versão, você pode filtrar os resultados de teste com o resultado como "Aprovado na nova execução" para identificar os testes que tiveram um comportamento não confiável durante a execução. Atualmente, isso mostrará a última tentativa de cada teste aprovado na nova execução. O modo de exibição de resumo também é modificado para mostrar "Aprovado na nova execução (n/m)" em testes totais, em que n é a contagem de testes aprovados na nova execução e m é o total de testes aprovados. Uma exibição hierárquica de todas as tentativas poderá ser vista nos próximos sprints.
Aprimoramentos de versão prévia e suporte para tipos diferentes de log gerados pela tarefa do Visual Studio Test
Aprimoramos a tarefa do VSTest para publicar logs gerados por diferentes tipos de instruções de registro correspondentes na saída padrão e erro padrão para testes com falha. Também melhoramos a experiência de visualização para dar suporte ao texto de exibição e formatos do arquivo de log com a capacidade de pesquisar nos arquivos de log.
Wiki
Pesquisa de wiki
É possível pesquisar suas páginas wiki favoritas por título ou conteúdo diretamente no código e nos itens de trabalho. Você pode ler mais sobre a Pesquisa de wiki no blog Microsoft DevOps.
Imprimir páginas wiki
Wiki pode ser usado para vários conteúdos. Às vezes, pode ser útil a impressão de conteúdo do Wiki para ler em seu tempo livre, adicionar comentários usando caneta e papel ou até mesmo compartilhar uma cópia em PDF offline com aqueles fora de seu projeto do VSTS. Agora, basta clicar no menu de contexto de uma página e selecionar Página de impressão.
Observação
Atualmente, esse recurso não tem suporte no Firefox.
Contribuir com páginas wiki com facilidade usando atalhos de teclado
Agora você pode usar atalhos para executar ações comuns de exibição e edição no Wiki ainda mais rapidamente usando apenas o teclado.
Ao exibir uma página, é possível adicionar, editar ou criar uma subpágina, por exemplo:
Ao editar uma página, você pode salvar rapidamente, salvar e fechar ou apenas fechar.
São adições aos atalhos de edição padrão, como Ctrl + B para negrito, Ctrl + I para itálico, Ctrl + K para vinculação, etc. Consulte a lista completa de atalhos de teclado para obter mais informações.
Renderização de markdown avançada em markdown de repositório de código
Agora você pode criar arquivos LEIAME.MD avançados nos repositórios de código. A renderização de markdown dos arquivos MD nos repositórios de código agora dá suporte a marcações HTML, citações do bloco, Emojis, redimensionamento de imagens e fórmulas matemáticas. Há uma paridade em renderização de markdown nos arquivos de Wiki e MD no código.
O Wiki dá suporte a fórmulas matemáticas
Se o aplicativo lida com fórmulas matemáticas e equações, agora você pode colocá-las no Wiki usando o formato LaTeX.
Referenciar itens de trabalho no wiki
Agora você pode referenciar itens de trabalho em páginas wiki pressionando a tecla '#' para obter uma lista dos itens de trabalho acessados mais recentemente e selecionando aquele em que você tem interesse. Isso é particularmente útil ao criar notas de versão, epics, especificações ou outras páginas que exigem referência a um item de trabalho.
Vincular itens de trabalho e páginas wiki
Agora é possível vincular um item de trabalho a um wiki e vice-versa. É possível vincular itens de trabalho ao wiki para criar páginas épicas, notas de versão e planejar conteúdo que ajuda você a rastrear os itens de trabalho associados a uma página da Wiki e validar o percentual de conclusão da sua página épica.
Depois de fazer isso, itens de trabalho vinculados aparecem na página wiki.
Adicione um link a uma página wiki de um item de trabalho por meio do novo tipo de link de "Página wiki".
Ctrl+S para salvar a página wiki
Ouvimos que você desejava uma maneira mais rápida e fácil de salvar uma página Wiki. Agora você pode usar apenas o atalho de teclado Ctrl + S para salvar uma página com uma mensagem de revisão padrão e continuar a editar. Se quiser adicionar uma mensagem personalizada de revisão, basta clicar na divisa ao lado do botão de salvar.
Colar conteúdo de wiki avançado como HTML
Agora você pode colar rich text no Markdown editor do Wiki por meio de qualquer aplicativo baseado em navegador, como o Confluence, o OneNote, o SharePoint e o MediaWiki. Isso é particularmente útil para quem que criou conteúdo avançado, como tabelas complexas, e deseja mostrá-lo no Wiki. Basta copiar o conteúdo e colar como HTML.
Mover a página no wiki usando o teclado
Anteriormente no Wiki, os usuários não podiam reordenar ou reatribuir pais às páginas usando o teclado e isso afetava os usuários que preferiam operações de teclado. Agora é possível reordenar as páginas usando os comandos Ctrl + seta para cima ou Ctrl + seta para baixo. Também é possível reatribuir pais às páginas clicando em Mover página no menu de contexto de uma página e selecionar a nova página pai para mover.
Filtrar realce de texto
Filtrar o painel de navegação no Wiki mostra toda a hierarquia de página. Por exemplo, se filtrar uma página chamada "foobar", o painel de navegação filtrado também mostrará todas as páginas pai. Isso pode causar confusão sobre o motivo pelo qual as páginas não intituladas "foobar" estão sendo mostradas nos conjuntos de resultados filtrados. Agora, a filtragem de conteúdo no Wiki realça o texto que está sendo pesquisado para fornecer uma visão clara dos títulos que estão filtrados e os que não estão.
Você também observará um comportamento semelhante em todos os painéis de navegação de código. Por exemplo, o painel de navegação do arquivo nas solicitações de pull, confirmações, conjuntos de alterações e check-in particular.
Visualizar conteúdo ao editar páginas wiki
Os dados mostram que os usuários quase sempre visualizam uma página wiki várias vezes ao editar o conteúdo. Para editar cada página, os usuários clicam em Visualização de uma a duas vezes, em média. Isso resulta em uma experiência de edição lenta e abaixo do ideal e pode ser muito demorado para os iniciantes em markdown. Agora você pode ver a versão prévia da página durante a edição.
Geral
Cartões de perfil
Há várias áreas no TFS em que as informações associadas a um indivíduo específico são mostradas, como, sem limitações: solicitações de pull criadas por itens individuais, itens de trabalho atribuídos a um indivíduo etc. No entanto, há informações limitadas sobre o indivíduo em si para que você possa obter o contexto completo. O novo cartão de perfil substitui o cartão de perfil existente no TFS. O cartão de perfil atualizado permite interagir e saber mais sobre os usuários em sua conta do TFS. Por meio de integrações com seu email padrão e o cliente de mensagens instantâneas, os usuários do AD (Active Directory) podem enviar emails e iniciar chats diretamente do cartão de perfil. Os usuários do AD também podem ver a hierarquia organizacional dentro do cartão de perfil. Os cartões de perfil podem ser ativados na página inicial do projeto – seção de membros da equipe, controle de versão, itens de trabalho e seções Wiki, clicando no ícone de cartão de visita, imagem do perfil ou nome de usuários com comentários.
Avatares circulares
Os avatares circulares estão aqui! Todas as imagens de perfil no serviço agora são exibidas em uma forma circular, em vez de um quadrado. Por exemplo, aqui está a solicitação de pull real para essa alteração (observe os avatares circulares, não quadrados).
Marcações de projeto
Agora é possível inserir nos projetos palavras-chave importantes (marcações). As marcações são facilmente adicionadas e excluídas diretamente da página inicial do projeto (por administradores) permitindo que os usuários entendam mais sobre a finalidade e o escopo do projeto. Temos mais planejamentos sobre como as marcações de projeto podem ser utilizadas, por isso, fique atento para obter mais novidades aqui.
Reordenar grupos favoritos
Agora é possível reordenar os grupos na página Meus favoritos da conta usando as setas para cima e para baixo em cada cabeçalho de grupo.
Comentários e Sugestões
Adoraríamos ouvir sua opinião! Relate um problema e acompanhe-o por meio da Comunidade de Desenvolvedores e receba consultoria no Stack Overflow.