Compartilhar via

Grupos de implantação e gatilho de conclusão de build – Atualização do VSTS Sprint 132

  • Artigo

A Atualização de Visual Studio Team Services (VSTS) do Sprint 132 traz alguns recursos importantes para ajudá-lo a dimensionar seu pipeline de build e lançamento. No Build, use o novo gatilho de conclusão de build para encadear builds relacionados que podem pertencer a equipes diferentes. Em Versão, anunciamos a disponibilidade geral dos Grupos de Implantação, que você pode usar para dimensionar implantações em várias máquinas virtuais com alta disponibilidade, incluindo ambientes de produção.

Outros destaques incluem:

Novidades no VSTS

Recursos

Código

Build e versão

Pacote

Wiki

Relatórios

Código

Descrever rapidamente as solicitações de pull usando mensagens de confirmação

Gravar mensagens de confirmação descritivas agrega valor ao histórico de qualquer repositório Git. Para incentivar mensagens de confirmação de qualidade, novas solicitações de pull (PR) que têm vários commits exigirão que os colaboradores insiram um título manualmente.

As descrições da solicitação de pull continuarão vazias por padrão, mas um novo recurso facilitará a incorporação das mensagens de confirmação das confirmações de PR na descrição da PR. Para adicionar as mensagens de confirmação, basta clicar em Adicionar mensagens de confirmação para acrescentar as mensagens de confirmação ao final do texto de descrição da PR.

Adicionar ação de mensagens de confirmação

Executar comandos TFVC diretamente do Windows Explorer

A Extensão do Shell do Windows TFVC, que oferece uma experiência de controle de versão leve integrada ao Windows Explorador de Arquivos, agora dá suporte ao VSTS e ao TFS 2018. Essa ferramenta fornece acesso conveniente a vários comandos TFVC diretamente no menu de contexto do Windows Explorer.

Anteriormente parte das ferramentas TFS Power, a ferramenta foi lançada como uma ferramenta autônoma no Visual Studio Marketplace.

Extensão do Shell

Build e versão

Produtos grandes têm vários componentes que dependem uns dos outros. Esses componentes geralmente são criados de forma independente. Quando um componente upstream (uma biblioteca, por exemplo) é alterado, as dependências downstream precisam ser recompiladas e revalidadas. Normalmente, as equipes gerenciam essas dependências manualmente.

Agora você pode disparar um build após a conclusão bem-sucedida de outro build. Artefatos produzidos por um build upstream podem ser baixados e usados no build posterior, e você também pode obter dados dessas variáveis: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Consulte a documentação de gatilhos de build para obter mais informações.

Esse recurso foi priorizado com base no que é atualmente a sugestão nº 2 mais votada, com 1.129 votos.

Configurar o encadeamento de build

Tenha em mente que, em alguns casos, uma única compilação de várias fases pode atender às suas necessidades. No entanto, um gatilho de conclusão de build será útil se seus requisitos incluírem diferentes definições de configuração, opções ou uma equipe diferente para possuir o processo dependente.

Dimensionar implantações para VMs usando Grupos de Implantação

Os Grupos de Implantação, que fornecem uma implantação robusta e pronta de várias máquinas, agora está disponível. Com os Grupos de Implantação, você pode orquestrar implantações em vários servidores e executar atualizações sem interrupção enquanto garante a alta disponibilidade do seu aplicativo completamente. Você também pode implantar servidores locais ou máquinas virtuais no Azure ou em qualquer nuvem, além de ter capacidade de acompanhamento de ponta a ponta de versões do artefato implantado até o nível de servidor.

A funcionalidade de implantação com base em agente depende dos mesmos agentes de build e implantação que já estão disponíveis. Você pode usar o catálogo de tarefas completo em seus computadores de destino na fase Grupo de implantação. De uma perspectiva de extensibilidade, você também pode usar as APIs REST para grupos de implantação e destinos para acesso programático.

Destinos de implantação compartilhada

Se você estiver usando o mesmo servidor para hospedar vários aplicativos, poderá compartilhar o servidor (também conhecido como destino de implantação) entre projetos de equipe usando pools de implantação.

Lista de destinos de Grupos de Implantação

Novos modelos

A implantação em vários destinos agora é uma novidade com os novos modelos de definição de versão. Vários modelos para o site do IIS, o site do IIS com banco de dados e vários modelos de implantação para o BD SQL estão disponíveis imediatamente.

Modelos de versão para grupos de implantação

Provisionando VMs

Use a tarefa aprimorada do Grupo de Recursos do Azure para inicializar dinamicamente agentes no Máquinas Virtuais recém-provisionado ou pré-existente no Azure.

Tarefa do Grupo de Recursos do Azure

Quando lançamos grupos de implantação em maio passado, enviamos uma interface de usuário simples direcionada a alguns cenários-chave. Agora você encontrará uma interface mais consistente que se parece com o restante do produto.

Consulte a documentação grupos de implantação para obter mais informações sobre como começar.

Criar aplicativos escritos em Go

Agora você pode criar seus aplicativos Go no VSTS!

Use a tarefa Go Tool Installer para instalar uma ou mais versões da Ferramenta Go em tempo real. Essa tarefa adquire uma versão específica da Ferramenta Go necessária para seu projeto e a adiciona ao PATH do agente de build. Se a versão da Ferramenta Go de destino já estiver instalada no agente, essa tarefa ignorará o processo de baixá-la e instalá-la novamente.

A tarefa Go ajuda você a baixar dependências, compilar ou testar seu aplicativo. Você também pode usar essa tarefa para executar um comando Go personalizado de sua escolha.

Estender portões de liberação com extensões de tarefa

Os portões de liberação trazem informações de sinais de integridade diretamente para o pipeline de lançamento. Um portão coleta um conjunto de sinais de integridade repetidamente, antes ou depois de uma implantação, para determinar se a versão deve prosseguir para o próximo estágio ou não. Um conjunto de portões internos é fornecido e a opção Invocar Função do Azure foi a recomendada para integrar outros serviços até o momento.

Agora, os portões podem vir na forma de uma extensão, o que facilita a integração de serviços novos ou personalizados para você ou autores de extensão e a configuração do portão.

Consulte a documentação de tarefas de porta de criação para obter mais informações.

Pacote

Usar upstream pacotes npm de outro lugar no VSTS

Continuamos investindo em fontes upstream, que permitem centralizar todas as dependências do pacote em um único feed e manter cópias salvas de todos os pacotes que você usa. Se você tiver vários feeds VSTS com pacotes npm, agora poderá adicionar um como uma fonte upstream do outro na mesma conta do VSTS. Como o npm limita principalmente você a um único feed/registro na configuração do projeto, upstream fontes oferecem a flexibilidade necessária para usar vários feeds npm, como um para cada equipe ou produto.

Também estamos trabalhando para habilitar upstream fontes para feeds do NuGet do VSTS em breve. Consulte a documentação upstream fontes para obter mais informações.

Lista de fontes upstream

Manter a velocidade de consulta do feed com políticas de retenção

Com o tempo, o número de versões de pacote pode ficar extenso, com versões mais antigas não utilizados. Para publicadores de pacote frequentes, isso poderia resultar em consultas de feed mais lentas no gerenciador de pacotes do NuGet e em outros clientes até que algumas versões fossem excluídas manualmente.

Agora você pode habilitar políticas de retenção em feeds. As políticas de retenção excluirão automaticamente a versão mais antiga de um pacote quando o limite de retenção for atingido. Pacotes promovidos a modos de exibição são mantidos por tempo indeterminado, fornecendo a capacidade de proteger as versões que são usadas na produção ou amplamente usadas em sua organização.

Para habilitar as políticas de retenção, edite seu feed e insira um valor em Número máximo de versões por pacote na seção Políticas de retenção.

configuração de políticas de retenção

Wiki

Publicar arquivos Markdown de um repositório Git como um Wiki

Os desenvolvedores criam documentação para "APIs", "SDKs" e "documentos de ajuda explicando o código" em repositórios de código. Em seguida, os leitores precisam examinar o código para encontrar a documentação certa. Agora você pode simplesmente publicar arquivos Markdown de repositórios de código e hospedá-los no Wiki.

código público como ação wiki

No Wiki, comece clicando em Publicar código como wiki. Em seguida, você pode especificar uma pasta em um repositório Git que deve ser promovido.

caixa de diálogo publicar páginas

Depois de clicar em Publicar, todos os arquivos Markdown na pasta selecionada serão publicados como um wiki. Isso também mapeará o cabeçalho do branch para o wiki para que as alterações feitas no repositório Git sejam refletidas imediatamente.

Caso você tenha várias versões do seu produto e queira navegar facilmente pela documentação dessas versões, também poderá publicar uma nova versão da documentação no wiki usando branches diferentes.

publicar nova ação de versão

Depois que os arquivos Markdown forem publicados, as páginas também poderão ser pesquisadas no hub de pesquisa wiki.

resultados da pesquisa para a CLI do Azure

Se você publicou o repositório errado, basta cancelar a publicação do wiki, o que deixa o repositório subjacente inalterado.

Você também pode alterar a ordenação das páginas do repositório ou até mesmo transformar uma pasta para parecer uma página wiki.

Confira a postagem no blog da documentação do produto para obter mais informações. Esse recurso foi priorizado com base em uma sugestão.

Reter caracteres especiais em títulos de página wiki

Agora você pode criar páginas wiki com caracteres especiais, como : < > * ? | -. Agora, páginas com títulos como "Perguntas frequentes?" ou "Guia de configuração" podem ser criadas no Wiki. Os seguintes caracteres são traduzidos para suas cadeias de caracteres codificadas em UTF-8:

Caractere Cadeia de caracteres codificada
: %3A
< %3C
> %3E
* %2A
? %3F
| %7C
- %2D

Esse recurso foi priorizado com base em uma sugestão.

Estender o Wiki usando APIs REST

As APIs REST do Wiki agora são públicas. Confira a documentação Funções wiki e pesquisa wiki para obter mais informações.

Relatórios

Integrar o Power BI à Análise do VSTS usando exibições

As Exibições de Análise funcionam com nosso Conector de Dados do Power BI do VSTS. Juntos, eles oferecem uma maneira fácil de obter seus dados do VSTS no Power BI para que você possa começar a criar relatórios personalizados.

Quando você instala a extensão de Análise do VSTS , criamos um conjunto de Exibições de Análise padrão que você pode começar a usar no Power BI. Agora você pode editar seus modos de exibição padrão e criar novos modos de exibição para ajustar os registros, os campos e o histórico retornados ao Power BI.

Próximas etapas e Comentários

Ir para o VSTS

Inscrever-se no Atualizações

Adoraríamos ouvir o que você pensa sobre esses recursos. Relate um problema ou forneça uma sugestão se você tiver ideias sobre coisas que gostaria de nos ver priorizando, por meio do menu de comentários.

Menu comentários

Você também pode obter conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.

Obrigada,

Gopinath Chigakkagari