Compartilhar via

Pools de DevOps gerenciados para Azure DevOps (versão prévia)

  • Artigo

Temos o prazer de anunciar a versão prévia dos Pools de DevOps gerenciados, projetados para ajudar as equipes de desenvolvimento e engenharia de plataforma a configurar e gerenciar rapidamente pools de DevOps personalizados.

Além disso, aprimoramos as APIs de estimativa de uso do medidor para GitHub Advanced Security, fornecendo novos recursos que ajudam você a identificar usuários.

Confira as notas sobre a versão para obter detalhes.

GitHub Advanced Security para Azure DevOps

Azure Pipelines

GitHub Advanced Security para Azure DevOps

A API de uso do medidor de segurança avançada agora retorna identidades de usuário

Para ajudá-lo a identificar seus usuários de Segurança Avançada, as APIs de Estimativa de Uso do Medidor agora retornam a identidade do Azure DevOps de cada usuário, incluindo seu nome de exibição, CUID, identificador de email e descritor de identidade. Esse recurso está disponível nos níveis de organização, projeto e repositório. Para usar esse novo endpoint, a sintaxe é semelhante aos endpoints da API de uso do medidor existentes, anexando /details ao endpoint:

  • No nível da organização: GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • No nível do projeto: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • No nível do repositório: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/repositories/{repository}/meterUsageEstimate/details?api-version=7.2-preview.1

Verificação de código do GitHub Advanced Security para projetos C# e Java sem builds

A varredura de código com CodeQL envolve a execução de consultas em bancos de dados que representam o código em seu repositório para uma única linguagem. Para linguagens compiladas como C/C++, C#, Go, Java e Swift, isso normalmente requer a criação do código primeiro.

No entanto, o CodeQL, o mecanismo de análise estática por trás do GitHub Advanced Security para Azure DevOps, agora pode verificar projetos C# e Java sem precisar de um build. Quando o modo de compilação é definido como "nenhum", o banco de dados do CodeQL é gerado diretamente da base de código, ignorando a etapa de compilação.

Para todas as linguagens compiladas, o modo de compilação padrão é "manual". No entanto, para C# e Java, você pode alterar o modo de compilação para "nenhum".

Você pode configurar o modo de compilação durante a configuração do AdvancedSecurity-Codeql-Init@1. Para obter instruções detalhadas sobre como configurar a Varredura de código no GitHub Advanced Security com o Azure DevOps, consulte Configurar a Varredura de código

Consideração:

  • Se "nenhum" for selecionado e uma linguagem diferente das linguagens compatíveis com suporte C# ou Java, a tarefa de pipeline poderá não funcionar conforme o esperado.

  • O modo de construção "none" atualmente funciona em conjunto com outras linguagens interpretadas (por exemplo, JavaScript, Python, Ruby).

  • Exemplo válido: C# e JavaScript com o modo de build definido como "none". (JavaScript em uma linguagem interpretada)

  • Exemplo inválido: C#, JavaScript e Swift com o modo de compilação definido como "none" (não há suporte para Swift no modo de compilação "none").

Captura de tela do AdvancedSecurity-Codeql.

Azure Pipelines

Pools de DevOps gerenciados (versão prévia)

As equipes de engenharia se destacam quando podem se concentrar em escrever código para desenvolver aplicativos e serviços para seus usuários. No entanto, na prática, uma quantidade substancial de tempo é frequentemente gasta gerenciando outras tarefas, como manter a infraestrutura de DevOps.

Temos o prazer de anunciar a versão prévia pública do MDP (Pools de DevOps Gerenciado), um novo recurso do Azure DevOps projetado para ajudar as equipes de desenvolvimento e engenharia de plataforma a implantar pools de DevOps personalizados adaptados às suas necessidades exclusivas. O MDP combina a flexibilidade dos agentes do Conjunto de Dimensionamento com a facilidade de manutenção associada aos agentes hospedados pela Microsoft, permitindo que as equipes estabeleçam consistência e práticas recomendadas enquanto otimizam o desempenho, a segurança, a conformidade e a eficiência de custos.

Os principais benefícios dos pools de DevOps gerenciados incluem:

  • Hospedado em seu nome: o MDP é hospedado e gerenciado pela Microsoft, com as máquinas virtuais alimentando os agentes criados e mantidos nas assinaturas do Azure de propriedade da Microsoft.
  • Tempo gasto no gerenciamento: o MDP reduz significativamente o tempo gasto no gerenciamento de agentes, especialmente aqueles baseados em infraestrutura local ou sistemas mantidos manualmente.
  • Pools específicos: devido à facilidade com que novos pools podem ser criados, as organizações podem criar facilmente vários pools específicos da equipe ou da carga de trabalho.
  • Faturamento de DevOps: o MDP ajuda a otimizar a fatura de DevOps de uma equipe por meio de muitos recursos. Isso torna mais fácil para as equipes encontrarem um equilíbrio ideal entre QoS/desempenho e custo de um pool.
  • Escalável: o MDP é dimensionado para 1000 agentes em um único pool.

As equipes podem criar pools com imagens de início rápido que contêm o mesmo software presente nos agentes hospedados pela Microsoft ou com imagens que a equipe criou com pré-requisitos exclusivos para seu cenário.

Saiba mais sobre os pools de DevOps gerenciados lendo nossa postagem no blog ou sua documentação.

As tarefas do Azure Pipelines usam o Nó 20

A maioria das tarefas de pipeline usa o Node como um executor. A tarefa de pipelines do Azure que usa o NodeJS como um executor agora usa o NodeJS 20. Os autores de extensões de tarefa devem atualizar suas tarefas para usar o Nó 20. Para obter orientação sobre como atualizar, consulte Como posso atualizar minha tarefa personalizada para o nó mais recente?.

Permissão Criar pipeline de build

Para aumentar a segurança do pipeline, estamos introduzindo uma nova permissão, Create build pipeline, no nível dos pipelines.

Captura de tela da permissão de criação de pipeline de build.

Anteriormente, a Edit build pipeline permissão era necessária para criar ou editar um pipeline. Isso representava um risco de segurança, pois permitia que todos os usuários com a capacidade de criar pipelines também editassem pipelines que não criaram. Evitar isso era demorado.

Para aprimorar sua experiência de pipeline sem comprometer a segurança, todos os usuários e grupos com a Edit build pipeline permissão agora também receberão a Create build pipeline permissão.

Quando um pipeline é criado, seu criador recebe a Edit build pipeline permissão.

Para melhorar a segurança do pipeline, você pode optar por remover a Edit build pipeline permissão de grupos de usuários, como Colaboradores e Leitores. Isso garante que, por padrão, somente o criador do pipeline possa editá-lo.

Observação

A permissão Editar pipeline de build não impede que outras pessoas editem um pipeline YAML; ela apenas protege as propriedades do pipeline de serem editadas.

Para novos projetos, usuários e grupos com permissão Edit build pipeline também terão a Create build pipeline permissão. Isso está sujeito a alterações no futuro.

Verificação de bloqueio exclusiva no nível do palco

Alguns casos de uso exigem que um pipeline acesse um recurso específico apenas uma vez a qualquer momento. Para apoiar este caso, temos a verificação de bloqueio exclusivo.

Uma situação semelhante surge quando apenas uma execução de pipeline deve acessar um estágio a qualquer momento. Por exemplo, se você tiver um estágio implantado em um grupo de recursos do Azure, talvez queira impedir que várias execuções de pipeline atualizem simultaneamente o mesmo grupo de recursos. Atualmente, conseguir isso requer o uso de um recurso de proxy, como um ambiente, e colocar a verificação de bloqueio exclusivo nesse ambiente. Essa abordagem pode ser demorada, aumentar a complexidade e aumentar os esforços de manutenção.

Neste sprint, estamos introduzindo suporte para especificar o bloqueio exclusivo no nível do estágio. Se você tiver um estágio com uma ID e especificar sua lockBehavior propriedade, um bloqueio será criado automaticamente para esse estágio. O sequential comportamento permanece consistente para bloqueios no nível do recurso e no nível do estágio. No entanto, o runLatest comportamento é diferente, pois cancela runLatest apenas builds para o mesmo branch, não para todos os branches do pipeline.

Informações de modelo em execuções de pipeline

Atualizamos a API Pipelines Runs – Get REST com informações sobre os modelos estendidos e incluídos em uma execução de pipeline.

Por exemplo, considere que você tem o seguinte código de pipeline YAML:

extends:
  template: template-stages.yml@templates
  parameters:
    stages:
    - stage: deploy
      jobs:
      - job:
        steps:
        - template: template-step.yml

A nova API REST tem as seguintes novas propriedades:

"yamlDetails":
    {
        "extendedTemplates":
        [
            {
                "yamlFile": "template-stages.yml",
                "repoAlias": "templates"
            }
        ],
        "includedTemplates":
        [
            {
                "yamlFile": "template-step.yml",
                "repoAlias": "templates"
            }
        ],
        "rootYamlFile":
        {
            "ref": "refs/heads/main",
            "yamlFile": "azure-pipelines.yml",
            "repoAlias": "self"
        },
        "expandedYamlUrl": "https://dev.azure.com/fabrikamfiber/161cfeeb-d9fd-395c-917b-fec46db44fbb/_apis/build/builds/39224/logs/1"
    }

Estágios de pipeline YAML disparados manualmente

Freqüentemente, recebemos solicitações sobre estágios de pipeline YAML disparados manualmente. Eles são úteis quando você deseja um pipeline unificado, mas nem sempre deseja que ele seja executado até a conclusão.

Por exemplo, seu pipeline pode incluir estágios para compilação, teste, implantação em um ambiente de preparo e implantação em produção. Talvez você queira que todos os estágios sejam executados automaticamente, exceto a implantação de produção, que você prefere disparar manualmente quando estiver pronto.

Com este sprint, estamos adicionando suporte para estágios de pipeline YAML disparados manualmente. Para usar esse recurso, você precisa adicionar a trigger: manual propriedade a um estágio.

Considere o seguinte exemplo de pipeline YAML:

stages:
- stage: stage_WUS1
  displayName: Deploy WUS1
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''     
- stage: stage_WUS2
  displayName: Deploy WUS2
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''

Quando você executa esse pipeline, a experiência é a seguinte:

Captura de tela dos estágios do pipeline YAML acionados manualmente.

Os estágios acionados manualmente não têm dependências e podem ser executados a qualquer momento. A execução do pipeline é concluída quando há apenas estágios acionados manualmente para serem executados.

Próximas etapas

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.

Ir para o Azure DevOps

Como fornecer comentários

Adoraríamos ouvir o que você pensa sobre esses recursos. Use o menu de ajuda 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.

Obrigada,

Silviu Andrica