Notas de versão do Team Foundation Server 2018

---

Developer Community | Requisitos do sistema e compatibilidade | Termos de licença | Blog de DevOps do TFS | Hashes SHA-1 | Últimas notas sobre a versão do Visual Studio 2019

---

---

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

Para saber mais sobre o Team Foundation Server 2018, confira a página Requisitos e Compatibilidade do Team Foundation Server. Visite a página visualstudio.com/downloads para baixar outros produtos do TFS 2018.

Consulte a Página de instalação do TFS para obter mais informações.

---

Data de lançamento: 15 de novembro de 2017

Resumo das novidades do TFS 2018

Adicionamos diversas novidades importantes no Team Foundation Server 2018. Alguns dos destaques incluem:

• Aprimoramos o Assistente de criação de projeto e o Gerenciador de modelos de processo na Web.
• Agora, é possível personalizar o cabeçalho de formulário do item de trabalho.
• Otimizamos o formulário de item de trabalho móvel.
• Adicionamos suporte para Forks do Git.
• É possível gerenciar grandes repositórios Git com GVFS.
• Exiba, filtre, exclua e defina a segurança de marcas de Git.
• Adicionamos um minimapa do arquivo, uma correspondência de colchetes, e um espaço em branco de alternância para a edição do código da web.
• Fizemos diversos aprimoramentos para solicitações de pull.
• Você tem uma nova experiência Wiki aprimorada.
• Adicionamos suporte para pacotes Maven.
• É possível importar e exportar e pausar as definições de build.
• O novo Editor de definição de versão tem a opção de aceitação por padrão.
• Você pode implantar com implantações da máquina virtual.
• Melhoramos a capacidade de acompanhamento de teste exploratório.
• Adicionamos o envio em lote de teste.
• Agora você pode exibir um widget do gráfico para planos de testes e conjuntos de testes.

Vídeo sobre as novidades do TFS 2018

Build XAML

Nós já havíamos listado o build XAML como removido do TFS 2018 RTW e Atualização 1. No entanto, o resultado disso foi que muitos clientes não conseguiram atualizar ou precisaram contatar o suporte para habilitá-lo novamente após a conclusão da atualização. No TFS 2018 Atualização 2, o build XAML está habilitado, mas foi preterido. Isso significa que não há mais nenhum investimento em build XAML e o MTM (Microsoft Test Manager) não é mais compatível com o uso de builds XAML. É altamente recomendável converter para um dos formatos de definição de build mais recentes. Você pode continuar a conectar seus controladores XAML e executar builds XAML com o TFS 2018 Atualização 2. Mais informações

Recursos removidos do TFS 2018 RTW

• O suporte para Central de laboratório e fluxos de teste automatizado no Microsoft Test Manager foi removido.
• Descontinuamos a extensão TFS para SharePoint.
• Removemos o recurso Sala de equipe.

---

Detalhes das novidades do TFS 2018

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 disponíveis quando você cria um Projeto de Equipe no cliente do Visual Studio. A vantagem de usar a interface da Web é que você 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.

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 seus 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.

Personalize o cabeçalho do formulário de item de trabalho

Agora, é possível personalizar a área do cabeçalho do formulário do item de trabalho substituindo os controles existentes ou ocultando os controles que não são relevantes para o processo. Isso permitirá substituir o caminho de Área por um campo Equipe personalizado, ocultando a Iteração se suas equipes estiverem mais focadas em Kanban e substituindo o Motivo por um campo personalizado. O campo Estado não pode ser ocultado ou substituído.

Formulário de item de trabalho móvel

Proporcionamos uma experiência completa de ponta a ponta, que conta com uma aparência otimizada para itens de Trabalho (Figura 1). Ele facilita a maneira de interagir com os itens atribuídos a você, que você está seguindo ou que visitou ou editou recentemente usando seu telefone.

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

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.

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, quadros Kanban, 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 a todas as colunas exibidas e selecionar marcas, também é possível filtrar por tipos de item de trabalho, estados e atribuídos para obter rapidamente os itens de trabalho que está procurando.

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.

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

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.

Planos de Entrega de complemento embutido

Novas ideias de recursos podem chegar a qualquer momento, então ficou mais fácil adicionar novos recursos diretamente a seus Planos de entrega (Figura 7). Basta clicar no botão Novo Item disponível ao passar o mouse, inserir um nome e pressionar Enter. Um novo recurso é criado com o caminho de área e o caminho de iteração esperado.

Controle de versão

Forks

O TFS 2018 adiciona suporte para bifurcações de Git (Figura 8). 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 sua própria bifurcação do repositório. 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.

GVFS

O Sistema de Arquivos Virtual do Git (GVFS) agora tem suporte. O GVFS permite que os repositórios do Git dimensionem para milhões de arquivos ao virtualizar e otimizar a forma que o Git opera no sistema de arquivos.

Crie uma pasta em um repositório usando a Web

Agora, é possível criar pastas via Web em seus repositórios do TFVC e do Git (Figura 9). Isso substitui a extensão de Gerenciamento de Pastas, que agora passará pelo processo de reprovação.

Para criar uma pasta, clique em Nova > Pasta na barra de comandos ou no menu de contexto:

Para o TFVC, você especificará um nome de pasta e, em seguida, fará o check-in. Para o Git, como pastas vazias não são permitidas, você também precisará especificar um nome de arquivo, editar o arquivo opcionalmente e confirmá-lo.

Além disso, para o Git, a caixa de diálogo Novo arquivo(Figura 10) foi aprimorada para aceitar barras "/" para criar subpastas.

Minimapa de arquivo

Agora, é possível exibir um minimapa de um arquivo enquanto você exibe ou edita para ter uma visão geral rápida do código (Figura 11). Para ativar o minimapa, abra a Paleta de Comando (F1 ou clique com o botão direito) e selecione Ativar/desativar Minimapa.

Correspondência entre colchetes

Ao editar ou exibir um arquivo, agora há diretrizes no lado esquerdo para tornar mais fácil fazer a correspondência com seu colchetes (Figura 12).

Ativar/desativar espaço em branco

Agora, é possível ativar e desativar o espaço em branco ao exibir ou editar um arquivo. Ainda estamos desenvolvendo um recurso que permitirá que você ative/desative o espaço em branco ao comparar. Para exibir o espaço em branco (Figura 13), abra a Paleta de Comandos (F1 ou clique com botão direito do mouse) e selecione Ativar/desativar espaço em branco, o que lhe permite diferenciar os espaços e guias.

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 na página Arquivos, acesse Configurações e, em seguida, Controle de Versão (Figura 14). Clique no repositório TFVC na árvore, navegue até o pivô Opções e desmarque Habilitar edição pela Web para este repositório TFVC. Por padrão, a edição pela web está habilitada.

Caso tente fazer uma edição pela Web em um projeto com a edição pela Web desabilitada, você receberá uma notificação de que ela não é permitida (Figura 15).

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 branches "obsoletos" (branches que apontam para confirmações com mais de 3 meses). Para ver suas ramificações obsoletas, vá para o pivô Obsoleto na página Ramificações(Figura 16).

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

Quando um branch é excluído acidentalmente do servidor, pode ser difícil descobrir o que aconteceu com ele. 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 17).

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

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 a todas as ramificações que são prefixadas com "dev", basta digitar "dev" na caixa de pesquisa e selecionar Pesquisar em ramificações que começam com "dev" (Figura 19).

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

O texto explicativo da solicitação de pull na página de confirmação de detalhes mostra informações mais relevantes para ajudá-lo a diagnosticar melhor (Figura 20). 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.

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 para chegar aos 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. Ele mostra um modo de exibição de árvore recolhido de um arquivo para exibir a hierarquia do arquivo ao filtrar por nome de arquivo.

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

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 está visível como um hub chamado Pushes (Figura 23) em Código, junto com Confirmações, Ramificações, Marcas e Solicitações de pull. A nova URL da página de envios por push é : \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. As URLs antigas continuarão a funcionar.

Ao mesmo tempo, o hub Histórico foi renomeado como Confirmações (Figura 24), 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 da página de confirmações é: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits. As URLs antigas continuarão a funcionar.

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

Ouvimos comentários que reportavam que ao filtrar o diretório para um arquivo específico na área dinâmica Arquivos do hub Código e o inverter posteriormente para a área dinâmica Histórico, o nome do arquivo não persistirá se a confirmação alterar mais de 1.000 arquivos. Como resultado, era necessário carregar mais arquivos e filtrar o conteúdo para localizar o arquivo, o que afetava 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 em seu repositório na página Marcas(Figura 25). 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.

É possível diferenciar facilmente uma marca leve de uma anotada. As 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 você pode ter marcado a confirmação errada. É possível excluir com facilidade as 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 26).

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 é possível localizar a marca que você estava procurando na página Marcas, basta pesquisar pelo nome da marca usando o filtro na parte superior da página Marcas(Figura 27).

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 permissão para excluir marcas ou gerenciar marcas dessa interface (Figura 28).

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

Se estiver vinculando itens de trabalho a solicitações de pull, será mais simples manter tudo atualizado. Agora, ao concluir uma PR, você terá a opção de concluir automaticamente os itens de trabalho vinculados depois que a PR for mesclada com êxito (Figura 29). Se você estiver usando políticas e definir as solicitações de pull para conclusão automática, haverá a mesma opção. Não há mais a necessidade de lembrar-se de rever os itens de trabalho para atualizar o estado depois de preencher a solicitação de pull. Isso é feito automaticamente para você.

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 30). A nova configuração é uma opção na política para Exigir um número mínimo de revisores.

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 31).

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 32).

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 33).

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 34). Também é possível filtrar para ver discussões de que participou.

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 35).

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

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 37).

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

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 39) permitem espiar com facilidade um comentário sem exibir o thread inteiro.

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, seja como um criador de PR ou como o 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 40).

Depois de adicionar uma lista de tarefas (Figura 41), basta selecionar 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.

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 42). É possível ver a lista de todas as pessoas que curtiram o comentário passando o mouse sobre o botão.

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

Usar a opção de preenchimento automático(Figura 43) 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.

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 44).

Modelos de email atualizados para fluxos de trabalho de solicitação de pull

Os alertas de solicitação de pull por email foram atualizados para ficarem claros, concisos e acionáveis (Figura 45). A linha do assunto agora começa com o título da PR. As informações secundárias, como nome do repositório e a ID, são enviadas para o final. O nome do autor foi adicionado ao assunto para simplificar a aplicação de 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.

Para a maioria dos alertas, o plano de ação (Figura 46) é 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.

Modelos de email atualizados para notificações por push

As notificações por push foram atualizadas para corresponder aos novos modelos de email que foram otimizados para serem claros, concisos e acionáveis (Figura 47). A linha do assunto ajuda a, claramente, distinguir envio de emails por push, identificar a ramificação, repositório e autor, além de resumir o número de confirmações incluídas no envio. Essas alterações também facilitam a criação de regras e filtros para ajudar a gerenciar essas notificações de email.

O corpo do email é consistente com outros emails, enfatizando o motivo pelo qual o email foi enviado, que iniciou a ação e o que aconteceu exatamente. Específico para envio de alertas por push, os detalhes sobre o repositório, ramificação, arquivos e confirmações são todos os incluídos para ajudar a informar os destinatários sobre o escopo das alterações. O plano de ação principal para envio de alertas por push é Exibir Push, que abrirá a exibição de pushes do push específico que gerou o alerta.

Wiki

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

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 49)

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

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

• 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 52).

• Atualizações offline de Wiki para usuários avançados.

À medida que você usa mais o Wiki, você pode acabar salvando alterações sem querer. 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 53).

Criar uma página Wiki com base em um link desfeito

Observamos um padrão durante a criação de um Wiki, em que um sumário em uma página Wiki inclui links inexistentes (Figura 54). Os usuários que clicam nesses links em uma tentativa de criar uma página real. Anteriormente, 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 do Wiki, permitindo que você crie páginas em vez disso.

Página wiki de vinculação profunda

O Wiki agora dá suporte a seções de vinculação profunda dentro de uma página e entre páginas, o que é muito útil para a criação de um sumário. Você pode referenciar um título na mesma página ou em outra página, usando a seguinte sintaxe:

• Mesma página: [text to display](#section-name)
• Outra página: [text to display](/page-name#section-name)

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 esta 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 55). O formato é: \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package.

Agora é possível ocultar as versões de pacote excluídas (Figura 56) de todos os usuários do feed (não há mais pacotes tachados).

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 57) com datas compreensíveis para que você possa localizar com facilidade os pacotes atualizados recentemente.

Pacotes maven

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

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 59).

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 do NuGet tem uma nova opção Permitir que duplicatas sejam ignoradas que permite que a tarefa continue ao tentar enviar pacotes por push a um feed do VSTS/TFS quando a versão já está em uso.

Atualizações de tarefa de build de npm

Independentemente de você estar criando seu projeto npm no Windows, no Linux ou no 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 de registros listados no arquivo .npmrc do projeto possam ser armazenadas com segurança em um ponto de extremidade de serviço. Como alternativa, se você está usando um feed do VSTS/TFS, há um seletor que permite a seleção de um feed e, em seguida, gera um .npmrc com as credenciais necessárias 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. Atualizamos a tarefa Maven para que você possa trabalhar facilmente com feeds do VSTS/TFS (Figura 60).

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. Isso inclui o seguinte:

1. Primeiro, o dotnet agora dá suporte fontes de pacotes autenticados como o Gerenciamento de Pacotes, 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 falha quando os arquivos de projeto que correspondem ao padrão especificado não são 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 (Figura 61) 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 60). 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.

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 é usado para essa etapa de build (Figura 62).

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. Se você ainda não está pronto para migrar e precisa continuar usando builds XAML, atualize para o TFS 2018 Atualização 2.

Quando você atualizar para o TFS 2018 RTW (ou Atualização 1):

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

• Você poderá exibir os builds XAML concluídos, mas não conseguirá colocar novos deles na fila.

• Não há nenhuma nova versão do controlador nem do agente de build XAML no TFS 2018.

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 Visual Studio ou o Team Explorer 2017 para editar as definições de build XAML ou para colocar novos builds XAML na fila.

• Se você precisar criar agentes de build XAML, será necessário instalá-los usando o instalador de agente de build do TFS 2015.

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. Isso foi uma das dez solicitações mais pedidas no UserVoice.

Temos o prazer de anunciar que agora isso é possível (Figura 63) e (Figura 64)!

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 ver o exemplo completo, confira https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.

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 65), essas tarefas são enviadas por push para o final e são agrupadas 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.

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

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 usados 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 67).

Use a biblioteca de arquivos seguros para armazenar arquivos como certificados de autenticação, Perfis de Provisionamento da Apple, arquivos de Repositório de Chaves do 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:

• Utilitário: instalar o certificado da Apple

• Utilitário: instalar o perfil de provisionamento Apple

Pausar definições de build

Agora, é possível pausar ou desabilitar as definições de build. Se planeja fazer alterações na definição de build e quer evitar o enfileiramento de novos builds até terminar, basta desabilitar a definição de build. Da mesma forma, caso planeje atualizar os computadores de agente, você poderá optar por pausar uma definição de build, o que permitirá que o VSTS ainda aceite novas solicitações de build, mas os manterá na fila sem executar até que você retome a definição.

Suporte de validações de entrada da tarefa

A digitação de parâmetros em tarefas de definição de build pode, às vezes, ser propensa a erros. Com a validação de entrada da tarefa, os autores de tarefa podem garantir que os valores apropriados sejam especificados. As expressões de validação seguem a sintaxe de expressão familiar usada em condições de tarefas e podem usar qualquer uma das funções compatíveis, além de funções gerais compatíveis com condições de tarefas, incluindo URL, IPV4, email, intervalo de números, sha1, comprimento ou correspondência.

Novo editor de definição de versão

Continuando em nossa jornada de atualização das experiências de Build e Versão, reinventamos o editor de definição de versão para fornecer uma experiência mais intuitiva, corrigimos alguns pontos problemáticos e adicionamos novos recursos. Um dos recursos mais avançados do novo editor é sua capacidade de ajudá-lo a visualizar como as implantações em seus ambientes progrediriam. Além disso, as aprovações, propriedades de ambiente e de configurações de implantação agora estão no contexto e podem ser configuradas facilmente.

Visualização do pipeline

O pipeline (Figura 68) no editor fornece uma exibição gráfica de como as implantações progridem em uma versão. Os artefatos sã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.

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 69).

Introdução aos modelos de implantação

Todos os modelos de implantação internos são equipados com parâmetros de processo que simplificam processo para que os usuários comecem especificando os parâmetros mais importantes sem precisar se aprofundar nas tarefas (Figura 70).

Gerenciamento simplificado de variáveis de ambiente e de versão

Use a exibição da Lista para adicionar rapidamente as variáveis de ambiente ou de versão, e a exibição de Grade para comparar e editar variáveis em escopos lado a lado. Além disso, você pode usar a pesquisa de filtro e de palavra-chave para gerenciar o conjunto de variáveis para trabalhar com os dois modos de exibiçã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 da versão (Figura 72). É 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.

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

Agora você pode vincular/desvincular a grupos de variáveis (Figura 73), 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 do número de liberação, na guia Opções . Você também pode salvar um ambiente como um modelo de implantação, definir permissões no nível do ambiente e reordenar as fases na guia Tarefas .

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

Implantação da máquina virtual 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 um pool de agentes e direciona implantações para servidores de destino remotos, instale o agente em cada um dos seus servidores de destino diretamente e gere as implantações 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 75) é um grupo lógico de destinos (computadores) com agentes instalados em cada um deles. Os grupos de implantação representam seus ambientes físicos, como desenvolvimento de caixa única, controle de qualidade de vários computadores e um farm de computadores para UAT/Prod. Eles também especificam o contexto de segurança para seus ambientes físicos.

Você pode usar isso em qualquer máquina virtual com a qual registrar nosso agente. Também facilitamos o registro com o Azure com suporte para uma extensão de máquina virtual do Azure que instala automaticamente o agente quando a máquina virtual acelera. As marcas são herdadas automaticamente na máquina virtual do Azure quando ela é registrada.

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

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

Esse recurso agora é parte integrante do Release Management. Não há licenças adicionais necessárias.

Interface do usuário aprimorada dos Grupos de Implantação

Continuando nossa jornada de atualizar as experiências de Build e Versão, agora reinventamos nossas páginas de grupos de implantação para torná-las uma experiência mais clara e intuitiva (Figura 78). Na página inicial, você pode exibir a integridade dos destinos no grupo de implantação. Também é possível gerenciar a segurança de um grupo de implantação individual ou definir as permissões padrão em grupos de implantação.

Para um destino em um grupo de implantação, é possível exibir um resumo, implantações recentes e funcionalidades de destino (Figura 79). Você pode definir marcas no destino e controlar o que é executado em cada destino. Adicionaremos suporte de filtro para grupos de implantação em versões futuras.

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 (Figura 80). 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 79).

Quando você tenta excluir um grupo de tarefas que ainda é referenciado, é mostrado um aviso e um link para essa 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 81).

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 essa versão principal for uma versão prévia, ainda haverá uma mensagem "Experimente". Quando o grupo de tarefas sair da versão prévia, as definições que o utilizam serão atualizadas automaticamente, acompanhando esse canal principal (Figura 82).

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 83), assim como fizemos para definições da 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.

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

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

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

A tarefa Intervenção Manual(Figura 85) agora é compatível com o 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 são usados nas notificações e também no email enviado aos usuários (Figura 86).

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 sã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) são atendidas. Na seção Gatilho da caixa de diálogo Condições de implantação do ambiente (Figura 87), selecione as condições do artefato como branch de origem e marcas para builds que dispararão uma nova implantação para esse ambiente.

Além disso, a página Resumo da Versão(Figura 88) 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.

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

O Release Management agora é compatível com a configuração de um gatilho de implantação contínua (Figura 89) para repositórios Git vinculados a uma definição da versão em qualquer um dos projetos de equipe na mesma conta. Isso permite disparar uma versão automaticamente ao fazer uma nova confirmação no repositório. Também é possível especificar um branch no repositório Git para a qual as confirmações dispararão uma 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.

Filtros de ramificação em gatilhos de ambiente

No novo editor de definição de versão, agora é possível especificar as condições de artefato para um determinado ambiente. Ao usar essas condições de artefato, você terá um controle mais granular no qual os artefatos devem ser implantados em um ambiente específico. Por exemplo, em um ambiente de produção, convém certificar-se de que os builds gerados somente da ramificação principal sejam implantados. Este filtro precisa ser definido para todos os artefatos que você achar que devem atender a esse critério.

Também é possível adicionar vários filtros a cada artefato vinculado à definição de versão (Figura 90). A implantação será disparada para esse ambiente apenas se todas as condições de artefato forem atendidas com êxito.

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 invoca qualquer API REST HTTP genérica (Figura 91) 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.

Também adicionamos uma seção Controlar opções (Figura 92) 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.

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 93). Isso melhora a capacidade de acompanhamento da confirmação de código para implantações.

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 94).

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 95). Isso facilita diferenciar o mesmo nome de definição de build, mas em pastas diferentes.

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 da 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 96), é 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.

Notificações personalizadas para as versões

As notificações de versão agora estão integradas com a experiência de configurações de notificação do VSTS. Essas versões de gerenciamento agora são notificadas automaticamente sobre ações pendentes (intervenções manuais ou aprovações) e falhas de implantação importantes. Você pode desligar essas notificações acessando as configurações de Notificação no menu do perfil e desligando as Assinaturas de Versão. Também é possível assinar notificações adicionais ao criar assinaturas personalizadas. Os administradores podem controlar as assinaturas para equipes e grupos as configurações de Notificação nas configurações de Equipe e de Conta.

Os autores da definição da versão não precisam mais enviar emails manualmente para obter aprovações e conclusões de implantação.

Isso é especialmente útil em contas grandes com vários stakeholders para versões e para aqueles que não sejam o aprovador, criador de versão e proprietário do ambiente, que podem querer ser notificados (Figura 97).

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.

Veja o impacto da atualização para o TFS 2018 abaixo:

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:
  • Você pode se conectar ao seu servidor do SCVMM usando a extensão do TFS SCVMM, criar e gerenciar máquinas virtuais e executar os fluxos de trabalho nele. Para obter mais detalhes, consulte Como executar operações do Lab Management no Build e Versão.

Teste automatizado:

• Não há mais suporte:
  • Não há mais suporte para fluxos de trabalho de teste automatizado que se baseiam no controlador de Teste e ambientes de laboratório, como o fluxo de trabalho de Build-Implantação-Teste XAML automatizados ou que executam testes automatizados em um plano de teste usando MTM.
• Alternativas recomendadas:
  • Você pode executar testes automatizados no Build e Versão.
  • Você pode executar testes automatizados de um plano de teste usando o hub de teste.

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.

Aprimoramentos de capacidade de acompanhamento de teste exploratório para links de item de trabalho, iterações e caminhos de área

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. Os bugs e as tarefas criados ao explorar os requisitos agora são criados com o mesmo caminho de área e iteração desse requisito e não com os padrões da equipe. Os casos de teste criados durante a exploração de requisitos agora serão vinculados a um link Testes <-> Testado por em vez do link Pai <-> Filho para que os casos de teste criados sejam adicionados automaticamente aos conjuntos de testes baseados em requisitos. Por fim, itens de trabalho criados enquanto não se estiver explorando especificamente 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 98).

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 99) 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.

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.

Adicionar link para o bug existente para um teste com falha

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.

Carregar anexos para execuções e resultados de teste

Agora, é possível anexar arquivos como capturas de tela e arquivos de log a execuções ou resultados de teste como informações adicionais. Até esse ponto, essa funcionalidade estava disponível somente por meio do cliente do Microsoft Test Manager (MTM), forçando-o para alternar o contexto entre o hub de Teste no VSTS/TFS e o cliente MTM.

Lote de teste

Na tarefa de teste do Visual Studio, no gerenciamento de Build/Versão, as opções estão disponíveis para controlar como os testes devem ser agrupados (em lotes) para uma execução eficiente. Os testes podem ser agrupados de duas maneiras:

1. Com base no número de testes e agentes que participam da execução, que simplesmente agrupam testes em um número de lotes de um tamanho especificado.
2. Com base no tempo de execução anterior de testes, que considera o tempo de execução anterior para criar lotes de testes de tal forma que cada lote tenha o tempo de execução aproximadamente igual (Figura 100). Os testes de execução rápida são agrupados em um lote, enquanto os testes de execução mais longa podem pertencer a um lote separado. Essa opção pode ser combinada com a configuração da fase de multiagente para reduzir o tempo total de teste para o mínimo.

Executar webtests usando a tarefa VSTest

Usando a tarefa de teste do Visual Studio, os webtests, também conhecidos como testes de desempenho da Web, agora podem ser executados no pipeline do CI/CD. Os webtests podem ser executados ao especificar os testes a serem executados na entrada do assembly da tarefa. Qualquer item de trabalho do caso de teste que tem uma "automação associada" vinculada a um webtest pode ser executado ao selecionar o conjunto de testes/plano de teste na tarefa (Figura 101).

Os resultados do WebTest estarão disponíveis como um anexo ao resultado do teste (Figura 102). Isso pode ser baixado para análise offline no Visual Studio.

Essa funcionalidade depende das alterações da plataforma de teste do Visual Studio e requer que o Visual Studio 2017 Atualização 4 esteja instalado no agente de build/versão. Os webtests não podem ser executados usando as versões anteriores do Visual Studio.

Da mesma forma, os webtests podem ser executados usando a tarefa Executar Teste Funcional. Essa funcionalidade depende de alterações no Agente de Teste, que estará disponível com o Visual Studio 2017 Atualização 5.

Widget de gráfico para planos e conjuntos de teste

Anteriormente, você pôde criar gráficos para planos e conjuntos de teste no hub de Teste e fixá-los ao painel. Agora, adicionamos um widget que permite criar gráficos para planos e conjuntos de teste no catálogo do widget no painel. É possível criar gráficos para status de criação de testes ou para status de execução de testes. Além disso, a adição de gráficos do widget permite criar gráficos maiores quando houver mais dados a serem mostrados em um gráfico (Figura 103).

Suporte de captura de tela e anotação para aplicativos da área de trabalho com o navegador Chrome para testes manuais

Estamos adicionando suporte para uma das principais sugestões de teste manual – obter capturas de tela de aplicativos de área de trabalho do Executor de Web Test no hub de Teste. Até agora, você tinha que usar o Executor de Testes no Microsoft Test Manager para obter capturas de tela de aplicativos de área de trabalho. É preciso instalar a extensão Teste e Comentários para usar essa funcionalidade. Estamos desenvolvendo o suporte para o navegador Chrome e o do Firefox virá logo depois.

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.

Criamos uma solução que permite que você desabilite a integração no servidor do SharePoint. Para obter mais informações, consulte a postagem no futuro da nossa Integração do TFS/SharePoint.

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.

---

Como estamos nos saindo?

Adoraríamos ouvir o que você tem para nos dizer! Relate um problema e acompanhe-o por meio da Comunidade de Desenvolvedores e receba consultoria no Stack Overflow.

---

Início da página