Notas de versão do Team Foundation Server 2017 Atualização 2 RC2

Last Update: 27/06/2017

Para ver as últimas atualizações, visite as Notas de versão em inglês.

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

Baixar a versão mais recente do Team Foundation Server

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


Comentários

Adoraríamos ouvir sua opinião! Relate um problema e acompanhe-o por meio do portal Comunidade de Desenvolvedores. Envie-nos sugestões por meio do site Atualizações de produto do Visual Studio Team Services.


Data de lançamento: 26 de junho de 2017

Resumo das atualizações nesta versão

Adicionamos um novo valor significativo ao Team Foundation Server 2017 Atualização 2 RC2. Alguns dos destaques incluem:

Veja os detalhes de todos os novos recursos exibindo as melhorias por área de recurso:


O que há de novo nesta versão

Melhorias no Acompanhamento de Item de Trabalho

Ícones do tipo de item de trabalho

Fizemos um compromisso global para tornar nossos produtos totalmente acessíveis para nossos clientes. Como parte desse compromisso, estamos trabalhando para encontrar e resolver vários problemas de acessibilidade – de qualquer tipo, desde padrões do teclado até design visual e layout.

O acompanhamento de item de trabalho baseava-se exclusivamente em cores em muitas experiências para transmitir o tipo de item de trabalho. No entanto, isso é problemático para nossos usuários daltônicos ou com visão reduzida que talvez não consigam distinguir entre os itens devido às semelhanças nas cores. Para aumentar a capacidade de visualização do tipo de item de trabalho para todos os nossos clientes, introduzimos ícones para a linguagem visual do tipo de item de trabalho. Personalize os tipos de item de trabalho escolhendo uma opção em uma seleção de nossa biblioteca de ícones.

As barras de cores que transmitem o tipo nas grades de lista de pendências e consultas foram substituídas por ícones coloridos (Figura 1).

Wit icons in query

(Figura 1) Ícones coloridos em uma consulta

Agora os cartões do board incluem um ícone de tipo (Figura 2).

Board with icon type

(Figura 2) Board com tipo de ícone

Planos de Entrega

Os Planos de Entrega são uma ferramenta organizacional que ajuda você a melhorar o alinhamento e a visibilidade entre equipes com o acompanhamento do status de trabalho em um calendário baseado em iteração. Personalize seu plano para incluir qualquer nível de equipe ou lista de pendências de todos os projetos na conta. Além disso, a opção Critérios do Campo nos Planos permite personalizar ainda mais a exibição, enquanto a opção Marcadores realça datas importantes.

Confira a página Planos de Entrega no Marketplace para saber mais e instalar a extensão.

Vinculação automática de itens de trabalho para builds

Com essa nova configuração na definição de build, você pode acompanhar os builds que incorporaram o trabalho sem a necessidade de pesquisar um grande conjunto de builds manualmente. Cada build bem-sucedido associado ao item de trabalho é exibido automaticamente na seção de desenvolvimento do formulário do item de trabalho.

Para habilitar esse recurso, ative a configuração em Opções na definição de build (Figura 3).

WIT build linking

(Figura 3) Vinculação de build do tipo de item de trabalho

Reprovação do antigo formulário do item de trabalho

Os comentários gerais sobre o novo formulário do item de trabalho foram positivos e agora temos uma adoção de 100% em nossas contas hospedadas. Queremos que os clientes locais aproveitem o mesmo valor que agradou nossos usuários do VSTS e, portanto, decidimos reprovar o antigo formulário do item de trabalho e o antigo modelo de extensibilidade. Leia mais sobre nossos planos na página Gerenciamento do Ciclo de Vida do Aplicativo da Microsoft.

Pesquisa de Itens de Trabalho

A Pesquisa de Itens de Trabalho fornece uma pesquisa rápida e flexível em todos os itens de trabalho de todos os projetos de uma coleção (Figura 4). Use o mecanismo de pesquisa de texto completo da Pesquisa de Itens de Trabalho para pesquisar termos com facilidade em todos os campos de item de trabalho e localizar itens de trabalho relevantes de forma eficiente. Use filtros da pesquisa em linha, em qualquer campo de item de trabalho, para restringi-lo rapidamente a uma lista de itens de trabalho.

Depois que o serviço Pesquisa for configurado no TFS, você poderá começar a pesquisar sem precisar instalar nada mais. Com a Pesquisa de Itens de Trabalho, é possível:

  • Pesquisar todos os projetos: pesquise em sua própria lista de pendências e na lista de pendências das equipes de seu parceiro. Use pesquisas entre projetos em todos os itens de trabalho para pesquisar todos os itens de trabalho de sua organização. Restrinja a pesquisa usando filtros de demarcador de projeto e área.
  • Pesquisar todos os campos de item de trabalho: encontre itens de trabalho relevantes de forma rápida e fácil pesquisando todos os campos de item de trabalho (incluindo campos ERE). Use uma pesquisa de texto completo em todos os campos para localizar itens de trabalho relevantes de forma eficiente. A exibição de trecho indica em que locais foram encontradas correspondências.
  • Pesquisar em campos específicos: use os filtros da pesquisa em linha rápida, em qualquer campo de item de trabalho, para restringi-lo a uma lista de itens de trabalho em poucos segundos. A lista suspensa de sugestões ajuda a preencher a pesquisa mais rapidamente. Por exemplo, uma pesquisa como AssignedTo:Chris WorkItemType:Bug State:Active encontra todos os bugs ativos atribuídos a um usuário chamado Carlos.
  • Aproveitar a integração com o acompanhamento de item de trabalho: a interface da Pesquisa de Itens de Trabalho é integrada aos controles conhecidos no hub de Trabalho, permitindo que você exiba, edite, comente, compartilhe e muito mais.

Workitem search

(Figura 4) Pesquisa de item de trabalho

Melhorias no controle de versão

Nova experiência de configuração de políticas de branch

Reformulamos a experiência de configuração de políticas de branch e adicionamos algumas novas funcionalidades excelentes (Figura 5). Um dos recursos mais avançados é a capacidade de configurar políticas para pastas de branch. Faça isso na exibição Branches, selecionando uma pasta de branch e escolhendo Políticas de branch no menu de contexto.

Configure branch policies

(Figura 5) Configurar políticas de branch

Isso abrirá a nova experiência de usuário da configuração de políticas, na qual você pode configurar as políticas que se aplicam a todos os branches na pasta de branch (Figura 6).

Policies page

(Figura 6) Página de políticas

Se você estiver usando a política de build, agora poderá configurar vários builds para um único branch. Também há novas opções para especificar um gatilho automático ou manual (Figura 7). Os gatilhos manuais são úteis para tarefas como execuções de teste automatizado que podem levar muito tempo para serem executadas e que realmente só precisam ser executadas uma vez antes do preenchimento da solicitação pull. A política de build também tem um nome de exibição que será útil se você estiver configurando vários builds.

Manual build

(Figura 7) Build manual

Depois de configurar uma política disparada manualmente, você pode executá-la selecionando a opção Enfileirar build na seção Políticas da solicitação pull (Figura 8).

Manual build queue

(Figura 8) Fila de builds manuais

Para as políticas de revisor obrigatório (Figura 9), adicionamos a capacidade de os administradores especificarem uma observação que será acrescentada à linha do tempo da solicitação pull quando a política se aplicar (Figura 10).

Required reviewer dialog

(Figura 9) Caixa de diálogo de revisor obrigatório

Required reviewer note

(Figura 10) Observação de revisor obrigatório

Nova política para comentários não ativos

Verifique se todos os comentários nas solicitações pull estão sendo examinados com a nova política Comentários. Com essa política habilitada, os comentários ativos impedirão o preenchimento da solicitação pull, forçando a resolução de todos os comentários. Os revisores que deixam comentários para o autor da solicitação pull, mas que a aprovam de forma otimista, podem ter certeza de que um autor que está ansioso para a mesclagem não perderá nenhum comentário.

Melhorias do hub de Arquivos

Fizemos várias atualizações no hub Arquivos para melhorar as experiências de exibição e edição.

Para a exibição, adicionamos pivôs que permitem exibir o LEIAME na pasta atual (Figura 11), visualizar arquivos Markdown, comparar um arquivo com uma versão anterior (Figura 12) e exibir a culpa.

Files viewing

(Figura 11) Exibição de arquivos

Files compare

(Figura 12) Comparação de arquivos

Para a edição, agora você pode visualizar as alterações, adicionar um comentário com facilidade, confirmar um novo branch e vincular itens de trabalho (Figura 13).

Files editing

(Figura 13) Edição de arquivos

Visualizar seu repositório Git

Agora você pode ver um gráfico durante a exibição do histórico de confirmações dos repositórios ou arquivos. Isso permite que você crie facilmente um modelo mental de todos os branches e todas as confirmações dos repositórios Git usando o gráfico do Git (Figura 14). O gráfico mostra todas as confirmações na ordem topológica.

Git graph

(Figura 14) Gráfico do Git

Os principais elementos do gráfico do Git incluem (Figura 15):

  1. o gráfico do Git é alinhado à direita, de forma que as confirmações associadas ao branch padrão ou ao branch selecionado sejam exibidas à direita, enquanto o restante do gráfico é expandido à esquerda.
  2. as confirmações de mesclagem são representadas por pontos cinza conectados ao seu primeiro e segundo pais.
  3. as confirmações normais são representadas por pontos azuis.
  4. se a confirmação pai de uma confirmação não estiver visível na porta de exibição nas próximas 50 confirmações, removeremos a conexão da confirmação. Depois de clicar na seta, a confirmação é conectada à sua confirmação pai.

Git graph elements

(Figura 15) Elementos do gráfico do Git

Exibir marcações do Git em confirmações

Caso sua equipe esteja usando marcações do Git para marcar um ponto específico no histórico do repositório, as confirmações agora mostrarão as marcações que você criou. Você poderá exibir as marcações (Figura 16) de uma confirmação específica na exibição Lista de confirmações e na página Detalhes.

Show tags

(Figura 16) Mostrar marcações

Adicionar marcações às confirmações

Em vez de criar marcações na linha de comando e enviá-las por push ao repositório, agora basta acessar uma confirmação e adicionar uma marcação (Figura 17). A caixa de diálogo de criação de marcação também permitirá marcar outras referências no repositório.

Create tag details

(Figura 17) Criar detalhes da marcação

A exibição de lista de confirmações também dá suporte a um menu de contexto (Figura 18). Não é mais necessário acessar a página Detalhes da confirmação para criar marcações e criar novos branches (Figura 19).

Create tag history

(Figura 18) Criar histórico de marcações

Tag branch

(Figura 19) Branch de marcação

Páginas de conjunto de alterações e check-in particular atualizadas

Modernizamos as páginas de conjunto de alterações e check-in particular no TFVC. Ambas as páginas ficaram mais acessíveis para aqueles que usam tecnologias adaptativas. As novas páginas também trazem um novo cabeçalho que contém o título do conjunto de alterações e as informações associadas sobre o conjunto de alterações, como detalhes do autor (Figura 20).

Changeset page

(Figura 20) Página de conjunto de alterações

As páginas de conjunto de alterações e check-in particular também hospedam um novo controle de discussão markdown (Figura 21) que permitirá digitar comentários em markdown, usar @mention para usuários, associar itens de trabalho usando # e anexar arquivos e imagens com facilidade.

Changeset discussion

(Figura 21) Discussão do conjunto de alterações

Filtragem de confirmação aprimorada

Agora você pode filtrar os resultados do histórico de confirmações (Figura 22) com opções de filtragem avançada. É possível filtrar as confirmações pelo:

  • histórico completo.
  • histórico completo com mesclagens simplificadas.
  • primeiro pai.
  • histórico simples (essa é a configuração de filtro padrão).

Improved commit filtering

(Figura 22) Filtragem de confirmação aprimorada

Importar repositórios do TFVC para o Git

Migre um código de seus repositórios do TFVC para repositórios Git na mesma conta. Para iniciar a migração, selecione Importar repositório no menu suspenso do seletor de repositório (Figura 23).

Repository selector drop-down

(Figura 23) Menu suspenso do seletor de repositório

Pastas ou branches individuais podem ser importados para o repositório Git ou todo o repositório do TFVC pode ser importado (menos os branches) (Figura 24). Você também pode importar até 180 dias de histórico.

Import repo complete

(Figura 24) Preenchimento de Importar repositório

Bloqueio de arquivos do Git LFS

Adicionamos o recurso bloqueio de arquivos do Git LFS. Isso permite que as equipes trabalhem com arquivos grandes e incomparáveis para evitar a perda de trabalho quando duas ou mais pessoas tentam editar o mesmo arquivo de uma só vez. Antes que uma pessoa possa começar a editar o arquivo, ela usa um bloqueio, o que notifica o servidor. Quando qualquer outra pessoa tenta usar um bloqueio, o servidor rejeita a solicitação, informando a segunda pessoa que alguém já está trabalhando no arquivo. Faça upgrade para o Git LFS 2.1 ou posterior para usar esse recurso.

Os comentários de confirmação do Git usam o novo controle de discussão

Os comentários leves deixados nas confirmações do Git foram atualizados para usar o novo controle de discussão. Isso dá suporte a Markdown nesses comentários e completa todos os recursos de comentários de código na Web para que o Git e o TFVC usem a última experiência.

Novo controle de exibição de árvore

A exibição Arquivos da Solicitação Pull, os detalhes da confirmação do Git, os detalhes do push do Git, os detalhes do Check-in particular do TFVC, os detalhes do Conjunto de alterações do TFVC, o hub de Conjuntos de alterações do TFVC e o hub do histórico do Git foram atualizados com um novo controle de exibição de árvore (Figura 25). O modo de exibição de árvore traz algumas melhorias de usabilidade. Primeiro, alteramos a exibição para mostrar um modo de exibição de árvore condensado que recolhe automaticamente os nós de pastas vazias, maximizando o número de arquivos na exibição.

A árvore também mostra os comentários de forma mais compacta. Arquivos com comentários mostram um item filho para cada thread de comentário, com o avatar indicando o usuário que criou o thread. Novos threads de comentário e aqueles com respostas são indicados pelo ponto azul e a contagem de respostas é resumida com uma contagem.

New tree view

(Figura 25) Novo modo de exibição de árvore

Melhorias da solicitação pull

CTAs aprimorados para o autor da solicitação pull e os revisores

Para as equipes que usam políticas de branch, às vezes, é difícil saber exatamente qual ação é necessária ao exibir uma solicitação pull. Se o principal plano de ação for o botão Preencher, isso significa que ele está pronto para ser preenchido? Usando as informações sobre a pessoa que está exibindo a página e o estado das políticas de branch configuradas, a exibição da solicitação pull agora apresentará o plano de ação que faz mais sentido para o usuário.

Quando as políticas estiverem configuradas, mas ainda não estiverem sendo passadas, o botão Preencher (Figura 26) agora incentivará o uso do recurso Preenchimento automático. Não é provável que você poderá preencher a solicitação pull com êxito se as políticas estiverem bloqueando-a. Portanto, oferecemos uma opção que preencherá a solicitação pull quando essas políticas acabarem sendo passadas.

 Auto-complete feature

(Figura 26) Recurso Preenchimento automático

Para os revisores, é mais provável que você desejará aprovar uma solicitação pull do que preenchê-la. Portanto, os revisores verão o botão Aprovar (Figura 27) realçado como o principal CTA, caso você ainda não a tenha aprovado.

CTA approve

(Figura 27) Aprovação de CTA

Após a aprovação, os revisores verão o botão Preencher (ou Preenchimento automático) realçado como o CTA nos casos em que um revisor também for a pessoa que está preenchendo a solicitação pull.

Comentários acionáveis

Em uma solicitação pull com mais do que alguns comentários, pode ser difícil manter o controle de todas as conversas. Para ajudá-lo a gerenciar melhor os comentários, simplificamos o processo de resolução de itens que foi abordado com uma série de melhorias:

  • No cabeçalho de cada solicitação pull, agora você verá uma contagem dos comentários que foram resolvidos (Figura 28).

PR header

(Figura 28) Cabeçalho da solicitação pull

  • Quando um comentário tiver sido examinado, você poderá resolvê-lo com um único clique (Figura 29).

Resolve button

(Figura 29) Botão Resolver

  • Se você tiver comentários para adicionar enquanto estiver resolvendo outros, poderá responder e resolvê-los com um único gesto (Figura 30).

Reply and resolve

(Figura 30) Responder e resolver

  • Conforme os comentários são resolvidos, você verá a contagem subir até que tudo tenha sido examinado (Figura 31).

Comment count address rate

(Figura 31) Taxa de exame da contagem de comentários

  • O filtro na Visão Geral foi aprimorado para permitir a filtragem por vários estados de comentário e mostrar a contagem de comentários para cada opção de filtro (Figura 32).

Filter improvements

(Figura 32) Melhorias de filtro

Exibição Atualizações mostra trocar base e forçar push

Na exibição Detalhes da Solicitação Pull, a guia Atualizações foi aprimorada para mostrar quando ocorreu um push por força e se a confirmação base foi alterada (Figura 33). Esses dois recursos serão realmente úteis se você trocar a base das alterações nos branches do tópico antes de preencher as solicitações pull. Agora os revisores terão informações suficientes para saber exatamente o que aconteceu.

Updates views

(Figura 33) Exibições Atualizações

Filtragem de solicitação pull por pessoas

Agora ficou mais fácil encontrar as solicitações pull! Adicionamos novas opções de filtragem para que você possa encontrar as solicitações pull criadas por um autor específico ou atribuídas a um revisor específico (Figura 34). Basta selecionar um usuário no filtro de autor ou revisor e a lista será atualizada para mostrar apenas as solicitações pull que correspondem ao filtro.

Filtering by people

(Figura 34) Filtragem por pessoas

Motivo obrigatório ao ignorar políticas de solicitação pull

Quando você estiver ignorando uma política de solicitação pull, deverá especificar um motivo. Na caixa de diálogo Preencher solicitação pull, você verá um novo campo Motivo, caso você opte por ignorá-la (Figura 35).

Bypass dialog

(Figura 35) Caixa de diálogo Ignorar

Depois de inserir o motivo e preencher a solicitação pull, a mensagem será exibida na Visão Geral (Figura 36).

Bypass message

(Figura 36) Mensagem do bypass

Compartilhar solicitações pull com equipes

A ação Compartilhar Solicitação Pull é uma maneira prática de notificar os revisores (Figura 37). Nesta versão, adicionamos suporte para equipes e grupos e, portanto, você pode notificar todos os envolvidos na solicitação pull com uma única etapa.

Share PR with teams

(Figura 37) Compartilhar solicitação pull com equipes

Melhorias de solicitação pull para equipes

Se você for membro de várias equipes, agora verá todas as solicitações pull atribuídas a essas equipes listadas na exibição Minhas Solicitações Pull (Figura 38). Isso torna a exibição Minhas Solicitações Pull o único local que você precisa visitar para ver todas as solicitações pull atribuídas a você.

PR improvements for teams

(Figura 38) Melhorias de solicitação pull para equipes

Em uma versão futura, adicionaremos equipes ao hub Solicitações Pull em Código para facilitar a visualização de todas as solicitações pull de um único projeto.

Notificações padrão para comentários de solicitação pull

Mantenha-se atualizado com as conversas que estão acontecendo nas solicitações pull com as novas notificações de comentário (Figura 39). Para as solicitações pull que você criou, você será notificado automaticamente sempre que um usuário adicionar um novo thread de comentário ou responder a um thread existente. Quando você comenta uma solicitação pull de outro usuário, você será notificado sobre as respostas futuras dos threads de comentário que você criou ou aos quais respondeu.

Default PR notifications

(Figura 39) Notificações padrão de solicitação pull

Essas notificações estão disponíveis como parte das assinaturas prontas para uso e são configuráveis na página de configurações Notificações.

Melhorias no Gerenciamento de Pacotes

Experiência de Gerenciamento de Pacotes atualizada

Atualizamos a experiência de usuário do Gerenciamento de Pacotes para torná-la mais rápida, resolver problemas comuns relatados pelo usuário e liberar espaço para os próximos recursos do ciclo de vida do pacote (Figura 40). Saiba mais sobre a atualização na página Experiência atualizada.

Package Management

(Figura 40) Gerenciamento de Pacotes

O Gerenciamento de Pacotes adiciona LEIAMEs npm e um botão de download

Agora você pode ver o LEIAME de qualquer pacote npm que inclui um README.md no pacote (Figura 41). Arquivos Leiame pode ajudar seu conhecimento de documento e o compartilhamento de equipe sobre seus pacotes.

Também é possível baixar qualquer pacote npm usando o botão Baixar na barra de comandos.

Package Management npm README

(Figura 41) LEIAME npm do Gerenciamento de Pacotes

Tarefas de build Restauração, Comando e Instalador de Ferramenta do NuGet

Fizemos atualizações importantes na tarefa Instalador do NuGet (agora chamada Restauração do NuGet) e adicionamos duas novas tarefas do NuGet: Comando do NuGet e Instalador de Ferramenta do NuGet. Especialmente, as tarefas Comando do NuGet e Restauração do NuGet agora usam o nuget.exe 4.0.0 por padrão.

O Instalador de Ferramenta do NuGet coloca você no controle da versão do NuGet usada pelas tarefas Restauração do NuGet e Comando do NuGet. Por padrão, as tarefas usarão uma versão testada e bem conhecida. Caso você deseje substituir isso, basta adicionar uma etapa Instalador de Ferramenta do NuGet antes das outras etapas de build do NuGet.

Agora a Restauração do NuGet foi otimizada para o cenário mais comum de restauração de pacotes antes de uma etapa de Build do Visual Studio. Ela também tem um melhor suporte para projetos pequenos que compartilham um único feed do NuGet: agora você pode escolher um feed do Team Services e adicioná-lo a um NuGet.Config gerado automaticamente.

Para operações mais complexas do NuGet, a tarefa Comando do NuGet fornece a flexibilidade para especificar qualquer comando e um conjunto de argumentos (Figura 42).

NuGet command

(Figura 42) Comando do NuGet

Melhorias de build e versão

Novo editor de definição de build

Reformulamos nosso editor de definição de build para fornecer uma experiência mais intuitiva, corrigir alguns problemas e adicionar novas funcionalidades. Esperamos que fique mais fácil usar modelos, adicionar tarefas e alterar configurações. E agora você pode usar parâmetros de processo para facilitar a especificação dos bits de dados mais importantes, sem precisar se aprofundar nas tarefas.

Procurar um modelo

Pesquise o modelo desejado e, em seguida, aplique-o ou comece com um processo vazio (Figura 43).

Build template search

(Figura 43) Pesquisa de modelo de build

Encontrar e adicionar uma tarefa de forma rápida exatamente no local desejado

Procure a tarefa que você deseja usar e, em seguida, depois de encontrá-la, adicione-a após a tarefa selecionada no momento no lado esquerdo ou arraste e solte-a no local desejado (Figura 44).

Build task search

(Figura 44) Pesquisa de tarefa de build

Também é possível arrastar e soltar uma tarefa para movê-la ou arrastar e soltá-la enquanto mantém pressionada a tecla Ctrl, para copiar a tarefa.

Usar parâmetros de processo para passar argumentos de chave para as tarefas

Agora você pode usar parâmetros de processo (Figura 45) para facilitar a especificação dos bits de dados mais importantes por aqueles que usam a definição de build ou o modelo, sem precisar se aprofundar nas tarefas.

Process parameters

(Figura 45) Parâmetros de processo

Se você criar um novo build com base em alguns dos modelos internos (por exemplo Visual Studio e Maven), poderá ver exemplos de como eles funcionam.

O novo editor inclui algumas outras melhorias, como a concessão de acesso mais rápido às configurações de fontes.

Para obter um passo a passo da criação de sua primeira definição de build usando o novo editor, consulte CI/CD para iniciantes.

Saiba mais na página Experiência de usuário em 2017.

Tarefas de build condicionais

Caso você esteja buscando ter mais controle sobre as tarefas de build, como uma tarefa para limpar itens ou enviar uma mensagem em caso de erros, agora estamos oferecendo quatro opções internas para controlar quando uma tarefa é executada (Figura 46).

Conditional build tasks

(Figura 46) Tarefas de build condicionais

Caso você esteja buscando mais flexibilidade, como uma tarefa para executar apenas determinados branches, com determinados gatilhos, sob determinadas condições, poderá expressar suas próprias condições personalizadas:

and(failed(), eq(variables['Build.Reason'], 'PullRequest'))

Consulte a página Especificar condições para execução de uma tarefa.

Tarefas internas para compilar e implantar aplicativos baseados em contêiner

Com esta versão, extraímos a maioria das tarefas de nossa extensão do Docker e as incorporamos ao produto por padrão, aprimoramos essas tarefas e introduzimos um conjunto de novas tarefas e novos modelos para facilitar um conjunto de cenários de contêiner.

  • Docker: compile, envie por push ou execute imagens do Docker ou execute um comando do Docker. Essa tarefa pode ser usada com o Registro do Docker ou do Contêiner do Azure. Agora você pode usar nossa autenticação de entidade de serviço interna com o ACR para torná-lo ainda mais fácil de usar.
  • Docker-Compose: compile, envie por push ou execute aplicativos do Docker de vários contêineres. Essa tarefa pode ser usada com o Registro do Docker ou do Contêiner do Azure.
  • Kubernetes: implante, configure ou atualize seu cluster Kubernetes no Serviço de Contêiner do Azure executando comandos kubectl.
  • Service Fabric: implante contêineres em um Cluster do Service Fabric. O Service Fabric é a melhor opção hoje para execução de Contêineres do Windows na nuvem.

Atualizações de implantação do Aplicativo Web do Azure

Fizemos várias melhorias nos Aplicativos Web do Azure:

  • A tarefa de implantação do Serviço de Aplicativo do Azure dá suporte a arquivos Java WAR, Node.js, Python e aplicativos PHP a serem implantados.
  • A tarefa de implantação do Serviço de Aplicativo do Azure dá suporte à implantação no Aplicativo Web do Azure para Linux com o uso de contêineres.
  • A Entrega Contínua do portal do Azure agora foi expandida e dá suporte a aplicativos Node.
  • A tarefa de gerenciamento do Serviço de Aplicativo do Azure foi adicionada à troca de Iniciar, Parar, Reiniciar ou Slot em um Serviço de Aplicativo do Azure. Ela também dá suporte a instalação de extensões de site para habilitar a instalação da versão necessária do PHP ou do Python ou a instalação do Gerenciador do IIS ou do Application Insights.

Também introduzimos o suporte ao CI/CD na última versão da CLI do Azure para configurar o CI/CD. Veja um exemplo:

az appservice web source-control config --name mywebapp --resource-group mywebapp_rg --repo-url https://myaccount.visualstudio.com/myproject/_git/myrepo --cd-provider vsts --cd-app-type AspNetCore

As tarefas do .NET Core dão suporte a arquivos de projeto

Com a atualização atual, estamos aprimorando as tarefas do .NET Core para dar suporte a arquivos *.csproj, além de project.json. Agora você pode usar o Visual Studio 2017 em seus agentes de build para compilar aplicativos do .NET Core usando arquivos csproj.

Melhorias de implantação do SSH

A tarefa de build/versão Copiar Arquivos Pelo SSH agora dá suporte ao til (~) no caminho de destino para simplificar a cópia de arquivos para o diretório base de um usuário remoto. Além disso, uma nova opção permite a falha do build ou da versão quando não são encontrados arquivos para cópia.

A tarefa de build/versão do SSH agora dá suporte à execução de scripts com terminações de linha do Windows em computadores Linux ou macOS remotos.

Instalar uma chave SSH durante um build ou uma versão

Uma nova tarefa de visualização, Instalar Chave SSH (Visualização), instala uma chave SSH antes de um build ou uma versão e a remove do agente após a conclusão do build ou da versão. A chave instalada pode ser usada para buscar um código em um repositório ou submódulos do Git, executar scripts de implantação ou outras atividades que exigem a autenticação SSH. Ela será aprimorada no futuro para dar suporte a frases secretas e outras funcionalidades.

As tarefas falham se o Visual Studio 2017 é especificado, mas não está presente no agente

As tarefas Build do Visual Studio e MSBuild permitem selecionar uma versão específica do Visual Studio. Até agora, se a versão Visual Studio 2017 não estivesse disponível, essas tarefas escolheriam automaticamente a próxima versão disponível.

Estamos alterando esse comportamento. Agora, o build falhará se você selecionar Visual Studio 2017, mas ele não estiver presente no agente.

Fizemos essa alteração pelos seguintes motivos:

  • Tipos de aplicativo mais recentes como o .NET Core não são compilados com ferramentas de build mais antigas. Eles exigem explicitamente o Visual Studio 2017 ou mais recente.

  • Você obtém resultados mais consistentes e previsíveis quando usa exatamente a mesma versão do Visual Studio.

  • Sempre que ocorrer fallback nas tarefas de build, poderão ocorrer erros de compilação que são de difícil compreensão.

Dica

Lembre-se de usar uma fila conectada a um pool que tem agentes com o Visual Studio 2017 e nenhum agente que tem somente versões anteriores do Visual Studio.

Limpeza automática de espaço de trabalho de agente privado

Agora você pode configurar um pool de agentes para limpar periodicamente diretórios de trabalho e repositórios obsoletos (Figura 47). Por exemplo, o pool excluirá espaços de trabalho deixados para trás pelas definições de build e versão excluídas.

Agent maintenance

(Figura 47) Manutenção de agente

O uso dessa opção deve reduzir o potencial de os agentes privados de build e versão ficarem sem espaço em disco. A manutenção é feita por agente (não por computador). Portanto, se você tiver vários agentes em um único computador, ainda poderá ter problemas de espaço em disco.

Status de upgrade do agente de build

Quando um agente está sendo atualizado, ele agora indica o status do upgrade no portal de gerenciamento de filas e pools.

Seleção de agentes privados em computadores que não estão em uso

O sistema agora usa o nome do computador como um fator ao alocar um build ou uma versão a um agente privado. Como resultado, o sistema preferirá um agente em um computador ocioso do que um agente em um computador ocupado quando alocar o trabalho.

Melhorias de DevOps do iOS

A extensão da Apple App Store agora dá suporte à verificação em duas etapas (autenticação de dois fatores) e à liberação de builds para testadores externos (Figura 48).

Apple App Store connection

(Figura 48) Conexão à Apple App Store

Instalar Certificado da Apple (Visualização) é uma nova tarefa de build que instala um certificado de autenticação P12 no agente para uso por um build posterior do Xcode ou Xamarin.iOS.

Instalar Perfil da Apple (Visualização) é uma nova tarefa de build para a instalação de perfis de provisionamento no agente para uso por um build posterior do Xcode ou Xamarin.iOS.

As tarefas de build do MSBuild, Xamarin.Android e Xamarin.iOS agora dão suporte à compilação com o conjunto de ferramentas do Visual Studio para Mac.

Melhorias de cobertura de código Java

A tarefa de build Publicar Resultados da Cobertura de Código relata a cobertura de código Cobertura ou JaCoCo como parte de um build. Agora ela dá suporte á especificação de padrões de curingas e mini-correspondências nos campos Arquivo de Resumo e Diretório de Relatório, permitindo que os arquivos e diretórios sejam resolvidos por build para caminhos que são alterados entre builds.

Melhorias do Maven e do SonarQube

A tarefa de build do Maven agora permite especificar um projeto do SonarQube para resultados da análise nos casos em que ele é diferente do que foi especificado no arquivo pom.xml do Maven.

Integração aprimorada do Jenkins

A tarefa de build/versão Trabalho da Fila do Jenkins agora dá suporte à execução de trabalhos de pipeline de vários branches do Jenkins durante a exibição da saída do console do Jenkins no Team Services (Figura 49). Os resultados do pipeline são publicados no resumo de build do Team Services.

Improved Jenkins integration

(Figura 49) Integração aprimorada do Jenkins

Implantação do conjunto de dimensionamento de máquinas virtuais do Azure

Um padrão comum que está sendo usado para implantação é criar uma imagem de computador completa para cada versão do aplicativo e, em seguida, implantá-la. Para facilitar, temos uma nova tarefa Criar imagem de computador imutável. Essa tarefa usa o Packer para gerar uma imagem de computador após a implantação de aplicativos e todos os pré-requisitos necessários. A tarefa usa o script de implantação ou o modelo de configuração do Packer para criar a imagem de computador e a armazena em uma conta de Armazenamento do Azure. Essa imagem pode, então, ser usada para implantações de conjunto de dimensionamento de máquinas virtuais do Azure que funcionam bem com esse tipo de implantação de imagem imutável.

Substituir parâmetros de modelo em implantações de grupo de recursos do Azure

No momento, nas tarefas de implantação de grupo de recursos do Azure, os usuários selecionam o template.json e o parameters.json e fornecem os valores de parâmetro de substituição em uma caixa de texto, após uma sintaxe específica. Essa experiência agora foi aprimorada, de forma que os parâmetros de modelo sejam renderizados em uma grade que permite sua edição e substituição (Figura 50). Acesse esse recurso clicando em ... ao lado do campo dos parâmetros de substituição, o que abre uma caixa de diálogo com os parâmetros de modelo junto com seus valores padrão e os valores permitidos (caso tenham sido definidos nos arquivos .json do modelo e do parâmetro). Esse recurso exige que as regras do CORS sejam habilitadas na fonte. Se os arquivos json do modelo e do parâmetro estiverem no Azure Storage Blob, consulte a documentação dos Serviços de Armazenamento do Azure para habilitar o CORS.

Azure RG parameters

(Figura 50) Parâmetros de RG do Azure

Vários gatilhos de versão com filtros de branch e marcação

O gerenciamento de versão agora dá suporte à configuração de gatilhos CD em várias fontes de artefato do tipo “Build”. Quando adicionados, uma nova versão é criada automaticamente quando uma nova versão de artefato está disponível para uma das fontes de artefato especificadas. Você também pode especificar o branch de origem do novo build para disparar uma versão. Além disso, os filtros de Marcação podem ser configurados para filtrar ainda mais os builds que devem disparar uma versão.

Definir padrões para fontes de artefato em uma versão

Os usuários podem definir a versão de artefato padrão a ser implantada em uma versão ao vincular uma fonte de artefato em uma definição (Figura 51). Quando uma versão é criada automaticamente, a versão padrão de todas as fontes de artefato são implantadas.

Default artifact version

(Figura 51) Versão de artefato padrão

Separação de tarefas para o solicitante da implantação e aprovadores

Anteriormente, os proprietários do ambiente podiam restringir os criadores da versão de aprovar as implantações da versão em um ambiente. No entanto, era possível iniciar manualmente a implantação de uma versão criada por outro usuário e aprová-la por conta própria.

Agora estamos preenchendo essa lacuna considerando o criador da implantação como uma função de usuário separada para implantações. O criador da versão ou o criador da implantação podem ser restringidos de aprovar as implantações.

Aprovações no nível da versão

Agora você pode optar por aprovar automaticamente as implantações que foram disparadas automaticamente após uma implantação bem-sucedida em outro ambiente (Figura 52). A aprovação de uma cadeia de implantações (que tem os mesmo aprovadores) pode ser feita de uma só vez, caso você opte por não aprovar cada implantação.

Digamos que você tenha dois ambientes Desenvolvimento e Teste, com os aprovadores de pré-implantação definidos como “userA” e “userB”, ambos obrigados a aprovar a implantação. Se a política do Teste for definida conforme mostrado abaixo, durante o tempo de implantação, será suficiente para o userA e userB aprovarem apenas o Desenvolvimento. A implantação no Teste obterá a aprovação automática. Se a implantação no Teste for disparada manualmente, as aprovações serão necessárias antes da implantação, para garantir as aprovações corretas.

Release level approvals

(Figura 52) Aprovações no nível da versão

Implantar na Nuvem do Azure Governamental

Agora os clientes com assinaturas do Azure em Nuvens Governamentais podem configurar um ponto de extremidade de serviço do Azure Resource Manager para direcionar nuvens nacionais.

Com isso, agora você pode usar o Release Management para implantar qualquer aplicativo nos recursos do Azure hospedados em nuvens governamentais, usando as mesmas tarefas de implantação (Figura 53).

Government cloud

(Figura 53) Nuvem governamental

Definir o número máximo de implantações paralelas

Esse recurso fornece controle sobre como várias versões pendentes são implantadas em um ambiente específico (Figura 54). Por exemplo, se o pipeline da versão executar a validação de builds em um ambiente de garantia de qualidade e a taxa de geração de builds for mais rápida do que a taxa de conclusão das implantações, você poderá configurar vários agentes e quantos builds desejar para serem validados em paralelo. Isso significa que cada um dos builds gerados é validado e o tempo de espera depende do número de agentes disponíveis. Com esse recurso, permitimos que você otimize as validações possibilitando a execução da validação nos n builds mais recentes em paralelo e o cancelamento das solicitações de implantação mais antigas.

Parallel deployments

(Figura 54) Implantações paralelas

Melhorias de tempo limite para a tarefa Intervenção Manual

A tarefa Intervenção Manual agora pode ser rejeitada ou continuada automaticamente depois de ficar pendente durante o tempo limite especificado ou por 60 dias, o que ocorrer primeiro. O valor de tempo limite pode ser especificado na seção de opções de controle da tarefa.

Execução paralela do Release Management

Agora o Release Management dá suporte a uma opção de execução paralela em uma fase (Figura 55). Selecione esta opção para realizar fan-out de uma fase usando Várias Configurações ou Vários Agentes como uma opção de multiplicador de fase.

Parallel execution support

(Figura 55) Suporte de execução paralela

Várias configurações: selecione essa opção para executar a fase para cada valor de várias configurações. Por exemplo, se você desejar implantar em duas geografias diferentes ao mesmo tempo, usar uma variável ReleasePlatform definida na guia Variáveis com os valores “east-US, west-US” executará a fase em paralelo, uma com um valor “east-US” e a outra “west-US”. Vários agentes: selecione essa opção para executar a fase com uma ou mais tarefas em vários agentes em paralelo.

Histórico de implantação de aplicativo Web no portal do Azure

O gerenciamento de versão agora atualiza os logs de implantação do Serviço de Aplicativo do Azure quando uma implantação é feita usando a tarefa de implantação do Serviço de Aplicativo. Exiba o histórico de implantações no portal do Azure selecionando a opção Entrega contínua na folha Serviço de Aplicativo.

Melhorias de testes

Executar testes usando fases do agente

Com a tarefa Teste do Visual Studio, agora você pode executar testes automatizados usando fases do agente (Figura 56).

Agora temos um agente de automação unificado no build, na versão e no teste. Isso traz os seguintes benefícios:

  1. Você pode utilizar um pool de agentes para suas necessidades de teste.
  2. Execute testes em modos diferentes usando a mesma tarefa de Teste do Visual Studio, de acordo em suas necessidades – execução baseada em um único agente, execução de teste distribuído baseada em vários agentes ou uma execução de várias configurações na qual os testes são executados, suponhamos, em navegadores diferentes.

Run tests using Agent Phases

(Figura 56) Executar testes usando Fases do Agente

Para obter mais informações, consulte a postagem Gerenciamento do Ciclo de Vida do Aplicativo da Microsoft.

Gatilho sob demanda de testes automatizados

O hub Teste agora dá suporte ao gatilho de casos de teste automatizado em planos de teste e conjuntos de testes (Figura 57). A execução de testes automatizados no hub Teste precisará de uma configuração semelhante à forma como os testes são executados de forma agendada em ambientes de versão. Você precisará configurar um ambiente na definição de versão usando o modelo Executar testes automatizados em planos de teste e associar o plano de teste para executar os testes automatizados. Consulte a documentação para obter as diretrizes passo a passo sobre como configurar ambientes e executar testes automatizados no hub Teste.

On-demand automated tests trigger

(Figura 57) Gatilho de testes automatizados sob demanda

Aprimoramentos de administração

Destinatários de email combinados para notificações

Os destinatários da mesma notificação de email agora são incluídos juntos na linha para: e recebem um único email. Anteriormente, eram enviados emails individuais para cada destinatário. Ficava difícil saber quem mais recebeu a notificação e ter uma conversa sobre o evento por email. Esse recurso se aplica às assinaturas prontas para uso, bem como às assinaturas de equipe que têm a capacidade de direcionar vários destinatários. Por exemplo, todos os revisores de uma solicitação pull agora recebem um único email quando uma alteração é feita na solicitação pull.

Saiba mais sobre como combinar destinatários de email.

Notificações prontas para uso

Os usuários e as equipes agora são notificados automaticamente por email quando há uma atividade na conta diretamente relevante para eles, como:

  • quando um item de trabalho é atribuído a um usuário.
  • quando um usuário ou uma equipe é adicionado como revisor de uma solicitação pull.
  • quando um usuário ou uma equipe é um revisor de uma solicitação pull que é atualizada.
  • quando outro usuário responde a um comentário da solicitação pull.
  • quando um build solicitado por um usuário é concluído.
  • quando uma extensão é instalada ou solicitada (somente administradores).

Os usuários podem cancelar a assinatura de uma dessas assinaturas acessando as configurações Notificação no menu do perfil do usuário e, em seguida, desativando as alternâncias apropriadas.

Um administrador de conta pode desabilitar uma ou mais dessas assinaturas automáticas acessando o hub Notificações da coleção na engrenagem de configurações. Qualquer uma dessas assinaturas pode ser desabilitada clicando em Desabilitar na ação “...”. Depois que uma assinatura for desabilitada, ela deixará de ser exibida para os usuários em suas páginas de configurações de notificação pessoais.

Saiba mais sobre as notificações prontas para uso.

Permissões do gerenciamento de extensões

Agora um administrador pode conceder a outros usuários e grupos a permissão para gerenciar extensões da coleção (Figura 58). Anteriormente, somente os administradores da coleção (ou seja, membros do grupo Administradores da Coleção do Projeto) podiam examinar as solicitações de extensão, instalar, desabilitar ou desinstalar extensões.

Para conceder essa permissão, um administrador pode acessar o hub de administração Extensões abrindo o menu do Marketplace, selecionando Gerenciar extensões e, em seguida, clicar no botão Segurança:

Extension management permissions

(Figura 58) Permissões do gerenciamento de extensões

Ser notificado quando extensões são instaladas, exigem atenção e outros

Os administradores ou aqueles com a capacidade de gerenciar extensões, agora são notificados automaticamente quando uma extensão é instalada, desinstalada, habilitada, desabilitada ou exige atenção. Isso é especialmente útil em implantações grandes em que várias pessoas têm a responsabilidade de gerenciar extensões. Os administradores podem desligar essas notificações acessando as configurações Notificação no menu do perfil e desligando a alternância de extensões.

Os administradores também podem definir assinaturas personalizadas para eventos relacionados à extensão. Por exemplo, um administrador pode ser notificado sempre que uma extensão é atualizada.

Os usuários agora também podem desativar notificações automáticas sobre suas solicitações de extensão.

Permitindo que os administradores do TFS adicionem assinantes ao nível de acesso avançado

O nível de acesso Avançado será removido das versões futuras do Team Foundation Server. No entanto, até isso acontecer, os administradores do TFS poderão adicionar os assinantes do MSDN Platform e do Visual Studio Test Professional ao nível de acesso Avançado com a Atualização 2.

Os assinantes do Visual Studio Enterprise devem ser adicionados ao nível de acesso do Visual Studio Enterprise em vez de ao Avançado. Caso você tenha comprado a extensão Gerenciador de Teste, continue gerenciando-a no hub Usuários, no Projeto de Equipe em que você fez a compra.


Problemas conhecidos

Os formulários de itens de trabalho não são renderizados corretamente na Web

  • Problema:

    Se você tiver um controle personalizado (como o controle de vários valores) instalado para o cliente do Visual Studio, mas não tiver o cliente Web, os formulários de item de trabalho na web falham ao ser renderizados.

  • Solução alternativa:

    Você precisará atualizar para a versão mais recente do seu controle. É necessário adicionar um layout da Web que não contém o elemento de controle ausente. Encontre o último controle de vários valores para a Atualização do TFS 2017 na página Controles personalizados para acompanhamento de item de trabalho do TFS. Para obter mais informações sobre o layout, consulte a página Todas as referências de elementos XML FORM (TFS 2015).


The Developer Community Portal Consulte os problemas relatados pelos clientes para o Team Foundation Server 2017.