Notas de versão do Team Foundation Server 2018

Last Update: 22/11/2017

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

Download the latest version of Team Foundation Server

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


Vídeo sobre as novidades do TFS 2018


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: 15 de novembro de 2017

Resumo: Atualizações do Team Foundation Server 2018

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

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 disponíveis quando você cria 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.

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.

Consulte a documentação para elementos de WebLayout e Controle para obter mais informações.

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 oferece uma maneira fácil de interagir com os itens atribuídos a você, que você está seguindo, ou que visitou ou editou recentemente do seu telefone.

Mobile work item query

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

Mobile work item form

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

Mobile navigation

(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, 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.

Filtering on query

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

Hidden field

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

Update hidden field

(Figura 6) Atualizar o 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.

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 será criado com o caminho de área e o caminho de iteração esperado.

Inline add on delivery plans

(Figura 7) Planos de entrega de complemento embutido

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.

Git forks

(Figura 8) Forks de Git

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 Novo > Pasta na barra de comando ou no menu de contexto:

New folder option

(Figura 9) Nova opção de pasta

Para TFVC, você especificará um nome de pasta e, em seguida, fará o check-in. Para Git, como as pastas vazias não são permitidas, você também precisará especificar um nome de arquivo, opcionalmente, editar o arquivo 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.

New file dialog

(Figura 10) Caixa de diálogo Novo Arquivo

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.

File minimap

(Figura 11) Minimapa de arquivo

Correspondência de 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).

Bracket matching

(Figura 12) Correspondência de colchetes

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.

Toggle white space

(Figura 13) Ativar/desativar espaço em branco

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.

Observação

A edição do arquivo README da página de Visão Geral do Projeto não será afetada.

Turn off web editing

(Figura 14) Desligar a edição na Web

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

Web editing not allowed dialog

(Figura 15) Caixa de diálogo Edição na 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 o pivô Obsoleto na página Ramificações (Figura 16).

Stale branches

(Figura 16) Branches 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 17).

Search for deleted branches

(Figura 17) Pesquisar por branches excluídas

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

Restore deleted branches

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

Search for a commit

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

Pull request callout

(Figura 20) 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. 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):

Find a file or folder

(Figura 21) Localizar um arquivo ou pasta

Filtered view

(Figura 22) Exibição filtrada 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 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.

Pushes page

(Figura 23) Página de envios por push

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.

Commits page

(Figura 24) Página de 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 era persistido se a confirmação alterasse mais de 1.000 arquivos. Como resultado, era necessário carregar mais arquivos e filtrar o conteúdo para localizar o arquivo, o que estava afetando 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.

View Git tags

(Figura 25) Exibir marcas de Git

É 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 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 26).

Aviso

Cuidado ao excluir marcas em repositórios remotos.

Delete git tags

(Figura 26) 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 é 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).

Filter Git tags

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

Git tag security

(Figura 28) 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, ao preencher uma PR, você terá a opção de preencher automaticamente os itens de trabalho vinculados após a PR ter sido mesclada com êxito (Figura 29). 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ê.

Complete linked work items

(Figura 29) Itens de trabalho vinculados concluídos

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.

Reset votes setting

(Figura 30) Configuração Redefinir 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 31).

Reset votes in timeline

(Figura 31) 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 32).

Find file or folder in pull request

(Figura 32) Localizar o 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 33).

Find results

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

PR comment filtering

(Figura 34) Filtragem de comentário em solicitação de pull

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

View original diff

(Figura 35) Comparação de exibição original

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 exibir como o código era no momento em que o comentário foi criado originalmente (Figura 36).

Update badge

(Figura 36) Notificação de atualizaçã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 37).

Hide comments

(Figura 37) Ocultar comentários

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:

Collapsed comments

(Figura 38) 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 39) permitem espiar facilmente um comentário sem exibir o thread inteiro.

Collapsed comment tooltip

(Figura 39) 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, 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).

Task list toolbar

(Figura 40) Barra de ferramentas de lista de tarefas

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.

Task list

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

Like pull request comments

(Figura 42) Curtir comentários de solicitação pull

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.

Cancel auto-complete dialog

(Figura 43) Caixa de diálogo Cancelar o 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 44).

Path filtering for notifications

(Figura 44) Caminho de filtragem para notificações

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

Improved email template

(Figura 45) Modelo de email aprimorado

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

Email call-to-action

(Figura 46) Chamada de ação de email

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.

Push template

(Figura 47) Modelo de push

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.

Wiki page

(Figura 48) Página Wiki de solicitação de pull

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)

Title wiki

(Figura 49) Wiki de título da PR

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

Wiki HTML tags

(Figura 50) Marcas HTML da Wiki de solicitação de pull

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

Image resize

(Figura 51) Redimensionar imagem de solicitação de pull

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

Wiki menu

(Figura 52) Menu de Wiki de solicitação de pull

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

Wiki revert button

(Figura 53) Botão Reverter Wiki de solicitação de pull

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.

Create wiki page

(Figura 54) Página de criação de Wiki de PR

Página wiki de vinculação profunda

Wiki agora dá suporte a seções de vinculação profundas 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.

Package URL

(Figura 55) URL do pacote de solicitação de pull

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!), em resposta a esta sugestão do UserVoice.

Hide deleted packages

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

Last pushed column

(Figura 57) Última coluna enviada por push

Pacotes maven

Lançamos o suporte para hospedagem de artefatos Maven no TFS 2018 (Figura 58). 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.

Maven packages

(Figura 58) Pacotes do 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 59).

Nuget task

(Figura 59) Tarefa do NuGet

Leia mais sobre o uso do NuGet mais recente em seu build no Blog Microsoft DevOps.

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 .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, teremos um seletor que permitirá a seleção de um feed e, em seguida, geraremos 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).

dotnet task

(Figura 60) Tarefa do 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 (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.

Feeds to use

(Figura 61) Feed a ser usado

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

Feed picker

(Figura 62) 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 saber mais sobre nosso plano de substituição do build XAML, consulte a postagem no blog "Aprimoramento dos recursos de automação de build do TFS/Team Services".

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 isso é possível (Figura 63) e (Figura 64)!

Export build definition

(Figura 63) Exportar a definição de build

Import build definition

(Figura 64) Importar a 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 65), 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.

Deprecated task badge

(Figura 65) Notificação de tarefa preterida

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á as pessoas que usam a tarefa na direção certa do catálogo de tarefas e das definições de build/versão existentes.

Deprecated task description

(Figura 66) Descrição da 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 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).

Secure files library

(Figura 67) Biblioteca de arquivos seguros

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:

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.

Leia mais sobre as metas e o uso na página de repositório das tarefas do vsts.

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

Release configuration

(Figura 69) Configuração da versão

Introdução aos modelos de implantação

Todos os modelos de implantação integrados são equipados com parâmetros de processo que facilitam o início para os usuários, especificando os parâmetros mais importantes sem precisar se aprofundar nas tarefas (Figura 70).

Deployment templates

(Figura 70) Modelos de implantação

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

Simplified management of variables

(Figura 71) Gerenciamento simplificado de variáveis

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.

Task editor

(Figura 72) Editor de tarefas

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

Agora, é possível 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 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.

Variable groups

(Figura 73) Grupos de variáveis

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

Environment menu

(Figura 74) Menu de ambiente

Consulte a documentação para o Editor de Definição de Versão para obter mais informações.

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

Deployment groups

(Figura 75) 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 76). É possível controlar o que é executado em quais computadores usando as marcas e controlar a velocidade da distribuição.

Configure deployment groups

(Figura 76) 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 77).

Deployment group progress

(Figura 77) Andamento do grupo de implantação

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.

Deployment groups UI

(Figura 78) Interface do usuário de grupos de implantação

Para um destino em um grupo de implantação, é possível exibir um resumo, implantações recentes e recursos 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.

Deployment groups UI tags

(Figura 79) Marcas da interface do usuário de grupos de implantação

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

Task group references

(Figura 80) Referências do 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 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 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 utilizam serão atualizadas automaticamente, acompanhando esse canal principal (Figura 82).

Save as draft

(Figura 81) Salvar o grupo de tarefas como rascunho

Publish task group as preview

(Figura 82) Publicar um grupo de tarefas como uma 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 83), 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.

Export task group

(Figura 83) Exportar o grupo de tarefas

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.

Multi configuration of agentless tasks

(Figura 84) Configuração de várias tarefas sem agente

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

A tarefa Intervenção Manual (Figura 85) 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 86).

Manual intervention task

(Figura 85) Tarefa de intervenção manual

Manual intevention pending dialog

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

Deployment conditions dialog

(Figura 87) Caixa de diálogo de Condições de implantação

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.

Release summary tip

(Figura 88) Dica de resumo da 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 89) 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.

Release triggers

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

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 mestre são implantadas. 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.

Branch filters

(Figura 90) Filtros de branch

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

REST API task

(Figura 91) Tarefa de API REST

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.

Task control options

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

Release status badge

(Figura 93) Notificação de previsão de lançamento

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

Deployment options dialog

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

Add artifact

(Figura 95) Adicionar um 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 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.

Revert release definition

(Figura 96) Reverter a 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 terão mais que 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).

Release notifications

(Figura 97) Notificações de versão

Consulte o post para gerenciar notificações de versão para obter mais informações.

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:
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 98).

Test case filters

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

Test trend chart

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

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). Testes de execução rápidos são agrupados em lotes, enquanto testes de execução mais demorados 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.

Test batching

(Figura 100) Envio de testes em lote

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

Test selection

(Figura 101) Seleção de teste

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.

Test summary

(Figura 102) Resumo do teste

Essa capacidade depende de alterações da plataforma de teste do Visual Studio e requer que a Atualização 4 do Visual Studio 2017 seja instalada 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.

Consulte o guia de início rápido Faça o teste de carga no seu aplicativo na nuvem usando o Visual Studio e o VSTS como um exemplo de como você pode usar isso junto com o teste de carga.

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

Chart widget

(Figura 103) Widget de gráfico

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.

Observação

Se você estiver atualizando para o TFS 2018 de uma versão anterior configurada para se integrar ao SharePoint, será necessário desabilitar a integração do SharePoint após a atualização ou os sites do SharePoint do TFS não serão carregados.

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.


Início da página