Compartilhar via

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

Estamos entusiasmados em anunciar a visualização 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 a Segurança Avançada do GitHub, fornecendo novos recursos que ajudam você a identificar os 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 da Segurança Avançada agora retorna as 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 ponto de extremidade, a sintaxe é semelhante aos pontos de extremidade da API de uso do medidor existente, acrescentando /details ao ponto de extremidade:

  • 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 de Segurança Avançada do GitHub para projetos C# e Java sem builds

A verificação 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 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 da Segurança Avançada do GitHub para Azure DevOps, agora pode examinar projetos C# e Java sem precisar de um build. Quando o modo de build é definido como "nenhum", o banco de dados CodeQL é gerado diretamente da base de código, ignorando a etapa de build.

Para todos os idiomas compilados, o modo de build padrão é "manual". No entanto, para C# e Java, você pode alterar o modo de build para "nenhum".

Você pode configurar o modo de build 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 um idioma diferente dos idiomas compatíveis com C# ou Java, a tarefa de pipeline poderá não funcionar conforme o esperado.

  • O modo de build "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 um idioma interpretado)

  • Exemplo inválido: C#, JavaScript e Swift com o modo de build definido como "nenhum" (não há suporte para Swift no modo de build "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 geralmente é gasta gerenciando outras tarefas, como manter a infraestrutura de DevOps.

Estamos entusiasmados em anunciar a visualização pública do MDP (Managed DevOps Pools), 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, otimizando o desempenho, a segurança, a conformidade e a eficiência de custo.

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 em assinaturas do Azure de propriedade da Microsoft.
  • Tempo gasto no Gerenciamento: O MDP reduz significativamente o tempo gasto gerenciando 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 facilmente criar vários pools específicos da equipe ou específicos da carga de trabalho.
  • Cobrança de DevOps: O MDP ajuda a otimizar a fatura de DevOps de uma equipe por meio de muitos recursos. Isso facilita que as equipes encontrem um equilíbrio ideal entre o QoS/desempenho e o custo de um pool.
  • Escalonável: O MDP é dimensionado para 1.000 agentes em um único pool.

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

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

Tarefas de pipeline do Azure usam o Node.js 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 Node.js 20. Para obter diretrizes sobre como atualizar, veja como posso atualizar minha tarefa personalizada para o Node.js mais recente?.

Permissão para criar pipeline de build

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

Captura de tela da permissão para criar pipeline de build.

Anteriormente, a Edit build pipeline permissão era necessária para criar ou editar um pipeline. Isso representava um risco à segurança, pois permitia que todos os usuários com a capacidade de criar pipelines também editem pipelines que não criaram. Impedir isso foi 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 construção não impede que outras pessoas editem um pipeline YAML; protege apenas contra a edição de suas propriedades.

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

Verificação exclusiva de bloqueio no nível do estágio

Alguns casos de uso exigem um pipeline para acessar um recurso específico apenas uma vez a qualquer momento. Para dar suporte a esse caso, temos a verificação de bloqueio exclusivo .

Uma situação semelhante ocorre quando apenas uma execução de pipeline deve acessar um estágio a qualquer instante. Por exemplo, se você tiver um estágio implantado 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, isso requer o uso de um recurso proxy, como um ambiente, e 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 adicionando suporte para especificar o bloqueio exclusivo em nível de 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 difere, pois cancela somente runLatest builds para um branch específico, não para todos os branches do pipeline inteiro.

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

Atualizamos o Pipelines Runs - Get da API REST com informações sobre os templates estendidos e incluídos durante 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 do pipeline YAML acionados manualmente

Frequentemente, recebemos solicitações sobre estágios de pipeline YAML disparados manualmente. Elas 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 de compilação, teste, implantação em um ambiente de preparo e implantação para 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 pronta.

Com esse sprint, estamos adicionando suporte para estágios de pipeline YAML disparados manualmente. Para usar esse recurso, você precisa 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 tela dos estágios de pipeline YAML disparados manualmente.

Estágios disparados 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 disparados manualmente para serem executados.

Próximas etapas

Observação

Essas funcionalidades serão lançadas 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 essas características. Use o menu de ajuda para relatar um problema ou fornecer uma sugestão.

Fazer uma sugestão

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

Obrigado

Silviu Andrica

  • Last updated on