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

---

Developer Community Recursos | de sistema etermos | de licença de compatibilidade | Do blog TFS DevOps Blog | SHA-1 HashesLatest Visual Studio 2019 Releases Notes (Notas sobre as versões | mais recentes do Visual Studio 2019)

---

---

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

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

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

---

Data de lançamento do sobre a versão: 24 de julho de 2017

Resumo das novidades no Team Foundation Server 2017 Atualização 2

Adicionamos diversas novidades importantes no Team Foundation Server 2017 Atualização 2. Alguns dos destaques incluem:

• Os itens de trabalho agora têm ícones associados a cada tipo de item de trabalho.
• Introduzimos Planos de Entrega.
• Procure itens de trabalho usando a Pesquisa de Itens de Trabalho.
• Há uma nova experiência de configuração de políticas de branch.
• Ocorreram diversas melhorias de solicitações pull.
• Agora há gráficos do Git para visualizar o histórico do Git.
• Agora você pode adicionar e exibir marcações do Git.
• Temos uma nova experiência de Gerenciamento de Pacotes.
• Há uma nova experiência do editor de definição de build.
• Várias atualizações durante a implantação nos Aplicativos Web do Azure.
• Várias melhorias durante a implantação de contêineres.
• Introduzimos tarefas de build condicionais.
• Agora, há notificações prontas para uso.

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

• Acompanhamento de item de trabalho
• Controle de versão
• Solicitações pull
• Gerenciamento de Pacotes
• Build e versão
• Teste
• Warehouse
• Administração
• Integração do Microsoft Teams

---

Detalhes das novidades no TFS 2017 Atualização 2

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

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

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 do Marketplace para saber mais e instalar a extensão.

Para usuários com uma instância do TFS desconectada da Internet, os Planos de Entrega estão disponíveis diretamente por meio da opção Gerenciar extensões no acesso via Web, sem a necessidade de navegar para o VSTS Marketplace. Em Gerenciar extensões, clique em Procurar extensões locais, em seguida, selecione Planos de Entrega e clique em Instalar. Consulte a documentação sobre extensões pré-instaladas para obter mais informações.

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

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

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

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

Se você está usando a política de build, agora é possível 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 é útil no caso de configuração de vários builds.

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 de pull (Figura 8) .

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

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

Verifique se a nova política Comentários é aplicada a todos os comentários nas solicitações de pull. 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 PR, 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 a uma versão anterior (Figura 12) e exibir o blame.

>

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

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.

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 são exibidas à direita, enquanto o restante do gráfico é expandido à esquerda.
2. As confirmações de mesclagem são representadas por pontos cinzas conectados ao primeiro pai e ao segundo pai.
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, a conexão da confirmação será removida. Depois de clicar na seta, a confirmação é conectada à sua confirmação pai.

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 de lista de confirmações e na página de detalhes.

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.

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

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

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.

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

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

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.  

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, e esse bloqueio 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 de 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.

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 a chamada de ação principal é o botão Concluir, isso significa que ela está pronta para ser concluída? 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 há políticas configuradas, mas não há aprovação, o botão Concluir(Figura 26) agora incentiva o uso do recurso Conclusão Automática.  Provavelmente você não poderá concluir a PR com êxito se houver políticas a bloqueando. Portanto, oferecemos uma opção que concluirá a solicitação de pull quando ela for aprovada por essas políticas.

Para os revisores, é mais provável que eles desejem aprovar uma solicitação de pull do que a concluir. Portanto, os revisores verão o botão Aprovar(Figura 27) realçado como a chamada de ação principal, caso ainda não tenham aprovado.

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 ajudar no gerenciamento de comentários, simplificamos o processo de resolução de itens com uma série de melhorias:

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

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

• Se você tem comentários para adicionar enquanto está resolvendo, responda e resolva-os com um único gesto (Figura 30) .

• Conforme os comentários são resolvidos, a contagem aumenta até que tudo seja examinado (Figura 31) .

• O filtro na Visão Geral foi melhorado 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) .

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 extremamente úteis se você trocar a base das alterações nos branches do tópico antes de concluir as PRs.  Agora os revisores terão informações suficientes para saber exatamente o que aconteceu.

Filtragem de solicitação pull por pessoas

Agora ficou mais fácil encontrar as solicitações de pull! Adicionamos novas opções de filtragem para que você possa encontrar as PRs 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 PRs que correspondem ao filtro. 

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

Depois de inserir o motivo e concluir a solicitação de pull, a mensagem é exibida na Visão geral(Figura 36).

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 para que você possa notificar todos os envolvidos na solicitação de pull com uma única etapa.

Melhorias de solicitação pull para equipes

Se você for membro de várias equipes, agora verá todas as PRs atribuídas a essas equipes, listadas na exibição Minhas Solicitações de 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ê.

Em uma versão futura, adicionaremos equipes ao hub Solicitações de Pull em Código para facilitar a visualização de todas as PRs 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.  

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 do usuário de 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.

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.

A restauração do NuGet e as tarefas de build do comando NuGet

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

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

Melhorias de build e versão

Novo editor de definição de build

Reformulamos o editor de definição de build para fornecer uma experiência mais intuitiva, corrigir alguns problemas difíceis e adicionar novas funcionalidades. Esperamos que você ache 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) .

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

Procure a tarefa que deseja usar e, 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) .

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.

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.

Várias versões das tarefas de Extensão

Os autores de extensão agora podem criar extensões com várias versões de uma tarefa específica, o que permite enviar patches para cada versão principal na produção.

Consulte Referência para criar tarefas de build personalizadas dentro de extensões.

Tarefas de build condicionais

Se você está buscando 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 uma tarefa em execução (Figura 46) .

Se você está buscando mais flexibilidade, como uma tarefa para executar apenas determinados branches, com determinados gatilhos, sob determinadas condições, expresse 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 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 foi expandida para dar 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 Por SSH agora dá suporte ao til (\~) no caminho de destino para simplificar a cópia de arquivos para o diretório raiz de um usuário remoto.   Além disso, uma nova opção causa a falha do build ou da versão quando não é encontrado nenhum arquivo 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. Esse recurso será melhorado futuramente para dar suporte a senhas 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.

Limpeza automática de workspace 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á workspaces deixados para trás pelas definições de build e versão excluídas.

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, agora ele indica o status da atualização 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.

Fila de pipelines

Agora nós mudamos do modelo de preço baseado em agente para o modelo de preços baseado em pipeline. Nesse novo modelo, os usuários podem executar muitos builds ou versões simultaneamente conforme o número de pipelines configurado na conta. Builds adicionais e versões posteriores a esse limite serão enfileiradas e aguardam a conclusão de builds e versões anteriores. O recurso de Fila de pipelines fornece aos usuários mais visibilidade sobre onde seus builds ou versões estão.

Ao iniciar a Fila de pipelines, você verá as seguintes informações:

1. Builds e versões aguardando um pipeline ser executado e sua posição na fila de espera. 2. Compilações e versões atualmente em execução usando pipelines disponíveis.

Enquanto seu build/versão está aguardando um pipeline, você também pode iniciar diretamente essa exibição de dentro da página de logs de build/versão e encontrar sua posição atual na fila de pipeline e outros detalhes.

Ação de versão no Resumo de build

Agora damos suporte a uma ação de Versão, disponível na barra de ações do resumo de Build, portanto, é fácil criar uma versão com base em um build.

Segurança para grupos de variáveis

A segurança para grupos de variáveis agora é controlada por meio de um conjunto de funções como Criador e Administrador.

Por padrão, as funções abaixo são atribuídas.

• Função de criador para Colaboradores
• Função de administrador para Administradores da coleção de projetos, Administradores de projeto, Administradores de build e Administradores de versão
• Função de leitor para os Usuários válidos do projeto

Os padrões podem ser substituídos para todos os grupos de variável ou para um específico.

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

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.

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

Um padrão comum usado para implantação é criar uma imagem completa da máquina 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. Agora, essa experiência foi melhorada para 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, confira a documentação dos Serviços de Armazenamento do Azure para habilitar o CORS.

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

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 têm os mesmos aprovadores) poderá ser feita de uma só vez, se você não desejar 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 ambiente de Teste for definida conforme mostrado abaixo, durante o tempo de implantação, ela será suficiente para que o userA e o userB aprovem apenas para o ambiente de Desenvolvimento. A implantação no Teste obterá a aprovação automática. Se a implantação no ambiente Teste for disparada manualmente, serão necessárias aprovações antes da implantação, para garantir as aprovações corretas.

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

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.

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.

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 é concluída 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, com base em suas necessidades – execução baseada em agente único, execução de teste distribuído baseada em vários agentes ou uma execução de várias configurações para executar testes em navegadores diferentes.

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. Confira a documentação para obter as diretrizes passo a passo de como configurar ambientes e executar testes automatizados por meio do hub de Teste.

Melhorias no Warehouse

Melhorias de desempenho no processamento de cubo do Analysis Services

Fizemos melhorias de desempenho na exibição vDimWorkItemTreeOverlay, que é usada para criar a dimensão Hierarquia de Árvore de Item de Trabalho com base nos links. Embora ele dependa de links System.LinkTypes.Hierarchy, observamos que a duração do processamento foi afetado por outros links também (por exemplo, System.LinkTypes.Related). Otimizamos a exibição para ignorar os tipos de link de adição que limitam a quantidade de dados lidos. Essa alteração diminui significativamente o tempo de processamento para determinados warehouses.

Reconciliação de esquema que não diferencia maiúsculas e minúsculas

O esquema do banco de dados do warehouse é criado mesclando campos de todos os bancos de dados da coleção anexados no processo de reconciliação de esquema. Anteriormente, todas as comparações diferenciavam maiúsculas de minúsculas e os administradores tinham que verificar se que havia uma correspondência exata nos nomes de referência do campo. Isso resultou em problemas em que houve diferenças sutis na capitalização. Com esta versão tornamos o processo mais tolerante a tais discrepâncias.

Melhorias 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 de pull.
• quando um usuário ou uma equipe é um revisor de uma solicitação de pull que é atualizada.
• quando outro usuário responde a um comentário da solicitação de 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 de 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 no nível 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:

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 podem adicionar assinantes da plataforma MSDN 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.

Integração do Microsoft Teams

Agora, as organizações que usam o Microsoft Teams para colaborar podem ver a atividade de seus projetos do TFS dentro dos canais da equipe. Isso permite que as equipes se mantenham informadas sobre alterações de item de trabalho relevantes, solicitações de pull, builds e versões e muito mais enquanto estão trabalhando no Microsoft Teams. Para obter mais informações, confira a documentação.

---

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

A versão do TFS é RC2, em vez da versão final

• Problema:

  Depois de baixar o TFS 2017 Atualização 2 antes de 1º de agosto de 2017 e instalá-lo, você tem uma versão RC2.

• Solução alternativa:

  Isso ocorreu devido a um problema intermitente nos links de instalação, corrigido em 1º de agosto de 2017. Baixe o TFS 2017 Atualização 2 novamente e instale esta versão final.

Consulte os problemas relatados pelos clientes para o Team Foundation Server 2017.

---

Comentários e Sugestões

Adoraríamos ouvir sua opinião! Relate um problema e acompanhe-o por meio da Comunidade de Desenvolvedores e receba consultoria no Stack Overflow.

---

Parte superior da página