Partilhar via

Pools de DevOps gerenciados para DevOps do Azure (visualização)

  • Artigo

Temos o prazer de anunciar a 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 o GitHub Advanced Security, fornecendo novos recursos que ajudam a identificar os usuários.

Confira as notas de versão para obter detalhes.

Segurança Avançada do GitHub para Azure DevOps

Pipelines do Azure

Segurança Avançada do GitHub 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 para 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 ponto de extremidade, a sintaxe é semelhante aos pontos de extremidade existentes da API de uso do medidor, anexando ao ponto de /details extremidade:

  • Ao nível da organização: GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • Ao 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 de segurança avançada do GitHub para projetos C# e Java sem compilações

A verificação de código com o CodeQL envolve a execução de consultas em bancos de dados que representam o código em seu repositório para um único idioma. 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 for Azure DevOps, agora pode verificar projetos C# e Java sem precisar de uma compilação. Quando o modo de compilação é definido como "nenhum", o banco de dados CodeQL é gerado diretamente da base de código, ignorando a etapa de compilação.

Para todos os idiomas compilados, 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 instalação do AdvancedSecurity-Codeql-Init@1. Para obter instruções detalhadas sobre como configurar a verificação de código no GitHub Advanced Security com o Azure DevOps, consulte Configurar a verificação de código

Consideração:

  • Se "nenhum" estiver selecionado e uma linguagem diferente das linguagens suportadas estiver em conformidade com C# ou Java, a tarefa de pipeline pode não funcionar conforme o esperado.

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

  • Exemplo válido: C# e JavaScript com o modo de compilação definido como "nenhum". (JavaScript numa linguagem interpretada)

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

Screenshot de AdvancedSecurity-Codeql.

Pipelines do Azure

Pools de DevOps gerenciados (visualização)

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 geralmente é gasta gerenciando outras tarefas, como a manutenção da infraestrutura de DevOps.

Temos o prazer de anunciar a visualização pública dos Managed DevOps Pools (MDP), 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 Scale set 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 Managed DevOps Pools incluem:

  • Hospedado em seu nome: o MDP é hospedado e gerenciado pela Microsoft, com as máquinas virtuais alimentando os agentes criados e mantidos em assinaturas do Azure de propriedade da Microsoft.
  • Tempo gasto em 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. Torna mais fácil para as equipas encontrarem um equilíbrio ideal entre a QoS/desempenho e o custo de uma piscina.
  • Escalável: o MDP pode ser 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 de pipelines do Azure usam o Nó 20

A maioria das tarefas de pipeline usa o Node como um corredor. As tarefas de pipelines do Azure que usam NodeJS como um corredor agora usam 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?.

Criar permissão de pipeline de compilação

Para aumentar a segurança dos oleodutos, estamos introduzindo uma nova permissão, Create build pipelineno nível dos oleodutos.

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

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 foi demorado.

Para melhorar 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, apenas o criador do pipeline possa editá-lo.

Nota

A permissão Editar pipeline de construção não impede que outras pessoas editem um pipeline YAML, apenas protege as propriedades do pipeline de serem editadas.

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

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

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

Uma situação semelhante ocorre quando apenas uma corrida de gasoduto deve acessar um estágio a qualquer momento. Por exemplo, se você tiver um estágio que implanta em um grupo de recursos do Azure, convém impedir que várias execuções de pipeline atualizem simultaneamente o mesmo grupo de recursos. Atualmente, para conseguir isso, é necessário usar um recurso de proxy, como um ambiente, e colocar a verificação de bloqueio exclusivo nesse ambiente. Essa abordagem pode ser demorada, adicionar complexidade e aumentar os esforços de manutenção.

Neste sprint, estamos introduzindo suporte para especificar o bloqueio exclusivo no nível do palco. Se você tiver um estágio com um 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 só cancela compilações runLatest para a mesma ramificação, não para todas as ramificações do pipeline.

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

Atualizamos o Pipelines Runs - Get REST API 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 acionados manualmente

Frequentemente recebemos solicitações sobre estágios de pipeline YAML acionados 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 criaçã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 acionar manualmente quando estiver pronto.

Com este sprint, estamos adicionando suporte para estágios de pipeline YAML acionados 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 de 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 restam apenas estágios acionados manualmente para serem executados.

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 Ajuda para relatar um problema ou fornecer uma sugestão.

Faça uma sugestão

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

Obrigado,

Silviu Andrica