Partilhar via

Pools de DevOps geridos para o Azure DevOps (versão de pré-visualização)

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.

Consulte as notas de versão para obter detalhes.

GitHub Advanced Security para o Azure DevOps

Azure Pipelines (Pipelines do Azure)

GitHub Advanced Security para o 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 este novo endpoint, a sintaxe é semelhante aos endpoints existentes da API de uso do medidor, anexando /details ao endpoint.

  • Ao nível da organização: executar o comando 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, como C# ou Java, for usada, 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 modo de compilação definido como "nenhum". (JavaScript em uma 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").

Captura de ecrã do AdvancedSecurity-Codeql.

Azure Pipelines (Pipelines do Azure)

Conjuntos DevOps geridos (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:

  • Alojado 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 despendido em Gestão: O MDP reduz significativamente o tempo gasto no gerenciamento de agentes, particularmente aqueles baseados em infraestrutura local ou sistemas mantidos manualmente.
  • Piscinas Específicas: Devido à facilidade com que novos pools podem ser criados, as organizações podem criar facilmente vários pools específicos para equipas ou para cargas 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 milhares de agentes num ú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 Node 20

A maioria das tarefas de pipeline usa o Node como executor. As tarefas dos pipelines do Azure que utilizam NodeJS como executor passam a usar NodeJS 20. Os autores de extensões de tarefa devem atualizar as suas tarefas para usar o Node.js 20. Para orientação sobre a atualização, consulte Como posso atualizar a minha tarefa personalizada para o mais recente Node?.

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 a sua experiência do pipeline sem comprometer a segurança, todos os utilizadores e grupos com a permissão Edit build pipeline receberão agora também a permissão Create build pipeline.

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.

Observação

A permissão Editar pipeline de compilação não impede que outras pessoas editem um pipeline YAML; apenas protege as propriedades do pipeline contra alterações.

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 de etapa

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 execução de pipeline deve acessar uma etapa num dado momento. Por exemplo, se tiveres um estágio que implanta num grupo de recursos do Azure, podes querer impedir que várias execuções de pipeline atualizem simultaneamente o mesmo grupo de recursos. Atualmente, para conseguir isso, é necessário utilizar um recurso de proxy, como um ambiente, e aplicar 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 a introduzir suporte para especificar o bloqueio exclusivo ao nível da fase. Se tiver um estágio com um ID e especificar a sua lockBehavior propriedade, um bloqueio será criado automaticamente para esse estágio. O comportamento do sequential permanece consistente tanto para bloqueios ao nível do recurso como ao nível do estágio. No entanto, o comportamento do runLatest é diferente, pois cancela apenas as 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"
    }

Fases de pipeline YAML acionadas manualmente

Frequentemente recebemos solicitações sobre estágios de pipeline YAML acionados manualmente. Eles são úteis quando desejas um pipeline unificado, mas nem sempre queres que ele seja conduzido até ao fim.

Por exemplo, o seu pipeline pode incluir estágios para construção, teste, implantação em um ambiente de teste 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 este recurso, precisas adicionar a propriedade trigger: manual 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 ecrã 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 restam apenas os estágios que precisam ser acionados manualmente.

Próximos passos

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 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

  • Last updated on