Compartilhar via


Agentes Linux e macOS hospedados pela Microsoft em disponibilidade geral – Atualização do VSTS Sprint 137

Na Atualização Sprint 137 do Visual Studio Team Services (VSTS), removemos o apelido "Visualização" de nossos agentes de CI/CD hospedados pela Microsoft para Linux e macOS e os disponibilizamos para o público geral. Juntamente com nosso agente do Windows hospedado pela Microsoft, agora você tem uma plataforma confiável e escalonável para compilações e versões de produção, independentemente da sua plataforma.

Há vários outros recursos em Código, Wiki, Pacote e Administração. Confira a lista de recursos abaixo para saber mais.

Próximas etapas

Leia sobre os novos recursos abaixo e acesse o VSTS para experimentá-los por si mesmo.

O que há de novo no VSTS

Recursos

Código:

Wiki:

Compilar e lançar:

Pacote:

Administrador:

Código

Criar solicitações de pull sem uma equipe padrão como revisor

Importante

Para usar esse recurso, você deve ter o recurso de visualização Nova navegação habilitado em seu perfil ou organização.

Quando lançamos a experiência de PR (solicitação de pull) pela primeira vez, achamos que faria sentido atribuir todas as PRs ao contexto de equipe que você selecionou ao criar a PR. Esse comportamento tem sido um ponto de frustração, já que muitas pessoas não perceberam a conexão entre o contexto da equipe e a atribuição de RP. Na verdade, essa tem sido uma das nossas principais sugestões do UserVoice.

Como parte das novas alterações de navegação, aproveitamos a oportunidade para alterar essa associação padrão com as equipes. Você notará duas alterações:

  1. Ao criar uma PR, nenhum revisor é adicionado por padrão. A lista de revisores tem um recurso para facilitar a adição de indivíduos e grupos que foram adicionados aos PRs recentemente. A política de revisores necessários também pode ajudar as equipes que desejam garantir que revisores específicos sejam adicionados para revisar seu código.
  2. O hub de Solicitações de Pull tem uma nova seção personalizável. Por padrão, esta seção mostra PRs "Atribuídos às minhas equipes", fornecendo funcionalidade equivalente à seção antiga. No entanto, se você pertencer a várias equipes, esta seção mostrará PRs atribuídas a qualquer uma de suas equipes. A seção também é personalizável - basta clicar na ação "Personalizar esta visualização" perto do cabeçalho da seção.

Permitir ignorar políticas de branch sem abrir mão da proteção por push

Há muitos cenários em que você tem a necessidade ocasional de ignorar uma política de branch - revertendo uma alteração que causou uma quebra de build, aplicando um hotfix no meio da noite, etc. Anteriormente, oferecíamos uma permissão ("Isento da imposição de política") para ajudar as equipes a gerenciar quais usuários receberam a capacidade de ignorar políticas de branch ao concluir uma solicitação de pull. No entanto, essa permissão também concedeu a capacidade de enviar diretamente para a filial, ignorando totalmente o processo de PR.

Para melhorar essa experiência, dividimos a permissão antiga para oferecer mais controle às equipes que estão concedendo permissões de desvio. Há duas novas permissões para substituir a antiga:

  1. Ignorar políticas ao concluir solicitações de pull. Os usuários com essa permissão poderão usar a experiência de "Substituição" nas solicitações de pull.
  2. Ignorar políticas ao enviar por push. Os usuários com essa permissão poderão enviar por push diretamente para branches que tenham políticas necessárias configuradas.

Ao conceder a primeira permissão e negar a segunda, um usuário poderá usar a opção bypass quando necessário, mas ainda terá a proteção contra push acidental para uma ramificação com políticas.

Observação

Essa alteração não introduz nenhuma alteração de comportamento. Os usuários que anteriormente receberam Permitir "Isento de imposição de política" receberão Permitir ambas as novas permissões, para que possam substituir a conclusão em PRs e enviar diretamente para branches com políticas.

Consulte a documentação Definir permissões de branch para obter mais informações.

Wiki

Agora você pode clicar no ícone de link ao lado de qualquer cabeçalho de seção em uma página wiki para gerar um URL diretamente para essa seção. Você pode copiar esse URL e compartilhá-lo com os membros da equipe para vinculá-los diretamente a essa seção. Esse recurso foi priorizado com base em uma sugestão.

URL do cabeçalho da wiki

Todos os links em um wiki que não estão vinculados corretamente aparecerão em uma cor vermelha distinta e ícone de link quebrado, dando a você uma pista visual de todos os links quebrados em uma página wiki.

Links quebrados do Wiki

Anexar arquivos e imagens em pastas

Ao editar páginas wiki offline, pode ser mais fácil adicionar anexos de arquivo e imagens no mesmo diretório da página wiki. Agora, você pode adicionar um anexo ou uma imagem em qualquer pasta do wiki e vinculá-lo à sua página. Esse recurso foi priorizado com base em uma sugestão.

Imagem wiki na pasta git repo

Abrir página em nova guia

Agora você pode clicar com o botão direito do mouse em uma página wiki e abri-la em uma nova guia ou simplesmente pressionar CTRL + clique esquerdo em uma página wiki para abri-la em uma nova guia.

Nova guia Wiki

Build e lançamento

Compilar e lançar com agentes Linux e macOS hospedados pela Microsoft

Os agentes Linux e macOS hospedados pela Microsoft agora estão fora da versão prévia e em disponibilidade geral. Depois de vários meses em pré-visualização, ouvindo comentários e ajustando a infraestrutura para fornecer um serviço consistente, estamos entusiasmados em oferecê-los agora em GA. Consulte a documentação de agentes hospedados pela Microsoft para obter mais informações.

Importante

Devido à forma como os pools hospedados foram implementados na versão prévia, os pools de agentes em organizações existentes continuarão a ter o moniker "Preview" (somente no nome). Os pools marcados como "Preview" atingiram a disponibilidade geral e serão equivalentes aos pools correspondentes recém-nomeados que serão lançados em breve.

Implantar automaticamente em novos destinos em um grupo de implantação

Anteriormente, quando novos destinos eram adicionados a um grupo de implantação, uma implantação manual era necessária para garantir que todos os destinos tivessem a mesma versão. Agora você pode configurar o ambiente para implantar automaticamente a última versão bem-sucedida nos novos destinos. Planejamos adicionar eventos e ações de gatilho adicionais à configuração de reimplantação automática nos próximos sprints. Consulte a documentação dos Grupos de Implantação para obter mais informações.

Grupos de implantação

Manter implantações até que os portões sejam bem-sucedidos de forma consistente

Os portões de liberação permitem a avaliação automática dos critérios de integridade antes que uma versão seja promovida para o próximo ambiente. Por padrão, a versão progride depois que uma amostra bem-sucedida para todos os portões é recebida. Mesmo que uma porta seja errática e a amostra bem-sucedida recebida seja ruído, a liberação progride. Para evitar esses tipos de problemas, agora você pode configurar a versão para verificar a consistência da integridade por um período mínimo antes de progredir. Em tempo de execução, a versão garantiria que avaliações consecutivas dos portões fossem bem-sucedidas antes de permitir a promoção. O tempo total para avaliação depende do "tempo entre a reavaliação" e normalmente seria maior do que a duração mínima configurada. Consulte a documentação Controle de implantação de versão usando portões para obter mais informações.

Configuração de retenção de portões

Azure DevOps Projects já está em disponibilidade geral

Em novembro, apresentamos o DevOps Projects, que ajuda você a começar a trabalhar com um pipeline completo de DevOps no Azure, desde o código até o monitoramento, em apenas alguns minutos. Adicionamos serviços ao longo do caminho e incorporamos muitos de seus comentários. Agora continuaremos avançando com ele em disponibilidade geral para ajudá-lo a ir ainda mais longe em sua jornada com o DevOps. Consulte a postagem de disponibilidade geral do Azure DevOps Projects no Blog do Microsoft DevOps para obter mais informações.

Pacote

Introdução ao Gerenciamento de Pacotes pré-instalado

A extensão de Gerenciamento de Pacotes é pré-instalada em todas as organizações. Se você estiver usando a nova visualização de navegação, procure-a na parte inferior da lista de serviços. Se você ainda estiver na navegação atual, procure o hub Pacotes no grupo de hubs de build e versão. Cada organização vem com 5 usuários gratuitos do Gerenciamento de Pacotes e usuários adicionais podem ser adquiridos no Marketplace. Em breve, você também poderá alternar a visibilidade desse serviço em sua organização usando a página de administração de Serviços na nova navegação, como pode fazer com os outros.

Serviço de pacotes

Administração

Conectar ou desconectar o Azure Active Directory como administrador de coleção de projetos

Um PCA (Administrador de Coleção de Projetos) agora pode conectar ou desconectar sua organização do Azure Active Directory. Anteriormente, isso tinha que ser feito por um proprietário da organização.

Projetos públicos disponíveis em versão prévia para todas as organizações

Importante

Para usar esse recurso, um administrador da organização deve habilitar projetos públicos na página Configurações .

Como anunciamos em abril, estamos trazendo projetos públicos para o VSTS. Pela primeira vez, você poderá marcar um projeto de equipe do VSTS como público. Isso permitirá que usuários anônimos (não autenticados) possam exibir o conteúdo desse projeto, incluindo itens de trabalho, código e resultados de build. Embora o recurso ainda esteja em versão prévia, a partir desse sprint, você não precisará mais ser convidado para ingressar na visualização privada.

Importante

Se você estiver usando um projeto público para criar um repositório hospedado no GitHub, observe que, embora as PRs (pull requests) de branches dentro do seu repositório sejam compiladas corretamente, as PRs abertas a partir de bifurcações do seu repositório não serão compiladas no momento.

Adote a palavra "organização" ao se referir a uma coleção de projetos no VSTS

Fizemos uma alteração em nossa terminologia quando se trata de nos referirmos a uma coleção de projetos no VSTS. Anteriormente, usamos o termo "conta", mas descobrimos que isso causou muita confusão para a comunidade de desenvolvedores e código aberto em geral. Optamos por substituir o termo "conta" por "organização". Você começará a ver essa mudança na documentação e no produto com esta atualização. Consulte a postagem Adotando a palavra "organização" no Blog do Microsoft DevOps para obter mais informações.

Como fornecer comentários

Adoraríamos ouvir o que você pensa sobre esses recursos. Use o menu de comentários para relatar um problema ou fornecer uma sugestão.

Menu de feedback

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

Obrigada,

Biju Venugopal