Eventos
17 de mar., 21 - 21 de mar., 10
Junte-se à série de encontros para criar soluções de IA escaláveis com base em casos de uso do mundo real com outros desenvolvedores e especialistas.
Registrar agoraNovos relatórios do Google Analytics e o aplicativo Azure Boards para o Slack - Atualização da Sprint 155
Na Atualização do Sprint 155 do Azure DevOps, introduziremos novos relatórios do Azure Boards para facilitar o acompanhamento de métricas importantes da equipe. Os novos relatórios poderão ser vistos na guia Análise nos hubs do Boards, da Lista de Pendências e do Sprint. Esses relatórios são totalmente interativos e ajustáveis para atender às suas necessidades.
Além disso, estamos felizes por anunciar o novo aplicativo do Azure Boards para Slack. O aplicativo permitirá monitorar atividades de item de trabalho e criar itens do canal do Slack.
Confira a lista de recursos abaixo para saber mais.
- tenha insights sobre a integridade de sua equipe com três novos relatórios do Azure Boards
- Aplicativo do Azure Boards para Slack
- Personalize colunas do quadro de tarefas
- Alterne entre mostrar e ocultar itens de trabalho filho concluídos na lista de pendências
- Pesquise por quadros, listas de pendências, consultas e sprints na caixa de pesquisa instantânea
- As marcações mais recentes são exibidas ao marcar um item de trabalho
- opções aprimoradas de filtragem de pesquisa de código
- Métricas de cobertura de código e política de ramificação para solicitações de pull
- Filtre notificações de comentários das solicitações de pull
- Ganchos de serviço para comentários de solicitação de pull
- Aprovações nos pipelines YAML de vários estágios
- Gerencie as variáveis de pipeline no editor YAML
- Novas variáveis predefinidas no pipeline YAML
- Cancele um estágio na execução do pipeline YAML de vários estágios
- Exiba informações corretas de pool para cada trabalho
- Associe itens de trabalho com pipelines YAML de vários estágios
- Gatilhos de CI para novas ramificações
- Cache de pipeline (versão prévia pública)
- kustomize e kompose como opções de bake na tarefa KubernetesManifest
- Suporte para credenciais de administrador do cluster na tarefa HelmDeploy
- Melhorias da Central de Implantação para o WebApp no portal do Azure
- Aprimoramentos do Projeto de DevOps para máquina virtual
Agora você pode convidar colaboradores do GitHub para o Azure DevOps quando estiver conectado com sua identidade do GitHub. Você pode pesquisar e convidar outros usuários do GitHub na página inicial do Project e na página Usuários nas configurações da organização.
Esse recurso deve ser habilitado para organizações existentes por meio de uma configuração em Políticas nas Configurações da organização. No entanto, ele é ativado por padrão para organizações criadas por uma identidade do GitHub.
Observação
Esse recurso não está disponível para usuários que não são do GitHub, mesmo que a política esteja ativada.
Para saber mais sobre como convidar membros da equipe, consulte a documentação aqui. Se você estiver tendo problemas para se conectar ao Azure DevOps usando o GitHub, consulte as perguntas frequentes sobre solução de problemas de autenticação e convite a usuários do GitHub.
Você não pode consertar o que não pode ver. Por isso, é preciso ficar de olho no estado e na saúde de seus processos de trabalho. Com esses relatórios, estamos tornando mais fácil para você controlar métricas importantes com o mínimo de esforço nos Azure Boards.
Os três novos relatórios interativos são: Burndown, Diagrama de Fluxo Cumulativo (CFD) e Velocidade. Você pode ver os relatórios na nova guia de análise.
Métricas como burndown de sprint, fluxo de trabalho e velocidade da equipe dão visibilidade do progresso da sua equipe e ajudam a responder perguntas como:
- Quanto trabalho nos resta neste sprint? Estamos no caminho certo para concluí-lo?
- Qual etapa do processo de desenvolvimento está demorando mais? Podemos fazer algo a respeito?
- Com base em iterações anteriores, quanto trabalho devemos planejar para o próximo sprint?
Observação
Os gráficos mostrados anteriormente nos cabeçalhos foram substituídos por esses relatórios aprimorados.
Os novos relatórios são totalmente interativos e permitem ajustá-los às suas necessidades. Você pode encontrar os novos relatórios na guia Analytics em cada hub.
O gráfico de burndown pode ser encontrado no hub Sprints .
Os relatórios CFD e Velocity podem ser acessados na guia Analytics em Quadros e Backlogs clicando no cartão relevante.
Com os novos relatórios você tem mais controle e informações sobre sua equipe. Estes são alguns exemplos:
- Os relatórios Burndown da Sprint e Velocidade podem ser definidos para usar a contagem de itens de trabalho ou a soma do trabalho restante.
- Você pode ajustar o período de tempo do burndown de sprint sem afetar as datas do projeto. Então, se sua equipe costuma passar o primeiro dia de cada planejamento de sprint, agora você pode combinar o gráfico para refletir isso.
- O gráfico Burndown agora tem uma marca d'água mostrando fins de semana.
- O relatório CFD permite remover colunas do quadro como Design para obter mais foco no fluxo sobre o qual as equipes têm controle.
Aqui está um exemplo do relatório CFD mostrando o fluxo dos últimos 30 dias da lista de pendências do Stories.
O gráfico Velocity agora pode ser rastreado para todos os níveis de lista de pendências. Por exemplo, agora você pode adicionar Recursos e Épicos, enquanto antes o gráfico anterior suportava apenas Requisitos. Aqui está um exemplo de um relatório de velocidade para as últimas 6 iterações da lista de pendências de recursos.
Temos o prazer de anunciar o novo aplicativo Azure Boards para o Slack. Com este aplicativo, você pode monitorar a atividade do item de trabalho e criar itens de trabalho do seu canal do Slack.
O aplicativo permite configurar e gerenciar assinaturas de eventos, incluindo criação e atualizações de itens de trabalho, e receber notificações para esses eventos em seu canal do Slack. As conversas no canal do Slack podem ser usadas para criar itens de trabalho. Você também receberá notificações pessoais quando itens de trabalho forem atribuídos a você. Além disso, as visualizações de URLs de item de trabalho permitirão que você inicie discussões.
Para instalar o aplicativo Azure Boards, clique aqui.
Temos o prazer de anunciar que adicionamos uma opção para permitir que você personalize as colunas no Painel de Tarefas. Agora você pode adicionar, remover, renomear e reordenar as colunas.
Para configurar as colunas no Painel de Tarefas, vá para Opções de Coluna.
Esse recurso foi priorizado com base em uma sugestão da Comunidade de desenvolvedores.
Muitas vezes, ao refinar a lista de pendências, você só quer ver itens que não foram concluídos. Agora, você tem a capacidade de mostrar ou ocultar itens filho concluídos na lista de pendências.
Se a alternância estiver ativada, você verá todos os itens filho em um estado concluído. Quando a alternância estiver desativada, todos os itens filho em um estado concluído serão ocultados da lista de pendências.
Agora você pode acessar facilmente seus quadros visitados recentemente, listas de pendências, consultas e sprints na caixa de pesquisa ativando a caixa de pesquisa nos Quadros do Azure.
Além disso, você pode pesquisar os quadros, listas de pendências, consultas e sprints em todo o seu projeto digitando o nome do quadro na caixa de pesquisa. Agora, as placas que mais importam para você estão a apenas um clique de distância.
Ao marcar um item de trabalho, a opção de preenchimento automático agora exibirá até cinco das tags usadas mais recentemente. Isso facilitará a adição das informações corretas aos seus itens de trabalho.
Anteriormente, a pesquisa de código suportava 39 filtros de pesquisa de código, como comment: e def:. Os dados sugeriram que havia muitos filtros não sendo usados, portanto, estamos removendo alguns filtros e fundindo outros. Com esta atualização, reduzimos o número de filtros para 19. Isso ajudará tornando as consultas de pesquisa de código mais eficientes e reduzindo a desordem na interface.
Por exemplo, agora func: maps to method:, ou seja, se você procurar por func:AccountAdmin, os resultados serão mapeados para method:AccountAdmin. Da mesma forma, macrodef: e macroref: são mapeados para macro:. Por outro lado, filtros como union: e org: foram preteridos por falta de uso.
Agora você pode ver as métricas de cobertura de código para alterações na exibição de solicitação pull (PR). Isso garante que você tenha testado adequadamente suas alterações por meio de testes automatizados. O status da cobertura aparecerá como um comentário na visão geral de relações públicas. Você pode exibir detalhes das informações de cobertura para cada linha de código alterada na exibição de comparação de arquivo.
Além disso, os proprietários de repositório agora podem definir políticas de cobertura de código e impedir que alterações grandes e não testadas sejam mescladas em uma ramificação. Os limites de cobertura desejados podem ser definidos em um azurepipelines-coverage.yml arquivo de configurações com check-in na raiz do repositório e a política de cobertura pode ser definida usando a configuração existente de uma política de ramificação para recursos de serviços adicionais no Azure Repos.
Comentários em solicitações pull muitas vezes podem gerar muito ruído devido a notificações. Adicionamos uma assinatura personalizada que permite filtrar quais notificações de comentário você assina por idade do comentário, comentarista, comentário excluído, usuários mencionados, autor da solicitação pull, ramificação de destino e participantes do thread. Você pode criar essas assinaturas de notificação clicando no ícone do usuário no canto superior direito e navegando até Configurações do usuário.
Agora você pode criar ganchos de serviço para comentários em uma solicitação pull com base no repositório e na ramificação de destino.
Agora você pode criar e armazenar seus pacotes dentro de feeds públicos. Os pacotes armazenados em feeds públicos estão disponíveis para todos na Internet sem autenticação, estejam ou não na sua organização ou mesmo conectados a uma organização de DevOps do Azure. Saiba mais sobre feeds públicos em nossa documentação de feeds ou vá direto para nosso tutorial para compartilhar pacotes publicamente.
kustomize (parte do Kubernetes sig-cli) permite que você personalize arquivos YAML brutos e sem modelos para vários fins e deixa o YAML original intocado. Uma opção para kustomize foi adicionada na ação bake da tarefa KubernetesManifest para que qualquer pasta contendo arquivos kustomization.yaml possa ser usada para gerar os arquivos de manifesto usados na ação de implantação da tarefa KubernetesManifest.
YAML
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
renderType: kustomize
kustomizationPath: folderContainingKustomizationFile
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)
kompose transformará um Docker Compose arquivos em um recurso Kubernetes.
YAML
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
renderType: kompose
dockerComposeFile: docker-compose.yaml
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)
Anteriormente, a tarefa HelmDeploy usava as credenciais de usuário do cluster para implantações. Isso resultou em prompts de logon interativos e pipelines com falha para um cluster habilitado para RBAC baseado no Active Directory do Azure. Para resolver esse problema, adicionamos uma caixa de seleção que permite usar credenciais de administrador de cluster em vez de credenciais de usuário de cluster.
Atualizamos a experiência para gerenciar variáveis de pipeline no editor YAML. Você não precisa mais ir para o editor clássico para adicionar ou atualizar variáveis em seus pipelines YAML.
As variáveis oferecem uma forma conveniente de inserir os principais bits de dados em várias partes do pipeline. Com essa atualização, adicionamos algumas variáveis predefinidas a um trabalho de implantação. Essas variáveis são definidas automaticamente pelo sistema, com escopo para o trabalho de implantação específico e são somente leitura.
- Environment.Id - O ID do ambiente.
- Environment.Name - O nome do ambiente direcionado pelo trabalho de implantação.
- Environment.ResourceId - A ID do recurso no ambiente de destino do trabalho de implantação.
- Environment.ResourceName - O nome do recurso no ambiente de destino do trabalho de implantação.
Atualmente, você pode vincular automaticamente itens de trabalho com compilações clássicas. No entanto, isso não foi possível com os pipelines YAML. Com esta atualização, resolvemos essa lacuna. Quando você executa um pipeline com êxito usando o código de uma ramificação especificada, o Azure Pipelines associará automaticamente a execução a todos os itens de trabalho (que são inferidos por meio das confirmações nesse código). Ao abrir o item de trabalho, você poderá ver as execuções nas quais o código desse item de trabalho foi criado. Para configurar isso, use o painel de configurações de um pipeline.
Ao executar um pipeline YAML de vários estágios, agora você pode cancelar a execução de um estágio enquanto ele estiver em andamento. Isso é útil se você souber que o estágio vai falhar ou se tiver outra execução que deseja iniciar. Esse recurso também é um pré-requisito para que possamos apoiar a repetição de um estágio com falha no futuro.
Continuamos a melhorar os pipelines YAML de vários estágios, agora permitimos que você adicione aprovações manuais a esses pipelines. Os proprietários de infraestrutura podem proteger seus ambientes e buscar aprovações manuais antes que um estágio em qualquer pipeline seja implantado neles. Com a segregação completa de funções entre proprietários de infraestrutura (ambiente) e de aplicativos (pipeline), você garantirá a aprovação manual para implantação em um pipeline específico e obterá controle central ao aplicar as mesmas verificações em todas as implantações no ambiente.
A execução do pipeline de implantação no dev será interrompida para aprovação no início do estágio.
Fizemos atualizações em várias das imagens de VM hospedadas do Azure Pipelines. Você pode encontrar mais detalhes sobre os últimos lançamentos aqui. As seguintes alterações foram adicionadas como parte desta atualização:
Para VS2017 e VS2019:
- Adicionado Azul Java 7
- Imagens do Docker em cache fixas para corresponder à versão do kernel do host
- Adicionado módulo do PowerShell Az v2.3.2
- Fixou o Mercurial na v5.0.0
- Python atualizado para as versões 2.7.16, 3.4.4, 3.5.4, 3.6.8, 3.7.4
- Biblioteca de classes portátil adicionada (somente VS 2019)
- Caminhos padrão e variáveis de ambiente do Rust alterados
Para o Ubuntu 16.04:
- Leme atualizado para sempre puxar mais recente (não mais fixado na v2.14.0)
- Adicionados vários contêineres populares do Docker
- Python atualizado para as versões 2.7.16, 3.4.10, 3.5.7, 3.6.9, 3.7.4
- Caminhos padrão e variáveis de ambiente do Rust alterados
Para todas as imagens, foi adicionada uma
ImageVersionvariável de ambiente para a versão da imagem
Para obter uma lista completa de ferramentas disponíveis para uma imagem específica, vá para Detalhes dos pools > de agentes de configurações>.
Nesta atualização, aprimoramos o fluxo de trabalho da máquina virtual (VM) DevOps Projects para incluir as VMs que não estão em conformidade com a restrição de cota por local. Anteriormente, você tinha que escolher a VM por nome e oferta. Agora, você tem uma visão sob demanda com mais detalhes sobre as ofertas de VM, como custo/mês, RAM, discos de dados etc. Isso facilita a seleção da máquina virtual necessária.
No último sprint, comunicamos que estamos lançando um novo pool hospedado chamado Azure Pipelines para substituir todos os outros pools hospedados - Hosted, Hosted VS2017, Hosted Ubuntu 1604, Hosted Windows 2019 with VS2019, Hosted macOS e Hosted macOS High Sierra. Essa alteração será implementada com esta versão.
Ter vários pools hospedados pode ser confuso às vezes. Você não tem uma imagem precisa de onde a simultaneidade está sendo consumida. Por exemplo, se você tiver uma simultaneidade de 10 trabalhos paralelos, verá 10 agentes virtuais em cada um dos pools hospedados, o que não é preciso. Quando seu trabalho está aguardando em um pool hospedado específico (por exemplo, Hosted VS2017) com todos os agentes ociosos, você pode pensar que o serviço Azure Pipelines está quebrado sem perceber que a simultaneidade é possivelmente consumida em outros pools hospedados (por exemplo, Ubuntu 1604 hospedado).
Com essa alteração, você verá um único pool hospedado que lhe dará uma imagem precisa de quantos trabalhos estão sendo executados nesse pool. Planejamos implementar essa mudança nos próximos sprints. Você não precisará fazer alterações em seus pipelines, pois redirecionaremos automaticamente os trabalhos dos pools hospedados antigos para a imagem apropriada no novo pool unificado.
Anteriormente, quando você usava uma matriz para expandir trabalhos ou uma variável para identificar um pool, tínhamos problemas para mostrar as informações corretas do pool nas páginas de logs. Com essa atualização, corrigimos os problemas que faziam com que informações incorretas do pool fossem mostradas para determinados trabalhos.
Testes irregulares podem afetar a produtividade dos desenvolvedores, uma vez que as falhas de teste podem não estar relacionadas às alterações em teste. Eles também podem afetar a qualidade do código enviado. É por isso que adicionamos suporte no produto para gerenciamento de testes escamosos. Essa funcionalidade oferece suporte ao ciclo de vida completo com detecção, emissão de relatórios e resolução. O gerenciamento de testes de regressão dá suporte à detecção personalizada e ao sistema.
A detecção do sistema está disponível por meio do recurso de reexecução de tarefas do VSTest. Um teste de regressão fornece resultados diferentes, como aprovação ou reprovação, mesmo quando não há alterações no código-fonte ou no ambiente de execução. Todas as execuções adicionais de teste para a mesma ramificação também são marcadas como escamosas até que seja resolvida e desmarcada. Você também pode conectar seu mecanismo de detecção personalizado usando nossas APIs. Depois que um teste é identificado como escamoso, você pode obter os detalhes no relatório de teste no contexto no pipeline. Em seguida, você pode decidir se os testes escamosos afetam a falha do pipeline. Por padrão, as informações de teste escamosas estão disponíveis como metadados adicionais.
Aqui está um exemplo de um relatório com o resumo do teste.
Para obter mais detalhes sobre o gerenciamento de testes escamosos, consulte a documentação aqui.
Melhoramos o Centro de Implantação para WebApp no portal do Azure com suporte para pipelines com vários artefatos. Agora, se um artefato não primário do Azure Pipelines for implantado no aplicativo Web, você obterá detalhes relevantes do portal do Azure. Você também terá um link direto para o repositório implantado para navegar diretamente para o repositório a partir do portal do Azure. O repositório pode ser hospedado no Azure Repos ou no GitHub.
Tem sido uma solicitação há muito pendente para não disparar compilações de CI quando uma nova ramificação é criada e quando essa ramificação não tem alterações. Considere os seguintes exemplos:
- Use a interface da Web para criar uma nova ramificação com base em uma ramificação existente. Isso acionaria imediatamente uma nova compilação de CI se o filtro de ramificação corresponder ao nome da nova ramificação. Isso é indesejado porque o conteúdo da nova ramificação é o mesmo quando comparado à ramificação existente.
- Você tem um repositório com duas pastas - app e docs. Você configura um filtro de caminho para CI para corresponder a "aplicativo". Em outras palavras, você não deseja criar uma nova compilação se uma alteração tiver sido enviada para documentos. Criar uma nova ramificação localmente, fazer algumas alterações em documentos e, em seguida, enviar por push para o servidor. Costumávamos acionar uma nova compilação de IC. Isso é indesejado, pois você pediu explicitamente para não procurar alterações na pasta de documentos. No entanto, devido à maneira como lidamos com um novo evento de ramificação, parece que uma alteração também foi feita na pasta do aplicativo.
Agora, temos uma maneira melhor de lidar com a IC para novas filiais para resolver esses problemas. Quando você publica uma nova ramificação, procuramos explicitamente novas confirmações nessa ramificação e verificamos se elas correspondem aos filtros de caminho.
Terraform é uma ferramenta de código aberto para desenvolver, alterar e versionar infraestrutura com segurança e eficiência. O Terraform codifica APIs em arquivos de configuração declarativos, permitindo que você defina e provisione a infraestrutura usando uma linguagem de configuração de alto nível. Você pode usar a extensão Terraform para criar recursos em todos os principais provedores de infraestrutura: Azure, Amazon Web Services (AWS) e Google Cloud Platform (GCP).
Para saber mais sobre a extensão Terraform, consulte a documentação aqui.
A estrutura de experimentos do Google Analytics permite testar praticamente qualquer alteração ou variação em um site ou aplicativo para medir seu impacto em um objetivo específico. Por exemplo, você pode ter atividades que deseja que seus usuários concluam (por exemplo, fazer uma compra, inscrever-se em um boletim informativo) e/ou métricas que deseja melhorar (por exemplo, receita, duração da sessão, taxa de rejeição). Essas atividades permitem identificar alterações que valem a pena implementar com base no impacto direto que elas têm no desempenho do recurso.
A extensão de experimentos do Google Analytics para DevOps do Azure adiciona etapas de experimentação aos pipelines de compilação e lançamento, para que você possa iterar, aprender e implantar continuamente em um ritmo acelerado gerenciando os experimentos continuamente enquanto obtém todos os benefícios de DevOps do Azure Pipelines.
Você pode baixar a extensão de experimentos do Google Analytics no Marketplace.
O cache de pipeline permite salvar os resultados de uma operação de longa execução, como uma restauração de pacote ou uma compilação de dependência, e restaurá-lo de volta durante a próxima execução de um pipeline. Isso pode resultar em compilações mais rápidas.
Para mais detalhes, veja a postagem no blog com o anúncio completo aqui.
Pode ser um desafio portar pipelines baseados em YAML de um projeto para outro, pois você precisa configurar manualmente as variáveis de pipeline e os grupos de variáveis. No entanto, com o grupo de variáveis de pipeline e os comandos de gerenciamento de variáveis, agora você pode criar scripts para configurar e gerenciar variáveis de pipeline e grupos de variáveis que, por sua vez, podem ser controlados por versão, permitindo que você compartilhe facilmente as instruções para mover e configurar pipelines de um projeto para outro.
Ao criar um PR, pode ser desafiador validar se as alterações podem interromper a execução do pipeline na ramificação de destino. No entanto, com a capacidade de disparar uma execução de pipeline ou enfileirar uma compilação para uma ramificação de RP, agora você pode validar e visualizar as alterações em andamento executando-a no pipeline de destino. Consulte az pipelines run e az pipelines build queue command documentation para obter mais informações.
Ao criar pipelines, às vezes você deseja criar e confirmar um arquivo YAML e não acionar a execução do pipeline, pois isso pode resultar em uma execução defeituosa devido a uma variedade de razões - a infraestrutura não está pronta ou precisa criar e atualizar grupos de variáveis/variáveis, etc. Com a CLI de DevOps do Azure, agora você pode ignorar a primeira execução de pipeline automatizada na criação de um pipeline incluindo o parâmetro --skip-first-run. Consulte az pipeline create command documentation para obter mais informações.
Os comandos da CLI do ponto de extremidade de serviço suportavam apenas a configuração e o gerenciamento do ponto de extremidade de serviço azure rm e github. No entanto, com esta versão, os comandos de ponto de extremidade de serviço permitem que você crie qualquer ponto de extremidade de serviço fornecendo a configuração via arquivo e fornece comandos otimizados - az devops service-endpoint github e az devops service-endpoint azurerm, que fornecem suporte de primeira classe para criar pontos de extremidade de serviço desses tipos. Consulte a documentação do comando para obter mais informações.
Observação
Esses recursos serão lançados nas próximas duas a três semanas.
Vá até o Azure DevOps e dê uma olhada.
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.
Você também pode obter conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.
Obrigada,
Sam Guckenheimer
Recursos adicionais
Treinamento
Roteiro de aprendizagem
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization
Certificação
Microsoft Certified: DevOps Engineer Expert - Certifications
Esta certificação mede sua capacidade de realizar as seguintes tarefas técnicas: Projetar e implementar processos e comunicações, projetar e implementar uma estratégia de controle do código-fonte, projetar e implementar pipelines de criação e liberação, desenvolver um plano de segurança e conformidade e implementar uma estratégia de instrumentação.