Suporte para implantações sequenciais ao usar verificações de bloqueio exclusivas

Neste sprint, estendemos a funcionalidade de verificações de bloqueio exclusivas no Azure Pipelines para dar suporte a implantações sequenciais. Agora você pode enfileirar várias execuções em um ambiente para permitir que apenas uma delas seja executada por vez.

Confira as descrições de recursos a seguir para obter detalhes.

Azure Boards

• Exibir a persona correta em links de confirmação

Azure Pipelines

• Suporte para implantações sequenciais em vez de mais recentes somente ao usar verificações de bloqueio exclusivas
• Suporte para a versão quebec do ServiceNow
• Alteração na política de pré-instalação do SDK do .NET em agentes windows e macOS hospedados pela Microsoft
• Alterações nas tarefas PublishBuildArtifacts e DownloadBuildArtifacts

Azure Boards

Exibir a persona correta em links de confirmação

A seção de desenvolvimento em um item de trabalho mostra a lista de confirmações relevantes e solicitações de pull. Você pode exibir o autor da solicitação de confirmação ou pull junto com a hora associada. Com essa atualização, corrigimos um problema com o avatar do autor sendo exibido incorretamente na exibição.

Azure Pipelines

Suporte para implantações sequenciais em vez de mais recentes somente ao usar verificações de bloqueio exclusivas

Em pipelines YAML, as verificações são usadas para controlar a execução de estágios em recursos protegidos. Uma das verificações comuns que você pode usar é um marcar de bloqueio exclusivo. Esse marcar permite que apenas uma única execução do pipeline continue. Quando várias execuções tentam implantar em um ambiente ao mesmo tempo, o marcar cancela todas as execuções antigas e permite que a execução mais recente seja implantada.

Cancelar execuções antigas é uma boa abordagem quando suas versões são cumulativas e contêm todas as alterações de código das execuções anteriores. No entanto, há alguns pipelines nos quais as alterações de código não são cumulativas. Com esse novo recurso, você pode optar por permitir que todas as execuções prossigam e implantem sequencialmente em um ambiente ou preservar o comportamento anterior de cancelar execuções antigas e permitir apenas as mais recentes. Você pode especificar esse comportamento usando uma nova propriedade chamada lockBehavior no arquivo YAML do pipeline. Um valor de sequential implica que todas as execuções adquirem o bloqueio sequencialmente ao recurso protegido. Um valor de runLatest implica que apenas a execução mais recente adquire o bloqueio para o recurso.

Para usar a verificação de bloqueio exclusivo com implantações sequential ou runLatest, siga estas etapas:

1. Habilite a verificação de bloqueio exclusivo no ambiente (ou em outro recurso protegido).
2. No arquivo YAML do pipeline, especifique uma nova propriedade chamada lockBehavior. Isso pode ser especificado para todo o pipeline ou para uma determinada fase:

Definir em uma fase:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Definir no pipeline:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Se você não especificar um lockBehavior, será considerado runLatest.

Suporte para a versão quebec do ServiceNow

O Azure Pipelines tem uma integração existente com o ServiceNow. A integração depende de um aplicativo no ServiceNow e de uma extensão no Azure DevOps. Agora atualizamos o aplicativo para trabalhar com a versão quebec do ServiceNow. Pipelines clássicos e YAML agora funcionam com Quebec. Para garantir que essa integração funcione, atualize para a nova versão do aplicativo (4.188.0) do repositório Service Now. Para obter mais informações, consulte Integrar com o ServiceNow Change Management.

Alteração na política de pré-instalação do SDK do .NET em agentes windows e macOS hospedados pela Microsoft

Recentemente, anunciamos uma alteração na política de pré-instalação do SDK do .NET em agentes do Ubuntu hospedados pela Microsoft. Agora estamos fazendo a mesma alteração para agentes windows e macOS hospedados pela Microsoft.

Atualmente, instalamos todas as versões disponíveis e com suporte do SDK do .NET (2.1.x, 3.1.x, 5.0.x) em agentes windows e macOS hospedados pela Microsoft. Essa abordagem será alterada em favor da instalação da versão mais recente do patch para cada versão do recurso. Essa alteração está sendo feita para fornecer mais espaço livre e para novas solicitações de ferramenta.

O que isso significa?

A versão do SDK é composta pelas seguintes partes: x.y.znn. z é a versão do recurso e nn é a versão do patch. Por exemplo, para 2.1.302, a versão do recurso é 3 e 02 é a versão do patch. De acordo com a nova abordagem, instalaremos apenas a versão mais recente do patch para cada versão do recurso, ou seja, somente 2.1.302 será instalada para 2.1.3x, apenas 2.1.403 para 2.1.4x e assim por diante. Todas as versões do SDK do .NET que não são as versões de patch mais recentes serão removidas das imagens do Windows e do macOS em 6 de setembro. Essa alteração afeta todas as versões do Windows e do macOS em agentes hospedados pela Microsoft.

Data de destino

A implantação de imagens atualizadas começará em 6 de setembro e levará de 3 a 4 dias.

Possível impacto

Se você usar um arquivo global.json, o build será afetado nos seguintes casos:

O build falhará se o arquivo global.json contiver a rollForward: disable propriedade e uma versão do SDK que não seja a versão mais recente do patch. Por exemplo:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "disable"
  }
}

A versão do SDK do .NET será alterada automaticamente para o patch mais recente se o arquivo global.json contiver a rollForward: patch propriedade . Por exemplo:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "patch"
  }
}

Se o rollForward campo não for especificado em seu arquivo global.json, não haverá nenhuma alteração para você. O nível de patch instalado mais recente é usado.

Se você precisar usar uma versão exata do SDK do .NET que não seja o patch mais recente, use a UseDotNet tarefa para instalá-lo como parte do build:

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    version: <dotnet version>

Alterações nas tarefas PublishBuildArtifacts e DownloadBuildArtifacts

O Azure Pipelines dá suporte a dois conjuntos de tarefas para publicar/baixar artefatos. PublishPipelineArtifact e DownloadPipelineArtifact são as tarefas mais recentes e recomendadas para executar essas etapas.

PublishBuildArtifacts e DownloadBuildArtifacts são as tarefas mais antigas e não têm as mesmas otimizações de desempenho e armazenamento presentes nas tarefas PipelineArtifact correspondentes. Essas tarefas mais antigas também tinham limitações de escala em termos de como foram implementadas. Alguns de nossos clientes maiores têm entrado nesses limites.

Embora gostaríamos que todos os clientes migrassem para as tarefas pipelineArtifact, também tivemos que seguir algumas etapas para lidar com a escalabilidade de tarefas mais antigas do BuildArtifact. Como parte de uma atualização recente para melhorar sua escalabilidade, os agentes do Azure Pipelines agora interagirão diretamente com artefatos de build por meio de domínios blobstore (em vez de rotear por meio de domínios tfs). Esses pipelines começarão a acessar endereços IP e domínios que estão há muito tempo na lista de permissões do Azure DevOps, mas podem não ter sido usados antes por pipelines específicos.

A implementação atualizada das tarefas buildArtifact requer uma atualização do agente, o que deve acontecer automaticamente, a menos que as atualizações automáticas tenham sido desabilitadas especificamente ou os firewalls estejam configurados incorretamente.

Se os agentes estiverem em execução em ambientes com firewall que não seguiram as instruções vinculadas, eles poderão ver falhas ao atualizar o agente ou nas tarefas PublishBuildArtifacts ou DownloadBuildArtifacts até que a configuração do firewall seja corrigida.

Um sintoma comum desse problema são erros repentinos relacionados a handshakes ssl ou falhas de download de artefato, geralmente em pools de implantação direcionados por definições de Release Management. Como alternativa, se as atualizações do agente tiverem sido bloqueadas, você poderá observar que as versões estão aguardando um agente no pool que nunca chega ou que os agentes ficam offline no meio da atualização (este último está relacionado a ambientes que bloqueiam erroneamente a CDN do agente).

Próximas etapas

Observação

Esses recursos serão distribuídos nas próximas duas a três semanas.

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

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

Obrigada,

Aaron Hallberg