Compartilhar via


Gerenciar a cobrança da organização no Azure DevOps – Atualização do Sprint 150

Na atualização sprint 150 do Azure DevOps, adicionamos a capacidade de gerenciar a cobrança para sua organização em nosso portal.

Na nova guia de cobrança, você pode escolher a assinatura do Azure usada para cobrança e pagar por usuários adicionais. Você não precisa mais acessar o Visual Studio Marketplace ou o portal do Azure para gerenciar a cobrança.

Confira a lista de recursos abaixo para obter mais informações.

Características

Geral:

Quadros do Azure:

Azure Repos:

Azure Pipelines:

Emissão de relatórios:

Wiki:

Administração:

Geral

Disponibilidade geral do tema escuro

Em outubro passado, lançamos a prévia pública do tema escuro como parte da nova navegação. Após vários meses em versão prévia, ouvindo comentários e ajustando a experiência, estamos empolgados em anunciar a disponibilidade geral do tema escuro.

Gerenciar a cobrança para sua organização do Azure DevOps

Estamos felizes em anunciar que agora você pode gerenciar a cobrança da sua organização no portal do Azure DevOps. Os administradores não precisam mais configurar a cobrança por meio do portal do Azure. Para gerenciar as configurações de cobrança, acesse as Configurações da Organização e selecione Cobrança.

Abaixo está uma lista de configurações que você pode gerenciar na guia Cobrança.

  1. Você pode escolher uma assinatura do Azure a ser usada para cobrança.

    Cobrança de configurações da organização.

  2. Você pode alterar a assinatura do Azure que sua organização usa para cobrança selecionando uma assinatura diferente. Anteriormente, era necessário remover a cobrança e, em seguida, comprar novamente, com cuidado, o mesmo nível para cada um dos seus recursos pagos (usuários básicos, usuários do Gerenciamento de Pacotes, pipelines hospedados pelo MS, etc.). Esse processo era tedioso e propenso a erros. Agora você pode alterar a assinatura do Azure que sua organização usa para cobrança selecionando uma assinatura diferente e clicando em salvar.

    ID da assinatura de cobrança do Azure

  3. Não é mais necessário ir ao Visual Studio Marketplace para gerenciar a configuração de cobrança. Adicionamos a capacidade de pagar por usuários adicionais do Basic, Test Manager e Gerenciamento de Pacotes (Azure Artifacts). Você pode aumentar ou diminuir a contagem de usuários pelos quais sua organização está pagando a partir da nova guia Cobrança.

    Cobrança de pagamento para usuários adicionais.

Quadros do Azure

Trabalho de consulta baseado em grupos do Azure Active Directory

Com o aumento da adoção do Azure Active Directory e a prevalência do uso de grupos para gerenciar a segurança, as equipes têm buscado cada vez mais maneiras de aproveitar esses grupos no Azure Boards. Agora, além de consultar itens de trabalho que foram atribuídos ou alterados por pessoas específicas usando os operadores In Group ou Not In Group , você também pode usar grupos do Azure Active Directory diretamente.

Consulte a documentação dos operadores de consulta para obter mais informações.

Consultar o trabalho com base em grupos.

Compartilhe o quadro da sua equipe usando uma notificação

O README do repositório geralmente é a casa em que sua equipe de projeto recorre para obter informações sobre como contribuir e usar sua solução. Agora, como é possível fazer com um status de build ou implantação no Azure Pipelines, você pode adicionar ao seu README uma notificação para o quadro da sua equipe no Azure Boards. Você pode configurar o badge para mostrar apenas as colunas Em Progresso ou todas as colunas, e até mesmo tornar o badge visível publicamente se o projeto for open source.

Use um emblema para compartilhar quadros.

Se o README for baseado no Markdown, você poderá simplesmente copiar o markdown de exemplo da página de configurações de selo de status e cole-o no arquivo.

Notificação em um README no GitHub.

Consulta para o trabalho em relação ao início do dia, semana, mês ou ano

Embora as equipes muitas vezes se concentrem no trabalho dentro do contexto do que está por vir ou com base em iterações de sprint, muitas vezes é interessante olhar para trás no trabalho através das lentes do calendário para relatar todo o trabalho que aconteceu no mês passado ou no primeiro trimestre do ano. Agora você pode usar o novo conjunto de macros de @StartOf, junto a qualquer campo baseado em data para consultar com base no início do dia, semana, mês ou ano.

  • @StartOfYear
  • @StartOfMonth
  • @StartOfWeek
  • @StartOfDay

Cada uma dessas macros também aceita uma nova cadeia de caracteres modificadora que permite deslocar os dados por unidades de data diferentes. Por exemplo, você pode escrever uma consulta para localizar todos os itens de trabalho concluídos no primeiro trimestre deste ano, fazendo a consulta em Data de Alteração de Estado >= @StartOfYear e Data de Alteração de Estado <= @StartOfYear(“+3M”). Consulte a documentação de macros de consulta para obter mais informações.

Consulte o trabalho relativo ao início do dia, semana, mês ou ano.

Exportar resultados de consulta para um arquivo CSV

Agora você pode exportar os resultados da consulta diretamente para um arquivo de formato CSV da Web.

Exportar resultados da consulta.

Azure Repos

Novos tipos de mesclagem para concluir solicitações de pull

Agora você tem mais opções ao mesclar as alterações de um pull request no branch de destino. Adicionamos suporte para dois dos nossos recursos mais solicitados na Comunidade de Desenvolvedores: mesclagemFast-Forward e mesclagemSemi-Linear (também chamada de "Rebase and Merge").

Agora você verá essas novas opções disponíveis na caixa de diálogo Solicitação de Pull Completa:

Novos tipos de mesclagem para concluir solicitações de pull.

A página atualizada de administração de políticas permite que os administradores controlem quais estratégias de mesclagem são permitidas em um ramo ou em uma pasta de ramos.

Limite os tipos de mesclagem.

Observação

As políticas existentes ainda são impostas. Por exemplo, se sua branch tiver atualmente uma política de "somente mesclagem combinação por squash", você terá que editar essa política para usar as novas estratégias de mesclagem.

Há algumas situações em que não é possível fazer o rebase durante a conclusão da solicitação de pull:

  • Se uma política no branch de destino proibir o uso de estratégias de rebase, você precisará da permissão "Substituir políticas do branch".
  • Se o branch de origem do pull request tiver políticas, você não poderá fazer rebase nele. O rebase modificará o branch de origem sem passar pelo processo de aprovação da política.
  • Se você usou a Extensão de Conflito de Mesclagem para resolver conflitos de mesclagem. As resoluções de conflito aplicadas a uma mesclagem de três vias raramente são bem-sucedidas (ou mesmo válidas) ao fazer o rebase de todos os commits em uma solicitação de pull, um de cada vez.

Em todos esses casos, você ainda tem a opção de fazer o rebase do branch localmente e fazer o push para o servidor, ou fazer a mesclagem das alterações ao concluir a solicitação de pull.

Azure Pipelines (Pipelines de Distribuição do Azure)

Tarefa de manifesto do Kubernetes

Adicionamos uma nova tarefa aos nossos pipelines de lançamento para simplificar o processo de implantação em clusters do Kubernetes usando arquivos de manifesto. Essa tarefa fornecerá os seguintes benefícios em comparação com o uso do binário kubectl em scripts:

  • Substituição de artefato: a ação de implantação recebe como entrada uma lista de imagens de contêineres que podem ser especificadas juntamente com suas marcações ou resumos. Isso é substituído na versão sem modelo dos arquivos de manifesto antes de aplicá-lo ao cluster para garantir que a versão correta da imagem seja obtida pelos nós do cluster.

  • Estabilidade do manifesto: o status de lançamento é verificado para os objetos do Kubernetes implantados para incorporar verificações de estabilidade ao calcular o status da tarefa como sucesso/falha.

  • Anotações de rastreabilidade – anotações são adicionadas aos objetos do Kubernetes implantados para sobrepor informações de rastreabilidade sobre a organização, o projeto, o pipeline e a execução de origem.

  • Preparar manifesto: a ação de preparação da tarefa permite preparar os gráficos Helm em arquivos de manifesto do Kubernetes para que possam ser aplicados ao cluster.

  • Estratégia de implantação: escolher a estratégia canário com a ação de implantação leva à criação do percentual desejado de workloads sufixados com -baseline e -canary para que possam ser comparados durante uma tarefa ManualIntervention antes de utilizar a ação promover/rejeitar da tarefa para finalizar a versão a ser retida.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

Atualizações para a tarefa do Docker

Atualizamos a tarefa do Docker para simplificar a experiência de criação de pipeline. O comando buildAndPush agora pode ser usado para criar várias tags para um repositório específico de contêiner e enviá-lo para vários registries de contêiner em uma única etapa. A tarefa pode usar conexões de serviço do registro Docker para realizar login em registros de contêiner. Os metadados de rastreabilidade sobre o repositório de origem, o commit e a proveniência do build são adicionados como rótulos às imagens criadas com essa tarefa.

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Instalador de ferramentas do Kubectl

Adicionamos uma nova tarefa que permite instalar uma versão específica do binário kubectl nos agentes. As mais recentes e semver cadeias de caracteres de versão, como 'v1.14.0', são aceitas como valores válidos para a entrada de Especificação de Versão do Kubectl.

instalador de ferramenta kubectl.

Registro de contêiner do Azure na conexão do serviço de registro do Docker

Agora você pode criar uma conexão de serviço do Registro do Docker na página de configurações do projeto. Para criar a conexão, escolha um registro de contêiner do Azure em uma das assinaturas associadas à identidade do Azure AD (Azure Active Directory). Todas as tarefas que exigem conexões de serviço com registros de contêiner, como Docker@2 e KubernetesManifest@0, darão suporte a uma única maneira de especificar uma conexão.

Adicione uma conexão de serviço do Docker.

Suporte para cgroup no pool hospedado do Ubuntu

No Linux, quando o uso de memória ficar muito alto, o kernel encerrará alguns processos para proteger o restante. Se o processo do agente do Azure Pipelines for selecionado para encerramento, a execução do pipeline falhará com uma mensagem de erro sobre a perda de comunicação com o agente. No pool do Ubuntu hospedado pela Microsoft, reduzimos as chances de que o agente seja encerrado executando etapas dentro de um cgroup personalizado. Embora o pipeline ainda possa falhar se você exceder a memória disponível, é mais provável que o processo do agente sobreviva e informe a falha corretamente. Se você executar um agente privado do Linux, publicamos as configurações que usamos para que você possa considerar uma configuração semelhante.

Executar uma vez o agente

Se estiver usando uma infraestrutura como Instâncias de Contêiner do Azure para executar agentes privados elásticos, muitas vezes você quer que cada agente aceite apenas um trabalho antes de ir embora. Até agora, isso não era fácil, pois você tinha que encerrar o agente (possivelmente resultando em uma falha a ser relatada) ou aceitar o risco de que um agente pudesse receber outro trabalho antes que você pudesse encerrá-lo. Com essa atualização, adicionamos o sinalizador --once à configuração do agente. Quando você configurar o agente dessa forma, ele aceitará apenas um trabalho e, em seguida, desligará a si mesmo.

Suporte para o Visual Studio 2019 (VS2019) na tarefa de Teste do Visual Studio

Adicionamos suporte para o VS2019 à tarefa de teste do Visual Studio nas pipelines. Para executar testes usando a plataforma de teste para VS2019, selecione as opções Mais recente ou Visual Studio 2019 na lista suspensa de versão da plataforma de teste.

Suporte para o Visual Studio 2019 (VS2019) na tarefa Teste do Visual Studio.

Atualização da interface de usuário para o pool de agentes

A página de gerenciamento de pools de agente nas configurações do projeto foi atualizada com uma nova interface do usuário. Agora você pode ver facilmente todos os trabalhos que estão sendo executados em um pool. Além disso, você pode saber por que um trabalho não está em execução.

Atualização da experiência do usuário (UX) do pool de agentes.

Assistente de tarefa para edição de arquivos YAML

Continuamos recebendo muitos comentários pedindo para facilitar a edição de arquivos YAML para pipelines. Nas atualizações anteriores, adicionamos suporte ao intellisense. Agora estamos adicionando um assistente de tarefa ao editor yaml. Com isso, você terá a mesma experiência familiar para adicionar uma nova tarefa a um arquivo YAML como no editor clássico. Esse novo assistente dá suporte à maioria dos tipos comuns de entrada de tarefa, como listas de seleção e conexões de serviço. Para usar o novo assistente de tarefa, selecione Editar em um pipeline baseado em YAML e, em seguida, selecione o assistente de tarefa .

Assistente de tarefa para edição de arquivos YAML.

Atualizações de imagem de pipelines hospedados

Estamos empolgados em anunciar atualizações para o pool de macOS hospedado para o OS X Mojave (10.4), que também incluirá suporte para o Xcode 10.2. Se seus pipelines baseados em designer estiverem usando o pool macOS hospedado, seus pipelines serão atualizados automaticamente para o Mojave. Se você quiser permanecer no OS X High Sierra (10.3), altere o pool em que seus builds são executados no MacOS High Sierra hospedado.

Se você estiver usando YAML, os novos rótulos vmImage que você pode usar serão os seguintes:

  • Rótulo de imagem que sempre apontará para a versão mais recente do macOS, atualmente 10.4
vmImage: 'macOS-latest'
  • Esse rótulo de imagem destina-se especificamente ao mac OS 10.4 se você quiser ter certeza de que seu pipeline é executado no Mojave
vmImage: 'macOS-10.4'
  • Rótulo de imagem que será direcionado especificamente para o Mac OS 10.3 se você quiser ter certeza de que seu pipeline será executado no High Sierra
vmImage: 'macOS-10.3'

Também fizemos atualizações na imagem do Windows Server 2019 para seus Azure Pipelines hospedados. As versões mais recentes podem ser encontradas aqui. Essa atualização inclui novas versões do VS2019 Preview, Docker, PowerShell Core, Node.js, npm e outros.

Para obter mais detalhes sobre o que está contido em nossas imagens de VM do macOS hospedadas e saiba mais sobre as ferramentas disponíveis em nossas imagens, visite nosso repositório de Geração de Imagens no GitHub.

Melhorias na integração do ServiceNow

Em dezembro passado, lançamos a integração do ServiceNow Change Management com pipelines de lançamento. Uma funcionalidade fundamental para a colaboração entre equipes que permitiu que cada equipe usizasse um serviço de sua escolha e tivesse uma entrega de ponta a ponta efetiva. Com essa atualização, aprimoramos a integração para dar suporte a todos os tipos de alterações (normal, padrão e emergência). Além disso, agora você pode especificar a porta usada para criar uma nova solicitação de alteração usando um modelo existente, de acordo com o processo ITSM seguido em sua organização. Por fim, você também pode bloquear lançamentos com base em solicitações de alteração existentes. Isso permite que você adote o CD, sem a necessidade de alterar o processo recomendado por suas equipes de TI.

Gerenciamento de alterações do ServiceNow.

Suporte para o módulo Az do Azure PowerShell

O Azure PowerShell fornece um conjunto de cmdlets que você pode usar para gerenciar recursos do Azure da linha de comando. No último mês de dezembro, o módulo Azure PowerShell Az ficou disponível e agora é o módulo pretendido para gerenciar seus recursos do Azure.

Anteriormente, não fornecemos suporte para o módulo Az do Azure PowerShell em nossos agentes hospedados. Com a nova versão 4.* da tarefa do Azure PowerShell nos pipelines de build e lançamento, adicionamos suporte ao novo módulo Az para todas as plataformas. A versão 3.* da tarefa do Azure PowerShell continuará a dar suporte ao módulo AzureRM. No entanto, para acompanhar os serviços e recursos mais recentes do Azure, recomendamos que você alterne para a tarefa do Azure PowerShell versão 4.* o mais rápido possível.

O módulo Az tem um modo de compatibilidade para ajudá-lo a usar scripts existentes enquanto você os atualiza para usar a nova sintaxe. Para habilitar a compatibilidade para o módulo Az, use o comando Enable-AzureRmAlias. Os aliases permitem que você use os nomes de cmdlet antigos com o módulo Az. Você pode obter mais detalhes sobre como migrar do módulo Azure RM para o módulo Azure PowerShell Az aqui .

Observação

Você precisará instalar o módulo Az no computador do agente se estiver usando agentes privados.

Para obter mais informações sobre o módulo Az do PowerShell do Azure, consulte a documentação aqui.

Aprimoramentos de autorização de recursos

Precisávamos fornecer segurança para recursos protegidos (por exemplo, conexões de serviço, grupos de variáveis, pools de agentes, arquivos seguros) quando referenciados em um arquivo YAML. Ao mesmo tempo, queríamos facilitar a configuração e o uso de pipelines que usam esses tipos de recursos para cenários de não produção. Anteriormente, adicionamos uma configuração para marcar um recurso como "autorizado para uso em todos os pipelines".

Com essa atualização, estamos facilitando a correção de um problema de autorização de recurso, mesmo que você não tenha marcado um recurso como tal. Na nova experiência, quando um build falhar devido a um erro de autorização de recurso, você verá uma opção para autorizar explicitamente o uso desses recursos no pipeline e, em seguida, continuar. Os membros da equipe com permissões para autorizar recursos poderão concluir essa ação diretamente de um build com falha.

Resumo do pipeline com erro de autorização.

Políticas de retenção simplificadas para os pipelines de build

Simplificamos o modelo de retenção para todos os pipelines de build, incluindo aqueles configurados com YAML. Há uma nova configuração no nível do projeto que permite controlar quantos dias você deseja reter as compilações de cada pipeline e quantos dias você deseja reter os artefatos de cada compilação. Se você usou o editor clássico para criar o pipeline de build, as configurações de retenção mais antigas continuarão a ser respeitadas, mas pipelines mais recentes usarão as novas configurações. Você pode gerenciar a retenção nas configurações de pipelines página de configurações do projeto.

Artefatos de pipeline obtidos automaticamente no lançamento

Anteriormente, se o pipeline de build vinculado a um lançamento tivesse publicado artefatos usando a tarefa Publicar Artefato do Pipeline, os artefatos não eram buscados automaticamente no lançamento. Em vez disso, você tinha que adicionar explicitamente uma tarefa Baixar Artefato de Pipeline no pipeline de lançamento para baixar o artefato.

Agora, todos os artefatos do pipeline publicados pelo pipeline de build são automaticamente baixados e disponibilizados para você no lançamento. Você também pode personalizar o download do artefato do pipeline a partir das propriedades de fase do pipeline de lançamento.

Atualizações do relatório de cobertura de código da Cobertura

Anteriormente, quando você executava testes em pipeline e publicava resultados de cobertura de código no Azure DevOps, era necessário especificar o resumo XML e um arquivo de relatório HTML. Além disso, os estilos nos relatórios HTML foram removidos antes de serem renderizados na guia cobertura de código. Essa remoção do estilo foi necessária do ponto de vista de segurança, pois arquivos HTML arbitrários poderiam ser carregados.

Com essa atualização, abordamos essas limitações para relatórios de cobertura do Cobertura. Ao publicar relatórios de cobertura de código, você não precisa mais especificar arquivos HTML. Os relatórios são gerados automaticamente e são renderizados com o estilo apropriado na guia cobertura de código. Essa funcionalidade usa a ferramenta de software livre ReportGenerator.

Cobertura de código.

Reportagem

Relatórios de falha e duração do build

É importante ter métricas e insights para melhorar continuamente a taxa de transferência e a estabilidade do pipeline. Como a primeira etapa para fornecer análise de pipeline, adicionamos dois relatórios para fornecer métricas e insights sobre seus pipelines.

  1. O relatório de falha mostrará a taxa de sucesso da build e a tendência de falha. Além disso, ele também mostrará a tendência de falha de tarefas para fornecer insights sobre qual tarefa está contribuindo para o número máximo de falhas.

    Relatórios de falha e duração do build.

  2. O relatório de duração terá a duração do pipeline junto com sua tendência.

    Tendência do relatório de duração do pipeline.

Disponibilidade geral do Analytics

Estamos entusiasmados em anunciar que os seguintes recursos de Análise serão incluídos no Azure DevOps sem nenhum custo adicional.

  1. Os Widgets de Análise são módulos configuráveis que exibem dados em um painel e ajudam a monitorar o progresso do seu trabalho. Os widgets incluídos são os seguintes:

  2. No produto, estamos incluindo o relatório dos principais testes com falhas para obter insights sobre os principais falhas no seu pipeline, ajudando a melhorar a confiabilidade do pipeline e reduzir a dívida técnica.

    Relatório de falha de teste.

Também continuaremos a oferecer integração do Power BI por meio de exibições de análise e acesso direto ao nosso ponto de extremidade OData em versão prévia para todos os clientes do Azure DevOps Services.

Se você estiver usando a extensão do marketplace de Análise, poderá continuar a usar o Analytics como fez antes e não precisará seguir nenhuma etapa adicional. Isso significa que vamos descontinuar a extensão do marketplace Analytics para clientes hospedados.

A oferta do Azure DevOps Analytics é o futuro dos relatórios e continuaremos investindo em novos recursos orientados pelo Analytics. Você pode encontrar mais informações sobre Análise nos links abaixo.

Wiki

Notificações em páginas wiki

Até agora, você não tinha uma maneira de saber quando o conteúdo em uma página wiki foi alterado. Agora você pode seguir páginas wiki para ser notificado por email quando a página é editada, excluída ou renomeada. Para acompanhar as alterações feitas em um wiki, selecione o botão Seguir na página do wiki.

Página wiki.

Esse recurso foi priorizado com base nesse tíquete de sugestão Para saber mais, confira nossa documentação aqui.

Administração

Gerenciar a cobrança para sua organização do Azure DevOps

Estamos felizes em anunciar que agora você pode gerenciar a cobrança da sua organização no portal do Azure DevOps. Os administradores não precisam mais configurar a cobrança por meio do portal do Azure. Para gerenciar as configurações de cobrança, acesse as Configurações da Organização e selecione Cobrança.

Veja abaixo uma lista de configurações que você pode gerenciar a partir da guia Cobrança.

  1. Você pode escolher uma assinatura do Azure a ser usada para cobrança.

    Configurações de cobrança da organização.

  2. Você pode alterar a assinatura do Azure que sua organização usa para cobrança selecionando uma assinatura diferente. Anteriormente, era necessário remover a cobrança e, em seguida, comprar novamente, com cuidado, o mesmo nível para cada um dos seus recursos pagos (usuários básicos, usuários do Gerenciamento de Pacotes, pipelines hospedados pelo MS, etc.). Esse processo era tedioso e propenso a erros. Agora você pode alterar a assinatura do Azure que sua organização usa para cobrança selecionando uma assinatura diferente e clicando em salvar.

    ID da assinatura de cobrança do Azure

  3. Não é mais necessário ir ao Visual Studio Marketplace para gerenciar a configuração de cobrança. Adicionamos a capacidade de pagar por usuários adicionais do Basic, Test Manager e Gerenciamento de Pacotes (Azure Artifacts). Você pode aumentar ou diminuir a contagem de usuários pelos quais sua organização está pagando a partir da nova guia Cobrança.

    Cobrança de pagamento para usuários adicionais.

Próximas etapas

Observação

Essas funcionalidades serão lançadas nas próximas duas a três semanas.

Vá até o Azure DevOps e dê uma olhada.

Como fornecer comentários

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

fazer uma sugestão

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

Obrigado

Jeremy Epling