Notas de versão do Team Foundation Server 2018 RC1

Last Update: 25/09/2017

Neste artigo, você encontrará informações sobre a versão mais recente do Team Foundation Server 2018 RC1. Clique no botão para baixar.

Baixar a versão mais recente do Team Foundation Server

Para saber mais sobre o Team Foundation Server 2018, consulte a página Requisitos e compatibilidade do Team Foundation Server.


Comentários

Adoraríamos ouvir sua opinião! Relate um problema e acompanhe-o por meio da Comunidade de Desenvolvedores e receba consultoria no Stack Overflow. Como sempre, se você tiver ideias sobre as coisas que gostaria que priorizássemos, vá para UserVoice para adicionar sua ideia ou votar em uma existente.


Data de lançamento: 30 de agosto de 2017

Resumo: atualizações do Team Server Foundation no TFS 2018 RC1

Adicionamos um novo valor significativo ao Team Foundation Server 2018. Alguns dos destaques incluem:

Resumo: novidades desta versão

Recursos removidos com esta versão:


Detalhes: novidades desta versão

Acompanhamento de item de trabalho

Assistente de criação de projeto na Web

Melhoramos a experiência para criar um Projeto de equipe do acesso via web. Agora, ele inclui a maioria dos recursos que estão disponíveis ao criar um Projeto de equipe no cliente do Visual Studio. A vantagem de usar a interface da Web é que não precisa de uma versão correspondente do Visual Studio. A diferença de usar o Visual Studio ou a versão da Web é que a versão da Web não provisionar seus relatórios no SSRS. Se você usou a versão da web da criação do Projeto de equipe, poderá executar o comando tfsconfig na Camada de aplicativo para provisionar ou atualizar os relatórios do SSRS. Consulte os detalhes em Adicionar relatórios de projeto.

Gerenciador do modelo de processo na Web

Com o TFS 2018, você pode usar o acesso via Web para carregar os modelos de processo. A interface da web é uma experiência muito mais fácil, porque você não precisa instalar a versão correta do Visual Studio para interagir com os modelos de processo. O Visual Studio 2017 atualização 4 e anteriores ainda mostrarão a caixa de diálogo Gerenciador do modelo de processo, embora, seja recomendável usar a interface da Web. O Visual Studio 2017 Atualização 5 e posterior o redirecionará para a Web automaticamente.

Formulário de item de trabalho móvel

Temos uma experiência de ponta a ponta completa que inclui uma aparência otimizada para itens de trabalho (Figura 1) e fornece uma maneira fácil de interagir com os itens que são atribuídos a você, que você estiver seguindo ou que você visitou, ou editou recentemente, de seu telefone.

Consulta de item de trabalho móvel

(Figura 1) Consulta de item de trabalho móvel

Juntamente com a boa aparência, essa experiência oferece suporte a controles otimizados para todos os tipos de campo (Figura 2).

Formulário de item de trabalho móvel

(Figura 2) Formulário de item de trabalho móvel

Com a nova navegação móvel (Figura 3), os usuários podem acessar outras partes prontamente móveis do TFS e voltar para o site de área de trabalho completo caso precisam interagir com outros hubs.

Navegação móvel

(Figura 3) Navegação móvel

Filtrando listas de pendências, quadros Kanban, sprints e consultas

Todas as nossas experiências da grade de acompanhamento do item de trabalho (consultas, listas de pendências, quadro Kanban quadros, listas de pendências de sprints e gerenciamento de casos de teste) agora usam nosso componente comum e consistente de filtragem (Figura 4). Além de aplicar um filtro de palavra-chave em colunas exibidas e marcas de seleção, também é possível filtrar por tipo de item de trabalho, estado e atribuídos a na ordem rapidamente para obter os itens de trabalho que está procurando.

Filtragem em consultas

(Figura 4) Filtragem em consultas

Expanda para mostrar os campos vazios em um cartão Kanban

Atualmente, você tem a opção de adicionar campos a um cartão e, em seguida, ocultar campos vazios (Figura 5) nas configurações de quadro para remover resíduos desnecessários do quadro. A desvantagem para esse recurso era que, depois que um campo vazio era ocultado, a única maneira de atualizar o campo era abrir o formulário de item de trabalho. Com a recém disponível opção de expandir em cartões Kanban, agora você pode aproveitar para ocultar campos vazios em todos os segmentos, mas ainda terá um acesso por um único clique para atualizar um campo específico em um cartão. Simplesmente passe o mouse sobre o cartão e procure na divisa para baixo na parte inferior do cartão para atualizar o campo oculto.

Campo oculto

(Figura 5) Campo oculto no cartão Kanban

Clique na divisa para baixo na parte inferior do cartão para atualizar o campo (Figura 6).

Atualizar campo oculto

(Figura 6) Atualizar campo oculto no cartão Kanban

Extensões de bloqueio de salvamento de item de trabalho

Os controles, grupos e páginas personalizados de formulário de item de trabalho agora podem agora bloquear o salvamento do item de trabalho para validar dados e garantir que o usuário preencha todas as informações necessárias antes de salvar o formulário de item de trabalho.

Controle de versão

Forks

O 2018 TFS adiciona suporte para forks de Git (Figura 7). Um fork é uma cópia do lado do servidor de um repositório. Ao usar forks, você pode permitir que uma ampla gama de pessoas contribua para o repositório sem conceder a elas o acesso direto de confirmação. Em vez disso, eles confirmam seu trabalho em seu próprio fork do repositório (Figura 7). Isso lhe dá a oportunidade de examinar suas alterações em uma solicitação de pull antes de aceitar as alterações no repositório central.

Forks de Git

(Figura 7) Forks de Git

Configuração para desligar a edição Web para repositórios TFVC

As equipes que usam TFVC geralmente usam políticas de check-in no Visual Studio para garantir a qualidade do código. No entanto, como as políticas de check-in são aplicadas no cliente, o código que está sendo editado na Web não está sujeito às mesmas políticas.

Várias pessoas pediram por uma forma de desabilitar a edição pela Web para protegerem-se contra alterações que ignoram as políticas de check-in. Habilitamos uma maneira para que você desligue a edição pela Web (Adicionar, excluir, renomear e editar) para TFVC com base em repositório/projeto.

Para desativar a edição pela Web da página Arquivos, acesse Configurações, em seguida, Controle de versão (Figura 8). Clique no repositório TFVC na árvore, navegue até a dinâmica Opções e desmarque Habilitar edição da Web para este repositório TFVC. Por padrão, a edição pela web está habilitada. Observação: a edição do arquivo README da página de Visão geral do projeto não será afetada.

Desligar a edição da Web

(Figura 8) Desligar a edição da Web

Se você tentar uma edição da Web em um projeto com a edição da Web desabilitada, receberá uma notificação de que ela não é permitida (Figura 9).

Caixa de diálogo de edição da Web não permitida

(Figura 9) Caixa de diálogo de edição da Web não permitida

Isso foi desenvolvido com base em uma sugestão relacionada.

Identificar ramificações obsoletas

Manter seu repositório limpo excluindo ramificações que não são mais necessárias permite às equipes localizar ramificações com que se importam e definir favoritos na granularidade certa. No entanto, se você tiver muitas ramificações em seu repositório, poderá ser difícil descobrir quais estão inativas e podem ser excluídas. Agora facilitamos a identificação de ramificações "obsoletas" (ramificações que apontam para confirmações com mais de 3 meses). Para ver suas ramificações obsoletas, vá para a dinâmica Obsoleto na página Ramificações (Figura 10).

Ramificações obsoletas

(Figura 10) Ramificações obsoletas

Pesquisar por uma ramificação excluída e recriá-la

Quando uma ramificação é acidentalmente excluída do servidor, pode ser difícil de descobrir o que aconteceu com ela. Agora você pode pesquisar por uma ramificação excluída, consultar quem a excluiu e quando e criá-la novamente se desejar.

Para pesquisar por uma ramificação excluída, digite o nome completo da ramificação na caixa de pesquisa de ramificação. Isso retornará todas as ramificações existentes que correspondem a esse texto. Você também verá uma opção para pesquisar por uma correspondência exata na lista de ramificações excluídas. Clique no link para pesquisar por ramificações excluídas (Figura 11).

Pesquisar por ramificações excluídas

(Figura 11) Pesquisar por ramificações excluídas

Se uma correspondência for encontrada, você verá quem a excluiu e quando. Também é possível restaurar a ramificação (Figura 12).

Restaurar ramificações excluídas

(Figura 12) Restaurar ramificações excluídas

Restaurar a ramificação a recriará na confirmação para a qual ela foi apontada pela última vez. No entanto, isso não restaurará políticas e permissões.

Pesquisar por uma confirmação em ramificações começando com um prefixo

Se você tiver a estrutura de ramificação em um formato hierárquico em que todas as ramificações são prefixadas com um texto, esse recurso ajudará a localizar uma confirmação em todas as ramificações que começam com esse texto de prefixo. Por exemplo, se quiser ver se uma confirmação chegou para todas as ramificações que são prefixados com "desenvolvimento", então, simplesmente digite "desenvolvimento" na caixa de pesquisa e selecione Pesquisar em ramificações que começam com "desenvolvimento" (Figura 13).

Pesquisar por uma confirmação

(Figura 13) Pesquisar por uma confirmação

Texto explicativo mais rico de solicitação de pull na página de detalhes de confirmação

O texto explicativo de solicitação de pull na página de confirmação de detalhes mostra informações mais relevantes para ajudá-lo a diagnosticar mais bem (Figura 14). Agora também mostramos a primeira solicitação de pull que introduziu a confirmação para qualquer ramificação e a solicitação de pull associada com a ramificação padrão no texto explicativo.

Texto explicativo de solicitação de pull

(Figura 14) Texto explicativo de solicitação de pull

Filtrar modo de exibição de árvore no código

Agora não é mais necessário percorrer todos os arquivos que uma confirmação pode ter modificado somente para obter seus arquivos. O modo de exibição de árvore na página de detalhes do conjunto de alterações, detalhes de solicitações de pull, detalhes do check-in particular e detalhes de confirmação agora dá suporte à filtragem de arquivos e pasta. Este é um filtro inteligente que mostra os arquivos filho de uma pasta quando você filtrar por nome de pasta e mostra um modo de exibição de árvore recolhido de um arquivo para mostrar a hierarquia do arquivo ao filtrar por nome de arquivo.

Localizar um filtro de arquivo ou pasta na árvore de confirmação (Figura 15) e (Figura 16):

Encontrar um arquivo ou pasta

(Figura 15) Encontrar um arquivo ou pasta

modo de exibição filtrado

(Figura 16) Modo de exibição filtrado na árvore de confirmação

A página de atualizações de ramificação agora é Pushes

A página Atualizações da ramificação tem um grande valor. No entanto, ele foi oculta como uma área dinâmica no hub Histórico. Agora a página de atualizações de ramificação estará visível como um hub chamado Pushes (Figura 17) em Código, junto com Confirmações, Ramificações, Marcas e Solicitações de pull. A nova URL para a página de pushes é: <tfsserverurl>/<projectname>/_git/<reponame>/pushes. As URLs antigas continuarão a funcionar.

Página Pushes

(Figura 17) Página Pushes

Ao mesmo tempo, o hub Histórico agora está renomeado como Confirmações (Figura 18) uma vez que o hub mostra somente as confirmações. Recebemos comentários de que pessoas estavam achando difícil solucionar problemas relacionados à confirmação porque o modo de exibição de lista de confirmação apenas mostrava o tempo detalhado ao passar o mouse sobre ela. Agora, o modo de exibição de lista de confirmação em sua instância mostrará data e hora no formato dd/mm/aa hh: mm. A nova URL para a página de confirmações é: <tfsserverurl>/<projectname>/_git/<reponame>/commits. As URLs antigas continuarão a funcionar.

Página Confirmações

(Figura 18) Página Confirmações

Manter o nome do arquivo ao mover de arquivos para confirmações

Ouvimos comentários de pessoas que, quando elas filtravam o diretório para um arquivo específico na área dinâmica Arquivos do hub Código e o invertiam posteriormente para a área dinâmica Histórico, o nome do arquivo não persistia se a confirmação alterasse mais de 1.000 arquivos. Isso fazia com que as pessoas precisassem carregar mais arquivos e filtrar o conteúdo para localizar o arquivo afetando assim a produtividade. Normalmente, os desenvolvedores trabalham no mesmo diretório e desejam continuar nos diretórios em que trabalham à medida que acompanham as alterações. Agora, mantemos o nome do arquivo enquanto você muda entre as áreas dinâmicas de hub Código independentemente do número de arquivos alterados em uma confirmação. Isso significa que não é mais preciso clicar em Carregar mais para localizar o arquivo desejado.

Exibir marcas de Git

É possível exibir todas as marcas no seu repositório na página Marcas (Figura 19). Se você gerenciar todas as marcas como versões, um usuário poderá visitar a página de marcas para obter uma visão geral de todas as versões do produto.

Exibir marcas de Git

(Figura 19) Exibir marcas de Git

É possível diferenciar facilmente entre uma marca leve e uma anotada aqui, pois marcas anotadas mostram o marcador e a data de criação junto com a confirmação associada, enquanto marcas leves mostram apenas as informações de confirmação.

Excluir marcas de Git

Pode haver ocasiões em que você deseja excluir uma marca de seu repositório remoto. Isso pode ocorrer devido a um erro de digitação no nome da marca ou pela marcação de confirmação errada. É possível excluir facilmente marcas da interface do usuário da Web clicando no menu de contexto de uma marca na página Marcas e selecionando Excluir marca (Figura 20).

Observação: excluir marcas no repositório remoto deve ser realizado com cuidado.

Excluir marcas de git

(Figura 20) Excluir marcas de Git

Filtragem de marcas de Git

Para repositórios antigos, o número de marcas pode crescer significativamente com o tempo; também pode haver repositórios que têm marcas criadas em hierarquias, o que podem dificultar a localização de marcas.

Se não for possível localizar a marca que está procurando na página de marcas, então, basta pesquisar pelo nome da marca usando o filtro na parte superior da página Marcas (Figura 21).

Filtrar marcas de Git

(Figura 21) Filtrar marcas de Git

Segurança de marcas de Git

Agora é possível conceder permissões granulares a usuários do repositório para gerenciar marcas. Você pode dar aos usuários a permissão para excluir marcas ou gerenciar marcas dessa interface (Figura 22).

Segurança de marca de Git

(Figura 22) Segurança de marca de Git

Leia mais sobre marcas de Git no blog Microsoft DevOps.

Preencher automaticamente itens de trabalho ao preencher solicitações de pull

Se estiver vinculando itens de trabalho a PRs, manter tudo atualizado ficou mais simples. Agora, quando você preenche uma PS, terá a opção de preencher automaticamente os itens de trabalho vinculados depois de a RP ter sido mesclada com êxito (Figura 23). Se estiver usando políticas e definir PRs para preenchimento automático, a mesma opção aparecerá. Não há mais a necessidade de lembrar-se de rever os itens de trabalho para atualizar o estado depois de preencher a RP. Isso será feito automaticamente para você.

Preencher itens de trabalho vinculados

(Figura 23) Preencher itens de trabalho vinculados

Redefinir os votos no push/nova iteração

As equipes que optam por um fluxo de trabalho de aprovação mais restrito em PRs agora podem optar por aceitar a redefinição de votos quando novas alterações forem enviadas por push (Figura 24). A nova configuração é uma opção na política para Exigir um número mínimo de revisores.

Redefinir configuração de votos

(Figura 24) Redefinir configuração de votos

Quando definida, esta opção fará com que todos os votos de todos os revisores sejam redefinidos sempre que a ramificação de origem da RP for atualizada. A linha do tempo da PR gravará uma entrada sempre que os votos forem redefinidos como resultado dessa opção(Figura 25).

Redefinir votos na linha do tempo

(Figura 25) Redefinir votos na linha do tempo

Filtrar árvore de solicitações de pull por nome de arquivo

Localizar um arquivo específico em uma solicitação de pull está mais fácil do que nunca. A nova caixa de filtro no modo de exibição Arquivos permite que os usuários filtrem a lista de arquivos no modo de exibição de árvore (Figura 26).

Encontrar arquivo ou pasta na solicitação de pull

(Figura 26) Encontrar arquivo ou pasta na solicitação de pull

O filtro corresponde a qualquer parte do caminho dos arquivos na solicitação de pull, para que você possa pesquisar por nomes de pasta, caminhos parciais, nomes de arquivos ou extensões (Figura 27).

Localizar resultados

(Figura 27) Localizar resultados

Mais opções de filtragem de comentários de solicitação de pull

Os comentários na visão geral da solicitação de pull e no modo de exibição de arquivos agora têm as mesmas opções (Figura 28). Também é possível filtrar para ver discussões de que participou.

Filtragem de comentário de PR

(Figura 28) Filtragem de comentário PR

Exibir diff original para comentários de código nos detalhes da solicitação de pull

Às vezes, é difícil compreender um comentário de PR depois que o código que ela referencia é alterado (muitas vezes, depois que uma alteração solicitada é realizada) (Figura 29).

Exibir diff original

(Figura 29) Exibir diff original

A partir de agora, quando isso acontecer, será exibida uma notificação com um número de atualização que poderá ser clicado para exibir como o código era no momento em que o comentário foi criado originalmente (Figura 30).

Atualizar notificação

(Figura 30) Atualizar notificação

Comentários da solicitação de pull recolhíveis

Revisar o código é uma parte fundamental da experiência de solicitação de pull, portanto, adicionamos novos recursos para tornar mais fácil para os revisores se concentrarem no código. Os revisores de código podem ocultar comentários facilmente para tirá-los do caminho ao revisar o novo código pela primeira vez (Figura 31).

Ocultar comentários

(Figura 31) Ocultar comentários

Ocultar comentários (Figura 32) oculta-os do modo de exibição de árvore e recolhe os threads de comentários no modo de exibição de arquivo:

Comentários recolhidos

(Figura 32) Comentários recolhidos

Quando os comentários são recolhidos, eles podem ser expandidos facilmente clicando no ícone na margem e recolhidos novamente com outro clique. As dicas de ferramenta (Figura 33) permitem espiar facilmente um comentário sem exibir o thread inteiro.

Dica de ferramenta de comentário recolhido

(Figura 33) Dica de ferramenta de comentário recolhido

Listas de tarefas em comentários e descrições de solicitação de pull

Ao preparar uma RP ou comentar, às vezes, você tem uma pequena lista de coisas que deseja acompanhar, mas acaba editando o texto ou adicionando vários comentários. Listas de tarefas leves são uma ótima maneira de acompanhar o progresso em uma lista de tarefas como um criador de PR ou revisor na descrição ou em um comentário único e consolidado. Clique na barra de ferramentas Markdown para iniciar ou aplicar o formato ao texto selecionado (Figura 34).

Barra de ferramentas da lista de tarefas

(Figura 34) Barra de ferramentas da lista de tarefas

Depois de adicionar uma lista de tarefas (Figura 35), basta marcar as caixas para marcar os itens como concluídos. Eles são expressos e armazenados com o comentário como [ ] e [x] em Markdown. Para obter mais informações, consulte Diretrizes de markdown.

Lista de tarefas

(Figura 35) Lista de tarefas

Capacidade de "Curtir" comentários em solicitações de pull

Demonstre seu apoio a um comentário de PR com um único clique no botão curtir (Figura 36). É possível ver a lista de todas as pessoas que curtiram o comentário passando o mouse sobre o botão.

Curtir comentários de solicitações de pull

(Figura 36) Curtir comentários de solicitações de pull

Fluxo de trabalho aperfeiçoado ao aprovar com sugestões

Usar a opção de preenchimento automático (Figura 37) com as solicitações de pull é uma ótima maneira de aumentar a produtividade, mas não deve encurtar nenhuma discussão ativa com revisores de código. Para facilitar ainda mais essas conversas, o voto Aprovar com sugestões agora aparecerá quando uma solicitação de pull for definida para ser preenchida automaticamente. O usuário terá a opção de cancelar o preenchimento automático para que seus comentários possam ser lidos ou manter a definição de preenchimento automático e permitir que a solicitação de pull seja preenchida automaticamente quando todas as políticas forem cumpridas.

Caixa de diálogo Cancelar preenchimento automático

(Figura 37) Caixa de diálogo Cancelar preenchimento automático

Suporte de filtragem de caminho para notificações de Git

Em vez de receber notificações para todas as pastas em um repositório, agora você pode escolher ser notificado quando os membros da equipe criarem solicitações de pull ou código de push apenas nas pastas que sejam importantes para você. Ao criar assinaturas personalizadas de notificação por email de solicitações de push do Git ou de pull do Git, você verá uma nova opção para filtrar essas notificações por caminho de pasta (Figura 38).

Filtragem de caminho para notificações

(Figura 38) Filtragem de caminho para notificações

Ótimos modelos de email para fluxos de trabalho de solicitação de pull

Os alertas de solicitação de pull por email foram atualizados para ficar claros, concisos e acionáveis (Figura 39). A linha de assunto começa com o título da PR e, as informações secundárias, como nome do repositório e a ID, serão enviadas para o final. O nome do autor foi adicionado ao assunto para tornar mais simples aplicar regras e filtros com base na pessoa que criou a PR.

O corpo dos emails de alerta tem um modelo atualizado que resume primeiro porque o alerta foi enviado, seguido dos metadados críticos (título, nomes de ramificação e descrição) e um botão de plano de ação principal. Detalhes adicionais, como os revisores, arquivos e confirmações estão incluídos mais adiante no email.

Modelo de email aprimorado

(Figura 39) Modelo de email aprimorado

Para a maioria dos alertas, o plano de ação (Figura 40) será exibir a solicitação de pull na Web. No entanto, quando você é notificado sobre um comentário específico, o plano de ação será vinculado diretamente para esse comentário para que seja possível localizar facilmente o código e a conversa anterior para o contexto.

Plano de ação do email

(Figura 40) Plano de ação do email

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 VSTS. Ao usar a nova API de Status de PR e a política de ramificação correspondente, serviços de terceiros podem participar do fluxo de trabalho da PR como recursos nativos do VSTS.

Quando um serviço é postado na API de Status para uma solicitação de pull, ele aparecerá imediatamente no modo de exibição Detalhes da PR em uma nova seção Status (Figura 41). 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 e o menu de ação (...) que é extensível para que novas ações sejam adicionados pelas extensões de web.

Seção de status de PR

(Figura 41) Seção de status de PR

Apenas o status não bloqueia o preenchimento de uma RP – que é onde 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 (Figura 42).

Adicionar nova política

(Figura 42) Adicionar nova política de PR

Na caixa de diálogo, selecione o serviço que está postando o status da lista e selecione as opções de política desejadas (Figura 43).

Definir política de status

(Figura 43) Definir política de status de PR

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.

Wiki

Agora, cada projeto dá suporte ao seu próprio wiki (Figure 44). Agora é possível escrever convenientemente páginas que ajudam os membros da equipe a entender, usar e contribuir para o seu projeto.

Página Wiki

(Figura 44) Página Wiki de PR

Alguns dos principais recursos do novo Wiki incluem:

  • Experiência de edição simplificada usando a sintaxe de markdown.
  • A nova página permite que você especifique um título e adicione conteúdo. (Figura 45) Title wiki

    (Figura 45) wiki Título da PR

  • Suporte para marcas HTML em markdown (Figura 46).

Marcas HTML de Wiki

(Figura 46) Marcas HTML de Wiki de PR

  • Redimensione as imagens de maneira conveniente na pasta de markdown (Figura 47).

Redimensionamento de imagem

(Figura 47) Redimensionamento de imagem de PR

  • Painel de gerenciamento de página avançado que permite reordenar, definir novo pai e gerenciar páginas.
  • Capacidade de filtrar páginas por título de wikis grandes (Figura 48).

Menu de Wiki

(Figura 48) Menu de Wiki de PR

Saiba mais sobre guia de Introdução ao Wiki.

  • Como você usa mais o Wiki, há uma possibilidade de salvar alterações não intencionais. Agora é possível reverter uma revisão para uma página de wiki, acessando os detalhes da revisão e clicando no botão Reverter (Figura 49).

Botão reverter do Wiki

(Figura 49) Botão reverter do Wiki de PR

Criar uma página de wiki de um link desfeito Durante a criação do wiki, observamos um padrão em que as pessoas criam um sumário em uma página de wiki que inclui links inexistentes (Figura 50). Assim, as pessoas clicariam nesses links para criar as páginas reais. Em nossa experiência anterior, tratávamos esse cenário fornecendo um aviso sugerindo que o link estava desfeito ou que a página não existia. Agora, lidamos com isso como um cenário principal para Wiki, permitindo que você crie páginas em vez disso.

Criar página wiki

(Figura 50) Criar página wiki de PR

A extensão Wiki no Marketplace agora está preterida. Se você for um usuário de extensão Wiki existente, será possível migrar suas páginas wiki para o novo wiki usando uma ferramenta de migração. Saiba mais sobre como migrar suas páginas wiki existentes para o novo Wiki.

Gerenciamento de Pacotes

Atualizações da experiência de gerenciamento de pacotes

URLs de pacote agora trabalham com o nome e versão do pacote, em vez de usar GUIDs. Isso facilita a criação manual de URLs de pacote (Figura 50). O formato é: <tfsserverurl>/<project|team>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package.

URL de pacote

(Figura 51) URL de pacote de PR

Agora é possível ocultar as versões de pacote excluídas (Figura 52) de todos os usuários do feed (não há mais pacotes tachados!), em resposta a esta sugestão do UserVoice.

Ocultar pacotes excluídos

(Figura 52) Ocultar pacotes excluídos

Qualquer ação que você pode executar na página de detalhes do pacote agora pode ser executada no menu de contexto na lista de pacotes.

A lista de pacotes contém uma nova coluna Enviado por push pela última vez (Figura 53) com datas compreensíveis para que você possa localizar com facilidade os pacotes atualizados recentemente.

Coluna Enviado por push pela última vez

(Figura 53) Coluna Enviado por push pela última vez

Pacotes maven

Lançamos o suporte para hospedagem de artefatos Maven no TFS 2018 (Figura 54)! Artefatos Maven permitem aos desenvolvedores de Java compartilhar facilmente o código e componentes. Confira nosso guia de Introdução de como compartilhar artefatos Maven usando o Gerenciamento de pacote.

Pacotes Maven

(Figura 54) Pacotes Maven

Nova tarefa NuGet unificada

Combinamos a tarefa Restauração do NuGet, Empacotador do NuGet e Publicador do NuGet em uma tarefa de build NuGet unificada para alinhar mais bem com o restante da biblioteca de tarefas de build; a nova tarefa usa NuGet 4.0.0 por padrão. Da mesma forma, preterimos as tarefas antigas e recomendamos mudar para a nova tarefa NuGet assim que possível. Essa alteração coincide com uma onda de melhorias descritas a seguir que você só poderá acessar usando a tarefa combinada.

Como parte desse trabalho, também lançamos uma nova tarefa de Instalador de ferramenta NuGet que controla a versão do NuGet disponível no caminho e é usada pela nova tarefa do NuGet. Portanto, para usar uma versão mais recente do NuGet, basta adicionar uma tarefa do Instalador de Ferramenta NuGet no início de seu build (Figura 55).

Tarefa Nuget

(Figura 55) Tarefa NuGet

Opção "Permitir que duplicatas sejam ignoradas" do NuGet

Ouvimos de diversos clientes do NuGet que elas geram um conjunto de pacotes, com apenas alguns deles podendo ter atualizações (e, portanto, números de versão atualizados). A tarefa de build NuGet tem uma nova opção Permitir que duplicatas sejam ignoradas que permitirá que a tarefa continue se tentar enviar pacotes por push para um feed de VSTS/TFS em que a versão já está em uso.

Atualizações de tarefa de build de npm

Independentemente de você estar criando seu projeto npm em Windows, Linux ou Mac, a nova tarefa de build NPM funcionará perfeitamente. Também reorganizamos a tarefa para que a instalação de npm e publicação de npm ficassem mais fáceis. Para instalar e publicar, simplificamos a aquisição de credencial para que as credenciais para registros listados no arquivo de .npmrc do projeto possam ser armazenadas com segurança em um ponto de extremidade de serviço. Como alternativa, se você estiver usando um feed do VSTS/TFS, temos um seletor que permitirá que a seleção de um feed e, em seguida, geraremos um .npmrc com as credenciais necessárias que são usadas pelo agente de build.

O Maven agora dá suporte a feeds autenticados

Diferentemente do NuGet e npm, a tarefa de build Maven não funcionava anteriormente com feeds autenticados. Nós atualizamos a tarefa Maven para que você possa trabalhar facilmente com feeds do VSTS/TFS (Figura 56).

Tarefa dotnet

(Figura 56) Tarefa dotnet

A tarefa dotnet oferece suporte a feeds autenticados, projetos da web

A próxima versão principal da tarefa dotnet (2. x) resolve muitas de suas solicitações por comentários e corrige um conjunto de bugs já acompanhávamos por um tempo.

  1. Primeiro, o dotnet agora dá suporte fontes de pacotes autenticados como o Gerenciamento de pacote, para que você não precise usar mais a tarefa NuGet para restaurar os pacotes de fontes de pacote privadas.
  2. O comportamento do campo Caminho para o(s) projeto(s) foi alterado na versão 2.0 da tarefa. Em versões anteriores da tarefa, se os arquivos de projeto que correspondem ao padrão especificado não forem encontrados, a tarefa registrava um aviso e, em seguida, prosseguia. Nesses cenários, às vezes, é difícil entender por que o build prosseguiu, mas as dependências não foram restauradas. Agora, a tarefa falhará se os arquivos de projeto que correspondem ao padrão especificado não forem encontrados. Isso está de acordo com o comportamento de outras tarefas e é fácil de entender e usar.
  3. Em versões anteriores do comando de publicação da tarefa, a tarefa modificava o caminho de saída colocando todos os arquivos em uma pasta que era nomeada com o nome do arquivo de projeto, mesmo quando você passava um caminho de saída explícito. Isso dificulta a junção dos comandos. Agora você tem controle sobre o arquivo de caminho de saída.

Também lançamos uma nova tarefa de Instalador de ferramenta dotnet que controla a versão do dotnet disponível no caminho e é usada pela nova tarefa dotnet. Portanto, para usar uma versão mais recente do dotnet, basta adicionar uma tarefa do Instalador de ferramenta dotnet no início do seu build.

Trabalho fora de sua conta/coleção

Agora é mais fácil trabalhar com feeds de fora da sua conta do VSTS ou do servidor TFS, independentemente de serem feeds do Gerenciamento de Pacotes em outra conta do VSTS ou em outro servidor TFS ou feeds que não sejam do Gerenciamento de Pacotes, como NuGet.org/npmjs.com, Artifactory ou MyGet (Figura 57). Tipos de Ponto de extremidade de serviço dedicados para NuGet e npm facilitam inserção das credenciais corretas e habilitam as tarefas de build para funcionar perfeitamente em operações de download do pacote e operações de envio do pacote por push.

Feeds para usar

(Figura 57) Feed pra usar

Seletor de feed para feeds de VSTS/TFS

É sempre recomendável fazer check-in de um arquivo de configuração (por exemplo, NuGet. config, .npmrc etc.) para que o repositório de origem tenha um registro de onde vieram seus pacotes. No entanto, fomos informados de um conjunto de cenários em que isso não é o ideal, portanto, adicionamos a nova opção Usar pacotes deste feed do VSTS/TFS, que permite que você selecione um feed e gere automaticamente um arquivo de configuração que será usado para essa etapa de build (Figura 58).

Seletor de feed

(Figura 58) Seletor de feed

Build e versão

Remoção do suporte para builds XAML

No TFS 2015, apresentamos um sistema de build de plataforma cruzada baseado na Web. No TFS 2018, esse é o único modelo ao qual oferecemos suporte. Não há suporte para builds XAML no TFS 2018. Incentivamos você a migrar seus builds XAML. Se ainda não estiver pronto para migrar e precisar continuar usando builds XAML, então, não atualize para o TFS 2018.

Quando você atualiza para o TFS 2018:

  • Se tiver qualquer dado de build XAML em sua coleção de projetos de equipe, um aviso sobre a remoção dos recursos de build XAML será enviado.

  • No TFS 2018, você poderá exibir builds XAML concluídos, mas não conseguirá enfileirar novos.

  • Não há nenhuma nova versão do controlador de build XAML ou do agente no TFS 2018 e não é possível configurar uma versão mais antiga do agente ou do controlador de build XAML para trabalhar com o TFS 2018.

Para obter uma explicação do nosso plano de substituição de build XAML, consulte esta postagem do blog.

Exportar e importar definições de build

Definições de build são implementadas internamente como arquivos. json, para que você possa ver detalhes sobre as alterações no histórico do arquivo. Já é possível clonar e criar modelos de suas definições de build, mas muitos usuários desejam fazer uma cópia de sua lógica de build e reutilizá-la em outro projeto de equipe. Na verdade, isso foi uma das dez principais solicitações no UserVoice.

Temos o prazer de anunciar que agora você pode fazer isso (Figura 59) e (Figura 60)!

Exportar definição de build

(Figura 59) Exportar definição de build

Importar definição de build

(Figura 60) Importar definição de build

Extensões com modelos de build

Modelos de build permitem criar uma linha de base para os usuários iniciarem com a definição do processo de build. Fornecemos diversos deles inclusos hoje e, embora você possa carregar novos à sua conta, nunca foi possível para os autores de extensão incluir novos modelos como parte de uma extensão. Agora você pode incluir modelos de build em suas extensões. Por exemplo:

{  "id": "Template1", 
   "type": "ms.vss-build.template", 
   "targets": [ "ms.vss-build.templates" ], 
   "properties": { "name": "Template1" } }

Para um exemplo completo, consulte https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.

Dica

É possível usar essa funcionalidade para oferecer e compartilhar o mesmo modelo personalizado em todos os seus projetos de equipe.

Substituir uma tarefa em uma extensão

Agora você pode substituir uma tarefa em sua extensão. Para que isso funcione, é necessário adicionar a seguinte variável à versão mais recente da tarefa:

"deprecated": true

Quando o usuário procura tarefas preteridas (Figura 61), nós enviamos essas tarefas por push para o final e as agrupamos em uma seção recolhível que fica recolhida por padrão. Se uma definição já estiver usando uma tarefa preterida, mostramos uma notificação de tarefa preterida incentivar os usuários a alternar para a substituição.

Notificação de tarefa preterida

(Figura 61) Notificação de tarefa preterida

Você pode ajudar os usuários a aprenderem a tarefa de substituição mencionando-a na descrição da tarefa (Figura 62). A descrição, em seguida, apontará as pessoas que usam a tarefa na direção certa do catálogo de tarefas e das definições de build/versão existentes.

Descrição de tarefa preterida

(Figura 62) Descrição de tarefa preterida

Permitir que as seções de build controlem a visibilidade da seção

Anteriormente, se você estivesse usando uma extensão que tinha tarefas de build e seções de resumo de build, veria a seção de resumo de build mesmo se não estivesse usando a tarefa de build nesse build. Agora, é possível optar por ocultar ou mostrar essa seção na página de resumo de build, adicionando a seguinte linha no seu código de extensão e configurar o valor como true ou false:

VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);

Exibir o exemplo incluído no repositório de exemplos de extensão vsts da Microsoft.

Suporte de grupo de variáveis

Os grupos de variáveis estiveram disponíveis para uso nas definições de versão e agora estão prontos para serem usado em definições de build também. Saiba mais sobre a criação de um grupo de variáveis. Isso foi desenvolvido e priorizado com base nas sugestões relacionados para variáveis de build/versão de nível de projeto e grupos de variáveis em definições de build.

Trabalhar com arquivos seguros como certificados da Apple

Adicionamos uma biblioteca de arquivos seguros de uso geral (Figura 63).

Biblioteca de arquvos seguros

(Figura 63) Biblioteca de arquivos seguros

Use a biblioteca de arquivos seguros para armazenar arquivos como assinatura de certificados, perfis de provisionamento da Apple, arquivos de armazenamento de chaves Android e chaves de SSH no servidor sem a necessidade de confirmá-los em seu repositório de origem.

O conteúdo de arquivos seguros é criptografado e só pode ser usado durante os processos de build ou versão referenciando-os partir de uma tarefa. Arquivos seguros estão disponíveis em diversas definições de build e versão no projeto de equipe com base nas configurações de segurança. Arquivos seguros seguem o modelo de segurança da biblioteca.

Também adicionamos algumas tarefas Apple que aproveitam esse novo recurso:

Novo editor de definição de versão

Padrão de aceitar padrão: o novo editor de definição de versão é aceito por padrão para todos. Você ou seus administradores de TFS ainda terão a opção de desativá-lo indo até a opção Recursos de versão prévia no menu do perfil. Consulte Recursos de versão prévia para obter mais detalhes.

Continuando em nossa jornada de atualização das experiências de Build e Versão, depois do novo editor de definição de build, reimaginamos nosso editor de definição de versão para torná-lo uma experiência mais limpa e intuitiva, corrigimos alguns pontos problemáticos e adicionamos novos recursos. Um dos recursos mais avançados do novo editor é sua capacidade para ajudá-lo a criar um modelo mental ou visualizar como as implantações em seus ambientes avançariam. Além disso, as definições de aprovações, de ambiente e de implantação agora estão no contexto e podem ser configuradas facilmente (Figura 65).

Visualização do pipeline

O pipeline (Figura 64) no editor fornece uma exibição gráfica de como as implantações progredirão em uma versão. Os artefatos serão consumidos pela versão e implantados nos ambientes. O layout e a vinculação dos ambientes refletem as configurações do gatilho definidas para cada ambiente.

Pipeline

(Figura 64) Pipeline de versão

Interface do usuário de configuração no contexto

Artefatos, gatilhos de versão, aprovações pré-implantação e pós-implantação, propriedades de ambiente e configurações de implantação agora estão no contexto e podem ser configurados facilmente (Figura 65).

Configuração de versão

(Figura 65) Configuração de versão

Introdução aos modelos de implantação

Uma lista de modelos (padrão e personalizados) é mostrada ao criar um novo ambiente para que seja fácil começar (Figura 66).

Modelos de implantação

(Figura 66) Modelos de implantação

Editor de fase e tarefa aprimorado

Todas as melhorias no novo editor de definição de build agora também estão disponíveis no editor de definição de versão (Figura 67). É possível pesquisar tarefas e adicioná-las usando o botão Adicionar ou usando arrastar/soltar. Você pode reorganizar ou clonar tarefas usando arrastar/soltar.

Editor de tarefas

(Figura 67) Editor de tarefas

Guias Grupos de variáveis, Retenção e Opções

Agora, é possível vincular/desvincular a grupos de variáveis (Figura 68), definir a política de retenção para ambientes individuais e modificar as configurações de nível de definição de versão como o formato de número de versão da guia Opções. Também é possível salvar um ambiente como um modelo de implantação, definir permissões de nível de ambiente e reordenar fases na guia Tarefas.

Grupos de variáveis

(Figura 68) Grupos de variáveis

Use as operações de nível de ambiente para salvar como modelo e definir a segurança (Figura 69).

Menu de ambiente

(Figura 69) Menu de ambiente

Implantação da VM usando grupos de implantação

O Release Management agora dá suporte à implantação avançada de vários computadores por padrão. Agora você pode orquestrar implantações em vários computadores e executar atualizações sem interrupção enquanto garante a alta disponibilidade do aplicativo completamente.

A funcionalidade de implantação com base em agente depende dos mesmos agentes de build e implantação. No entanto, ao contrário da abordagem atual em que você instala os agentes de build e implantação em um conjunto de servidores de proxy em implantações de pool e unidade de um agente em servidores de destino remoto, instale o agente em cada um dos seus servidores de destino diretamente e gera a implantação sem interrupção para esses servidores. Você pode usar o catálogo de tarefas completo em seus computadores de destino.

Um grupo de implantação (Figura 70) é um grupo lógico de destinos (computadores) com agentes instalados em cada um deles. Grupos de implantação representam seus ambientes físicos, como desenvolvimento integrado, garantia de qualidade de vários computador e um farm de máquinas para UAT/Prod. Eles também especificam o contexto de segurança para seus ambientes físicos.

Grupos de implantação

(Figura 70) Grupos de implantação

Você pode usar isso em qualquer VM com a qual registrar nosso agente. Também facilitamos o registro com o Azure com suporte para uma extensão de VM do Azure que automaticamente instala o agente quando a VM acelerar. Herdaremos automaticamente as marcas na VM do Azure quando ela for registrada.

Assim que você tiver um grupo de implantação, bastará configurar o que deseja que seja executado nesse grupo de implantação (Figura 71). É possível controlar o que é executado em quais computadores usando as marcas e controlar a velocidade da distribuição.

Configurar grupos de implantação

(Figura 71) Configurar grupos de implantação

Quando a implantação for executada, os logs mostrarão a progressão em todo o grupo de computadores pretendidos (Figura 72).

Progresso do grupo de implantação

(Figura 72) Progresso do grupo de implantação

Esse recurso agora é parte integrante do Release Management. Não há nenhuma licença adicional necessária para usá-lo.

Referências do grupo de tarefas

Os grupos de tarefas permitem que você defina um conjunto de tarefas que pode adicionar a suas definições de build ou versão. Isso é útil se precisar usar o mesmo agrupamento de tarefas em várias builds ou versões. Para ajudá-lo a acompanhar os consumidores de um grupo de tarefas, agora há uma exibição de definições de build, de definições de versão e de grupos de tarefas que referenciam seu grupo de tarefas (Figura 73).

Referências de grupo de tarefas

(Figura 73) Referências de grupo de tarefas

Quando você tentar excluir um grupo de tarefas que ainda é referenciado, o avisaremos e forneceremos um link para esta página.

Controle de versão de grupo de tarefas

Ao fazer alterações em grupos de tarefas, isso pode parecer arriscado porque a alteração é efetiva para todas as definições que usam o grupo de tarefas. Com controle de versão de grupo de tarefas, agora você pode rascunhar e visualizar versões de grupo de tarefas enquanto ainda oferece versões estáveis para as definições mais importantes até estar pronto para alternar. Depois de alguns rascunhos e iteração, é possível publicar uma versão estável e, durante a publicação, se as alterações forem significativas por natureza, você poderá optar por publicar o grupo de tarefas como versão prévia (uma nova versão principal). Como alternativa, é possível publicá-lo diretamente como uma versão estável atualizada (Figura 74).

Quando uma nova versão principal (ou versão prévia) do grupo de tarefas está disponível, o editor de definição o informará que há uma nova versão. Se a versão principal for uma versão prévia, você ainda verá uma mensagem de "Experimente". Quando o grupo de tarefas sair da versão prévia, as definições que o usam serão atualizadas automaticamente, acompanhando esse canal principal (Figura 75).

Salvar como rascunho

(Figura 74) Salvar grupo de tarefas como rascunho

Publicar grupo de tarefas como versão prévia

(Figura 75) Publicar grupo de tarefas como versão prévia

Importação e exportação de grupo de tarefas

Embora os grupos de tarefas tenham habilitado a reutilização dentro de um projeto, sabemos que a recriação de um grupo de tarefas entre os projetos e contas pode ser difícil. Com a importação/exportação de grupo de tarefas (Figura 76), assim como fizemos para definições de versão, agora você pode exportar como um arquivo JSON e importar onde desejar. Também habilitamos grupos de tarefas aninhados, que expandem primeiro quando são exportados.

Exportar grupo de tarefas

(Figura 76) Exportar grupo de tarefas

Suporte de diversas configurações em tarefas do lado do servidor (sem agente)

Ao especificar multiplicadores variável para tarefas do servidor (sem agente) (Figura 77), agora é possível executar o mesmo conjunto de tarefas em uma fase em várias configurações, que são executadas em paralelo.

Multiconfiguração de tarefas sem agente

(Figura 77) Multiconfiguração de tarefas sem agente

Suporte a variáveis na tarefa de intervenção manual

A tarefa Intervenção Manual (Figura 78) agora dá suporte ao uso de variáveis dentro do texto de instrução mostrado aos usuários quando a tarefa é executada, no ponto em que o usuário pode retomar a execução do processo de versão ou rejeitá-la. Todas as variáveis definidas e disponíveis na versão podem ser incluídas e os valores serão usados nas notificações e também no email enviado aos usuários (Figura 79).

Tarefa de intervenção manual

(Figura 78) Tarefa de intervenção manual

Caixa de diálogo de intervenção manual pendente

(Figura 79) Caixa de diálogo de intervenção manual pendente

Controle versões para um ambiente com base na ramificação de origem

Uma definição de versão pode ser configurada para disparar uma implantação automaticamente quando uma nova versão é criada, normalmente após um build da origem ocorrer. No entanto, é possível implantar apenas builds de ramificações específicas da origem, em vez de quando qualquer build for bem-sucedido.

Por exemplo, é possível que todos os builds sejam implantados em ambientes de desenvolvimento e teste, mas apenas builds específicos sejam implantados na produção. Anteriormente, era necessário manter dois pipelines de versão para essa finalidade, um para os ambientes de desenvolvimento e teste e outro para o ambiente de produção.

O Release Management agora dá suporte ao uso de filtros de artefato para cada ambiente. Isso significa que é possível especificar as versões que serão implantadas em cada ambiente quando as condições de gatilho de implantação (por exemplo, um build bem-sucedido e criação de uma nova versão) forem atendidas. Na seção Gatilho da caixa de diálogo Condições de implantação do ambiente (Figura 80), selecione as condições do artefato como branch de origem e marcas para builds que dispararão uma nova implantação para esse ambiente.

Caixa de diálogo de condições de implantação

(Figura 80) Caixa de diálogo de condições de implantação

Além disso, a página Resumo da Versão (Figura 81) agora contém uma dica pop-up que indica o motivo de todas as implantações "não iniciadas" estarem nesse estado e sugere como ou quando a implantação será iniciada.

Dica de resumo de versão

(Figura 81) Dica de resumo de versão

Gatilhos de versão para repositórios Git como uma fonte de artefato

O Release Management agora dá suporte à configuração de um gatilho de implantação contínua (Figura 82) para repositórios Git vinculados a uma definição de versão em qualquer um dos projetos de equipe na mesma conta. Isso permite disparar uma versão automaticamente quando é feita uma nova confirmação no repositório. Também é possível especificar uma ramificação no repositório de Git para a qual as confirmações dispararão uma versão.

Gatilhos de versão

(Figura 82) Gatilhos de versão

Gatilhos de versão: implantação contínua para alterações enviadas por push para um repositório de Git

O Release Management sempre ofereceu a capacidade de configurar a implantação contínua, quando um build é concluído. No entanto, agora também é possível configurar a implantação contínua no envio por push do Git. Isso significa que você pode vincular repositórios Git do Team Foundation e GitHub como origens de artefato para uma definição de versão e, em seguida, disparar versões automaticamente para aplicativos como Node.JS e PHP que não são gerados de um build e, portanto, não precisam de uma ação de build para implantação contínua.

Aprimoramentos em tarefas do servidor

Fizemos dois aprimoramentos em tarefas do servidor (tarefas que são executados em uma fase de servidor).

Adicionamos uma nova tarefa que pode ser usada para invocar qualquer API REST HTTP genérica (Figura 83) como parte do pipeline automatizado. Por exemplo, ela pode ser usada para invocar o processamento específico com uma função do Azure e esperar até que ela seja concluída.

Tarefa API REST

(Figura 83) Tarefa API REST

Também adicionamos uma seção Controlar opções (Figura 84) a todas as tarefas do servidor. O comportamento da tarefa agora inclui a configuração das opções Habilitado, Continuar se houver erro, Sempre executar e Tempo limite.

Opções de controle da tarefa

(Figura 84) Opções de controle da tarefa

Notificação de status de versão no hub de códigos

Atualmente, se quiser saber se uma confirmação está implantada no ambiente de produção do seu cliente, primeiro, identifique qual build consome a confirmação e verifique todos os ambientes de versão em que este build está implantado. Agora, essa experiência é muito mais fácil com a integração do status da implantação na notificação de status do hub Código para mostrar a lista de ambientes nos quais seu código está implantado. Para cada implantação, o status é postado na última confirmação que era parte da implantação. Se uma confirmação for implantada em várias definições de versão (com vários ambientes), cada uma terá uma entrada na notificação, com o status mostrado para cada ambiente (Figura 85). Isso melhora a capacidade de acompanhamento da confirmação de código para implantações.

Notificação de status de versão

(Figura 85) Notificação de status de versão

Por padrão, quando você cria uma definição de versão, o status da implantação é postado para todos os ambientes. No entanto, é possível escolher seletivamente os ambientes cujo status de implantação deve ser exibido na notificação de status (por exemplo, mostrar apenas ambientes de produção) (Figura 86).

Caixa de diálogo de opções de implantação

(Figura 86) Caixa de diálogo de opções de implantação

Aprimoramentos no menu de definição de build durante a adição de artefatos

Ao adicionar os artefatos de build a uma definição de versão, agora é possível exibir as definições com suas informações de organização de pasta e simplificar a escolha da definição desejada (Figura 87). Isso facilita diferenciar o mesmo nome de definição de build, mas em pastas diferentes.

Adicionar artefato

(Figura 87) Adicionar artefato

A lista de definições é filtrada com base naquelas que contêm o termo do filtro.

Reverter a definição de versão para a versão mais antiga

Atualmente, se uma definição de versão é atualizada, não é possível reverter diretamente para uma versão anterior. A única maneira é examinar o histórico de definição de versão para localizar a diferença das alterações e, em seguida, editar manualmente a definição de versão. Agora, ao usar o recurso Reverter definição (Figura 88), é possível escolher e reverter para qualquer versão anterior de uma definição de versão por meio da guia Histórico da definição de versão.

Reverter definição de versão

(Figura 88) Reverter definição de versão

Teste

Remoção do suporte para a Central de laboratório e fluxos de teste automatizado no Microsoft Test Manager

Com a evolução do Build e Release Management, os builds XAML não têm mais suporte no TFS 2018 e, consequentemente, estamos atualizando o suporte para usar o Microsoft Test Manager (MTM) com o TFS. Não há suporte do TFS para o uso da Central de laboratório/Central de teste no MTM para testes automatizados, a partir do TFS 2018. Se você não está pronto para migrar diretamente de builds XAML e da Central de laboratório, não deve atualizar para o TFS 2018.

Se você atualizar para o TFS 2018, este é o impacto:

Central de laboratório:
  • Não há mais suporte:
    • Controladores de teste não podem ser registrados com o TFS para criar e gerenciar ambientes de laboratório.
    • Qualquer Controlador de teste existente registrado com o TFS ficará offline e os ambientes de laboratório existentes aparecerão como “Não pronto”.
  • Alternativa recomendada:
Teste automatizado:
Teste manual:
  • Todos os cenários de teste manuais continuam tendo suporte completo. Embora os testes manuais possam ser executados usando o MTM com o TFS 2018, os ambientes de laboratório não podem ser usado para executar testes manuais.
  • Para todos os cenários de teste manual, é altamente recomendável usar o hub de teste no acesso à Web do TFS.

Com base nos comentários que recebemos de equipes que realizam testes exploratórios, estamos aperfeiçoando os links de rastreamento ao corrigir bugs, tarefas ou casos de teste na extensão de Teste e comentários. Bugs e tarefas criadas ao explorar os requisitos agora serão criados com o mesmo caminho de área e iteração desse requisito em vez de os padrões da equipe. Casos de teste criados durante a exploração de requisitos agora serão vinculados com um link de Testes <-> Testado por em vez do link Pai – Filho de forma que os casos de teste que você criar sejam adicionados automaticamente a conjuntos de testes com base nos requisitos. Por fim, itens de trabalho criados enquanto não estiver especificamente explorando nenhum requisito serão arquivados na iteração de padrão da equipe em vez da iteração atual para que nenhum novo item de trabalho entre na iteração atual depois que o planejamento de sprint estiver concluído.

Filtros para itens de trabalho de caso de teste em Planos de teste e conjuntos no Hub de teste

Além dos filtros nos campos de Teste como Resultado, Configuração e Testador, agora você pode filtrar nos campos de item de trabalho do Caso de Teste como Título, Estado e Atribuir a (Figura 89).

Filtros de caso de teste

(Figura 89) Filtros de caso de teste

Gráficos de tendências de teste para execuções de teste e ambientes de versão

Estamos adicionando o suporte para Ambientes de Versão no widget Tendência de Resultado do Teste (Figura 90) para que você possa acompanhar o status dos ambientes de teste nos painéis do VSTS. Da mesma maneira que faz para resultados de teste no Build, é possível criar gráficos de tendências que mostram a taxa de aprovação do teste, a contagem do total, testes aprovados ou com falha e a duração do teste para Ambientes de versão. Também é possível filtrar os gráficos em uma execução de teste específica em um ambiente com o filtro de título Execução de teste.

Gráfico de tendência de teste

(Figura 90) Gráfico de tendência de teste

Suporte para formatação de markdown para comentários de Execução de teste e Resultado do teste

Estamos adicionando suporte para formatação de comentários de Execução de teste e Resultado do teste com a sintaxe de markdown. Você pode usar esse recurso para criar o texto formatado ou links rápidos para URLs em seus comentários. Você pode atualizar comentários de Resultado do teste na página Resumo dos resultados com comentários de Atualizar análise e Execução de teste na página Executar resumo com Atualizar comentários no hub de Teste.

Ao analisar o resultado do teste na página de resumo do Build ou Versão ou no hub de Teste, agora é possível associar um bug existente a um teste com falha. Isso é útil quando um teste estiver falhando por um motivo conhecido que tenha um bug já arquivado.

Descontinuidade da Extensão de TFS para SharePoint

O TFS 2018 e versões posteriores não oferecerão mais suporte para a Extensão TFS para SharePoint. Além disso, as telas usadas para configurar a integração entre um Servidor do TFS e um Servidor do SharePoint foram removidas do Console de administração do Team Foundation.

No futuro, não ofereceremos suporte à integração de servidor para servidor e integraremos o uso de APIs públicas e estruturas de extensibilidade.

Se você estiver atualizando um servidor com a integração do TFS/SharePoint configurada, fornecemos uma solução para você "atualizar diretamente" da integração de servidor para servidor. Os sites do SharePoint do TFS continuarão sendo exibidos após a atualização, mas os recursos de integração serão desabilitados. Para obter mais detalhes e instruções, acesse aqui.

Descontinuação de salas de equipe

As equipes de desenvolvimento modernas dependem muito da colaboração. Pessoas desejam (e necessitam) um lugar para monitorar a atividade (notificações) e falar sobre ela (chat). Alguns anos atrás, reconhecemos essa tendência e definimos para criar a Sala da equipe para dar suporte a esses cenários. Desde então, temos visto mais soluções para colaborar surgirem no mercado. Notadamente, o aumento de Slack. E, mais recentemente, o comunicado do Microsoft Teams.

Com tantas boas soluções disponíveis que se integram bem com o TFS e o Visual Studio Team Services, anunciamos em janeiro os planos para remover o nosso recurso de Sala de equipe do TFS 2018 e do Visual Studio Team Services.


Problemas conhecidos

Serviço de Importação de Banco de Dados do TFS não oferece suporte a versões RC

Serviço de Importação de Banco de Dados do TFS para Visual Studio Team Services não oferece suporte para importações de versões RC do TFS. Se você estiver planejando importar seu banco de dados de coleção ao Team Services usando esse serviço, é importante que você não atualize o banco de dados de produção para esta versão RC. Se você atualizar, será necessário aguardar e atualizar para a versão RTW desta versão ou restaure uma cópia de backup do banco de dados de uma versão anterior do TFS para importar.

A tarefa de Teste v1 do Visual Studio no Build/versão não pode executar testes usando a atualização 3 do Visual Studio 2017

A tarefa de Teste v1 do Visual Studio no Build/versão não pode executar testes usando a atualização 3 do Visual Studio 2017. A tarefa falha com “Não é possível determinar o local de vstest.console.exe”. A solução alternativa é usar a versão 2 da tarefa de Teste do Visual Studio.