Partilhar via

Faturamento baseado em atribuição de usuário, nível de acesso padrão e faturamento diário - Atualização do Sprint 158

  • Artigo

Na Atualização do Sprint 158 do Azure DevOps, adicionamos a cobrança baseada em atribuição de usuário. Com esta funcionalidade, o número de licenças Básico ou Básico + Plano de Teste será alterado à medida que adiciona ou remove utilizadores. Isso significa que você pagará apenas pelas licenças que estiver usando. Também adicionamos uma nova configuração que permite que você escolha se deseja que novos usuários sejam adicionados à sua organização para obter acesso Básico total ou acesso limitado/gratuito das Partes Interessadas.

Para além disso, mudámos da faturação mensal para a diária. Ou seja, se conceder a um utilizador acesso pago durante algumas semanas ou até alguns dias, paga apenas pelo tempo durante o qual foi atribuído ao utilizador o acesso pago em vez da totalidade do mês.

Confira a lista de recursos abaixo para saber mais.

O que há de novo no Azure DevOps

Funcionalidades

Geral:

Quadros do Azure:

Repositórios do Azure:

Azure Pipelines:

Planos de Teste do Azure:

Relatórios:

Wiki:

Geral

User assignment-based billing and default access level (Faturação baseada em atribuições de utilizadores e nível de acesso predefinido)

Faturação baseada na atribuição do utilizador

Com esta atualização, adicionámos a faturação baseada na atribuição de utilizadores. Em vez de ter que aumentar ou diminuir o número de licenças pagas Basic ou Basic + Test Plan que sua organização tem disponível para atribuir, agora isso acontece automaticamente quando você adiciona ou remove usuários, ou altera seu nível de acesso. Isso significa que você nunca está pagando por mais licenças do que está usando, e isso torna a automação de sua atribuição de nível de acesso muito mais fácil. Por exemplo, você conseguiu configurar regras de grupo para controlar qual nível de acesso é atribuído a novos usuários que ingressam na sua equipe automaticamente. No entanto, no passado, eles só funcionavam se você tivesse licenças extras pelas quais estava pagando e que ainda não foram atribuídas a ninguém e, se você acabasse, a regra de grupo falhava. Esses tipos de erros não acontecem mais, desde que a assinatura do Azure que você usa para cobrança permaneça ativa.

Nível de acesso padrão para novos usuários

Também adicionamos uma nova configuração que permite que você escolha se deseja que novos usuários sejam adicionados à sua organização para obter acesso Básico total ou acesso limitado/gratuito das Partes Interessadas. No passado, os novos usuários obtinham Basic se houvesse licenças Basic não atribuídas disponíveis, mas Stakeholder se não houvesse. Todas as organizações começarão com seu nível de acesso padrão definido como Stakeholder, portanto, não haverá cobranças inesperadas para novos usuários. Se sua organização normalmente mantinha licenças extras não atribuídas, para que novos usuários adicionados aos projetos obtivessem acesso Básico total, certifique-se de alterar seu nível de acesso padrão para Básico.

Default access level for new users.

Faturação diária

Como parte da mudança para o faturamento baseado em atribuição, também mudamos de faturamento mensal para diário. Agora, se você conceder a um usuário acesso pago por algumas semanas ou até mesmo alguns dias, pagará apenas pelo tempo em que lhe foi atribuído o acesso pago, em vez de um mês inteiro. À medida que mudamos sua organização de cobrança mensal para diária, sua próxima fatura do Azure provavelmente será menor do que era anteriormente. O próximo mês voltará ao normal assim que tiver um mês inteiro de cobranças diárias acumuladas.

New UI to manage organization and project permissions (Nova IU para gerir as permissões da organização e dos projetos)

O gerenciamento de permissões de organização e projeto tem uma nova aparência e o desempenho foi melhorado. Agora, novos membros do grupo aparecerão na lista à medida que forem adicionados sem exigir uma atualização forçada da página. Dirija-se às Configurações da sua organização e dê uma olhada.

Manage organization and project permissions.

Azure Boards

Suporte para campos personalizados em colunas de Rollup

O rollup agora pode ser feito em qualquer campo, incluindo campos personalizados. Ao adicionar uma coluna Rollup, você ainda pode escolher uma coluna Rollup na lista Rápida, no entanto, se quiser acumular em campos numéricos que não fazem parte do modelo de processo pronto para uso, você pode configurar o seu próprio da seguinte maneira:

  1. Na lista de pendências, clique em "Opções de coluna". Em seguida, no painel, clique em "Adicionar coluna Rollup" e Configure o pacote cumulativo personalizado.

    Rollup on custom fields.

  2. Escolha entre Barra de progresso e Total.
  3. Selecione um tipo de item de trabalho ou um nível de lista de pendências (geralmente as listas de pendências agregam vários tipos de item de trabalho).
  4. Selecione o tipo de agregação. Contagem de itens de trabalho ou Soma. Para Soma, você precisará selecionar o campo a ser resumido.
  5. O botão OK irá levá-lo de volta ao painel de opções de coluna, onde você pode reordenar sua nova coluna personalizada.

Support for custom fields in Rollup columns.

Observe que não é possível editar sua coluna personalizada depois de clicar em OK. Se você precisar fazer uma alteração, remova a coluna personalizada e adicione outra conforme desejado.

New rule to hide fields in a work item form based on condition (Nova regra para ocultar campos num formulário de item de trabalho com base em condições)

Adicionamos uma nova regra ao mecanismo de regras herdadas para permitir que você oculte campos em um formulário de item de trabalho. Esta regra ocultará campos com base na associação ao grupo de usuários. Por exemplo, se o usuário pertencer ao grupo "proprietário do produto", você poderá ocultar um campo específico do desenvolvedor. Para mais detalhes consulte a documentação aqui.

Custom work item notification settings (Definições personalizadas das notificações de item de trabalho)

Manter-se atualizado sobre itens de trabalho relevantes para você ou sua equipe é incrivelmente importante. Ajuda as equipas a colaborarem e a manterem-se no caminho certo com os projetos e garante que todas as partes certas estão envolvidas. No entanto, diferentes partes interessadas têm diferentes níveis de investimento em diferentes esforços, e acreditamos que isso deve ser refletido em sua capacidade de acompanhar o status de um item de trabalho.

Anteriormente, se você quisesse seguir um item de trabalho e receber notificações sobre quaisquer alterações feitas, receberia notificações por e-mail para todas e quaisquer alterações feitas no item de trabalho. Depois de considerar o seu feedback, estamos tornando o seguimento de um item de trabalho mais flexível para todas as partes interessadas. Agora, você verá um novo botão de configurações ao lado do botão Seguir no canto superior direito do item de trabalho. Isso levará você a um pop-up que permitirá que você configure suas opções de seguimento.

Configure follow options.

Em Configurações de notificação, você pode escolher entre três opções de notificação. Primeiro, você pode ser completamente cancelado. Em segundo lugar, você pode estar totalmente inscrito, onde você recebe notificações para todas as alterações de item de trabalho. Por fim, você pode optar por ser notificado sobre alguns dos principais e cruciais eventos de alteração de item de trabalho. Você pode selecionar apenas uma ou todas as três opções. Isso permitirá que os membros da equipe sigam os itens de trabalho em um nível mais alto e não se distraiam com cada alteração feita. Com este recurso, eliminaremos e-mails desnecessários e permitiremos que você se concentre nas tarefas cruciais em mãos.

Choose Notification Settings.

Estamos entusiasmados em lançar uma visualização do controle de implantação no formulário de item de trabalho. Esse controle vincula seus itens de trabalho a uma versão e permite que você rastreie facilmente onde seu item de trabalho foi implantado. Para saber mais, consulte a documentação aqui.

Link work items to deployments.

Repositórios do Azure

Use service account-based authentication to connect to AKS (Utilizar autenticação baseada em conta de serviço para ligar ao AKS)

Anteriormente, ao configurar o Azure Pipelines a partir do Centro de Implementação AKS, utilizávamos uma Ligação do Azure Resource Manager. Essa conexão tinha acesso a todo o cluster e não apenas ao namespace para o qual o pipeline foi configurado. Com essa atualização, nossos pipelines usarão a autenticação baseada em conta de serviço para se conectar ao cluster para que ele só tenha acesso ao namespace associado ao pipeline.

Visualizar arquivos Markdown na solicitação pull Comparação lado a lado

Agora você pode ver uma visualização de como um arquivo Markdown ficará usando o novo botão Visualizar . Além disso, você pode ver o conteúdo completo de um arquivo na comparação lado a lado selecionando o botão Exibir .

Preview Markdown files in pull request Side-by-side diff.

Build policy expiration for manual builds (Expiração da política de compilação para compilações manuais)

As políticas reforçam a qualidade do código e os padrões de gerenciamento de alterações da sua equipe. Anteriormente, você podia definir políticas de expiração de compilação para compilações automatizadas. Agora você também pode definir políticas de expiração de compilação para suas compilações manuais.

Build policy expiration for manual builds.

Add a policy to block commits based on the commit author email (Adicionar uma política a consolidações de blocos com base no e-mail do autor da consolidação)

Agora, os administradores podem definir uma política de push para evitar que confirmações sejam enviadas por push para um repositório para o qual o e-mail do autor da confirmação não corresponde ao padrão fornecido.

Add a policy to block commits based on the commit author email.

Esse recurso foi priorizado com base em uma sugestão da Comunidade de desenvolvedores para oferecer uma experiência semelhante. Continuaremos a manter o ticket aberto e incentivaremos os usuários a nos dizer quais outros tipos de políticas push você gostaria de ver.

Pipelines do Azure

Retry failed stages (Repetir etapas falhadas)

Nota

Para experimentar esse recurso, você deve ter o recurso de visualização Pipelines de vários estágios habilitado.

Um dos recursos mais solicitados em pipelines de vários estágios é a capacidade de tentar novamente um estágio com falha sem ter que começar do início. Com esta atualização, estamos adicionando uma grande parte dessa funcionalidade.

Agora você pode tentar novamente um estágio de pipeline quando a execução falhar. Todos os trabalhos que falharam na primeira tentativa e aqueles que dependem transitivamente desses trabalhos falhados são todos repetidos.

Isso pode ajudá-lo a economizar tempo de várias maneiras. Por exemplo, quando você executa vários trabalhos em um estágio, talvez queira que cada estágio execute testes em uma plataforma diferente. Se os testes em uma plataforma falharem enquanto outras passarem, você poderá economizar tempo não executando novamente os trabalhos aprovados. Como outro exemplo, um estágio de implantação pode ter falhado devido a uma conexão de rede escamosa. Repetir essa etapa irá ajudá-lo a economizar tempo, não tendo que produzir outra compilação.

Existem algumas lacunas conhecidas neste recurso. Por exemplo, não é possível repetir um estágio que você cancela explicitamente. Estamos a trabalhar para colmatar estas lacunas em futuras atualizações.

Enhancements to approvals in YAML pipelines (Melhorias das aprovações nos pipelines YAML)

Nota

Você deve ter pipelines de vários estágios e novos recursos de visualização da experiência de conexão de serviço habilitados para experimentar esse recurso.

Continuamos a melhorar os pipelines YAML de vários estágios. Com esta atualização, habilitamos a configuração de aprovações em conexões de serviço e pools de agentes. Para aprovações, seguimos a segregação de funções entre proprietários de infraestrutura e desenvolvedores. Ao configurar aprovações em seus recursos, como ambientes, conexões de serviço e pools de agentes, você terá certeza de que todas as execuções de pipeline que usam recursos exigirão aprovação primeiro.

A experiência é semelhante à configuração de aprovações para ambientes. Quando uma aprovação está pendente em um recurso referenciado em um estágio, a execução do pipeline aguarda até que o pipeline seja aprovado manualmente.

Enhancements to approvals in YAML pipelines.

Suporte a testes de estrutura de contêiner no Azure Pipelines

O uso de contêineres em aplicações está aumentando e, portanto, a necessidade de testes e validação robustos. O Azure Pipelines agora traz suporte para Testes de Estrutura de Contêiner. Essa estrutura fornece uma maneira conveniente e poderosa de verificar o conteúdo e a estrutura de seus contêineres.

Você pode validar a estrutura de uma imagem com base em quatro categorias de testes que podem ser executados juntos: testes de comando, testes de existência de arquivos, testes de conteúdo de arquivo e testes de metadados. Você pode usar os resultados no pipeline para tomar decisões de ir/não ir. Os dados de teste estão disponíveis na execução do pipeline com uma mensagem de erro para ajudá-lo a solucionar melhor as falhas.

Insira o arquivo de configuração e os detalhes da imagem

Container structure testing support in Azure Pipeline.

Dados e resumo dos ensaios

Test data and summary.

Flaky bug management and resolution (Gestão e resolução inconstante de erros)

Em julho, introduzimos o gerenciamento de testes escamosos para dar suporte ao ciclo de vida de ponta a ponta com deteção, emissão de relatórios e resolução. Para melhorá-lo ainda mais, estamos adicionando gerenciamento e resolução de bugs de teste escamosos.

Ao investigar o teste escamoso, você pode criar um bug usando a ação Bug, que pode ser atribuído a um desenvolvedor para investigar melhor a causa raiz do teste escamoso. O relatório de bug inclui informações sobre o pipeline, como mensagem de erro, rastreamento de pilha e outras informações associadas ao teste.

Quando um relatório de bug é resolvido ou fechado, desmarcaremos automaticamente o teste como não flaky.

Enhancements to Azure Pipelines app for Slack and Microsoft Teams (Melhorias da aplicação do Pipeline do Azure para o Slack e Microsoft Teams)

Pipelines baseados em YAML de vários estágios

Nota

Para experimentar esse recurso, você deve ter o recurso de visualização Pipelines de vários estágios habilitado.

O aplicativo Azure Pipelines para Slack e Microsoft Teams agora oferece suporte a pipelines YAML de vários estágios para CI e CD. Com esse aprimoramento, você será notificado sobre vários eventos relacionados aos pipelines YAML.

Enhancements to Azure Pipelines app for Slack and Microsoft Teams.

Eventos suportados para pipelines YAML de vários estágios

  • Estado de execução alterado
  • Estado do estágio de execução alterado
  • Etapa de execução aguardando aprovação
  • Aprovação do estágio de execução concluída

Events supported for multi-stage YAML pipelines.

Desfraldar URL e extensões de mensagens

Adicionámos uma extensão de mensagens para a aplicação Azure Pipelines para Microsoft Teams. Agora você pode pesquisar pipelines e compartilhar detalhes relevantes sobre o pipeline como um cartão no canal. O desfralde de URL ajuda você a iniciar discussões em torno de pipelines e ter conversas contextuais significativas.

URL unfurling and messaging extensions.

Updates to hosted pipelines images (Atualizações às imagens de pipelines alojados)

Atualizámos várias das imagens de VM alojadas no Azure Pipelines. A seguir estão alguns dos destaques nesta atualização:

  • Adicionado Go 1.13 para Ubuntu 16.04, Ubuntu 18.04, VS2017 e VS2019. Go 1.12 continua sendo o padrão.
  • Adicionado Android SDK e Build Tools 29 para Ubuntu 16.04, Ubuntu 18.04, VS2017 e VS2019.
  • Adicionado Az Module 2.6.0 ao VS2017 e VS2019.
  • Várias correções de bugs.

Você pode encontrar mais detalhes sobre os últimos lançamentos aqui.

Nota

Removeremos o Ruby 2.3 de todas as imagens em uma atualização futura, uma vez que chegou ao fim da vida útil em 31 de março de 2019.

Open Policy Agent installer task (Tarefa de instalação do Open Policy Agent)

O Open Policy Agent é um mecanismo de política de uso geral de código aberto que permite a aplicação de políticas unificadas e sensíveis ao contexto. Adicionámos a tarefa de instalação do Open Policy Agent. É particularmente útil para a aplicação de políticas in-pipeline em relação à infraestrutura como provedores de código.

Por exemplo, o Open Policy Agent pode avaliar os arquivos de política do Rego e os planos Terraform em pipeline.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Pipeline decorators for release pipelines (Decoradores de pipeline para pipelines de versão)

Os decoradores de pipeline permitem adicionar etapas ao início e ao fim de cada trabalho. Isso é diferente de adicionar etapas a uma única definição porque se aplica a todos os pipelines em uma organização.

Temos apoiado decoradores para construções e pipelines YAML, com os clientes usando-os para controlar centralmente as etapas em seus trabalhos. Estamos agora a alargar o apoio também à libertação de gasodutos. Você pode criar extensões para adicionar etapas direcionadas ao novo ponto de contribuição e elas serão adicionadas a todos os trabalhos do agente em pipelines de versão.

Planos de Teste do Azure

New Test Plans page (Nova página de Planos de Teste)

A maioria dos recursos de planejamento, criação, execução e acompanhamento agora estão disponíveis na nova página Planos de teste. Por isso, estamos habilitando para todos os usuários de Planos de Teste para que eles possam nos fornecer feedback. Os poucos recursos restantes necessários para atingirmos a paridade com a página Planos de teste anteriores serão habilitados nos próximos sprints. Se necessário, os usuários podem desativar a página Planos de teste no menu Visualizar recursos. Leia mais aqui.

Relatórios

Inline sprint burndown using story points (Relatório de evolução rápida inline com pontos de história)

Seu Sprint Burndown agora pode ser esgotado por Stories. Isso aborda seus comentários da Comunidade de desenvolvedores.

No hub Sprint, selecione a guia Análise. Em seguida, configure seu relatório da seguinte maneira:

  1. Selecionar lista de pendências do Stories
  2. Selecione para burndown em Soma de pontos de história

Inline sprint burndown using story points.

Wiki

URLs de páginas Wiki curtas e legíveis

Você não precisa mais usar um URL de várias linhas para compartilhar links de páginas wiki. Estamos aproveitando os IDs de página no URL para remover parâmetros, tornando o URL mais curto e fácil de ler.

A nova estrutura de URLs terá a seguinte aparência:

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Este é um exemplo da nova URL para uma página Bem-vindo ao Wiki de DevOps do Azure:

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

Isso foi priorizado com base nesse tíquete de sugestão de recurso da Comunidade de desenvolvedores.

Mermaid diagram support in wiki (Suporte para diagramas Mermaid no wiki)

Adicionamos suporte para inserir diagramas de sereia em páginas wiki. Agora você pode criar, editar e gerenciar fluxogramas, diagramas de sequência em seus documentos de design e adicionar gráficos de Gantt em seus documentos de planejamento no Azure DevOps Wiki.

Mermaid diagram support in wiki.

Isso foi priorizado com base nesse tíquete de sugestão de recurso da Comunidade de desenvolvedores. Para obter mais informações sobre diagramas de sereia, consulte nossa documentação aqui.

Próximos passos

Nota

Esses recursos serão lançados nas próximas duas a três semanas.

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

Ir para Azure DevOps

Como fornecer feedback

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

Make a suggestion

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

Obrigado,

Ravi Shanker