Partilhar via

Suporte para implementações sequenciais ao utilizar verificações de bloqueio exclusivas

  • Artigo

Neste sprint, expandimos a capacidade de verificações de bloqueio exclusivas nos Pipelines do Azure para suportar implementações sequenciais. Agora, pode colocar várias execuções em fila num ambiente para permitir que apenas uma delas seja executada de cada vez.

Consulte as seguintes descrições de funcionalidades para obter detalhes.

Azure Boards

Pipelines do Azure

Azure Boards

A secção de desenvolvimento num item de trabalho mostra a lista de consolidações e pedidos Pull relevantes. Pode ver o autor da consolidação ou do pedido Pull juntamente com a hora associada. Com esta atualização, corrigimos um problema com o avatar do autor a ser apresentado incorretamente na vista.

Pipelines do Azure

Suporte para implementações sequenciais em vez do mais recente apenas ao utilizar verificações de bloqueio exclusivas

Nos pipelines YAML, as verificações são utilizadas para controlar a execução de fases em recursos protegidos. Uma das verificações comuns que pode utilizar é uma verificação de bloqueio exclusiva. Esta verificação permite que apenas uma única execução do pipeline continue. Quando várias execuções tentam implementar num ambiente ao mesmo tempo, a verificação cancela todas as execuções antigas e permite que a execução mais recente seja implementada.

Cancelar execuções antigas é uma boa abordagem quando as versões são cumulativas e contêm todas as alterações de código das execuções anteriores. No entanto, existem alguns pipelines em que as alterações de código não são cumulativas. Com esta nova funcionalidade, pode optar por permitir que todas as execuções prossigam e implementem sequencialmente num ambiente ou preservar o comportamento anterior de cancelar execuções antigas e permitir apenas as mais recentes. Pode especificar este comportamento com uma nova propriedade chamada lockBehavior no ficheiro YAML do pipeline. Um valor de sequential implica que todas as execuções adquirem o bloqueio sequencialmente para o recurso protegido. Um valor de runLatest implica que apenas a execução mais recente adquire o bloqueio ao recurso.

Para utilizar a verificação de bloqueio exclusivo com sequential implementações ou runLatest, siga estes passos:

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

Definir num palco:

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

Definido no pipeline:

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

Se não especificar um lockBehavior, assume-se que é runLatest.

Suporte para a versão quebeque do ServiceNow

O Azure Pipelines tem uma integração existente com o ServiceNow. A integração depende de uma aplicação no ServiceNow e de uma extensão no Azure DevOps. Atualizámos agora a aplicação para trabalhar com a versão quebeque do ServiceNow. Os pipelines clássicos e YAML funcionam agora com o Quebec. Para garantir que esta integração funciona, atualize para a nova versão da aplicação (4.188.0) a partir da loja Service Now. Para obter mais informações, veja Integrar com a Gestão de Alterações do ServiceNow.

Alterar a política de pré-instalação do SDK .NET em agentes do Windows e macOS alojados na Microsoft

Recentemente, anunciámos uma alteração na política de pré-instalação do SDK .NET nos agentes Ubuntu alojados pela Microsoft. Estamos agora a fazer a mesma alteração para agentes do Windows e macOS alojados na Microsoft.

Atualmente, instalamos todas as versões disponíveis e suportadas do SDK .NET (2.1.x, 3.1.x, 5.0.x) em agentes windows e macOS alojados na Microsoft. Esta abordagem será alterada a favor da instalação da versão de patch mais recente para cada versão de funcionalidade. Esta alteração está a ser efetuada para lhe fornecer mais espaço livre e novos pedidos de ferramentas.

O que significa?

A versão do SDK é composta pelas seguintes partes: x.y.znn. z é a versão da funcionalidade e nn é a versão do patch. Por exemplo, para a versão 2.1.302, a versão da funcionalidade é 3 e 02 é a versão do patch. De acordo com a nova abordagem, iremos instalar apenas a versão de patch mais recente para cada versão de funcionalidade, ou seja, apenas 2.1.302 será instalada para 2.1.3x, apenas 2.1.403 para 2.1.4x e assim sucessivamente. Todas as versões do SDK .NET que não sejam as versões de patch mais recentes serão removidas das imagens do Windows e do macOS no dia 6 de setembro. Esta alteração afeta todas as versões do Windows e macOS nos agentes alojados na Microsoft.

Data de destino

A implementação de imagens atualizadas começará a 6 de setembro e demorará entre 3 e 4 dias.

Impacto possível

Se utilizar um ficheiro global.json, a compilação será afetada nos seguintes casos:

A compilação falhará se o ficheiro 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 .NET será alterada automaticamente para o patch mais recente se o ficheiro global.json contiver a rollForward: patch propriedade. Por exemplo:

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

Se o rollForward campo não estiver especificado no ficheiro global.json, não haverá alterações para si. É utilizado o nível de patch instalado mais recente.

Se precisar de utilizar uma versão exata do SDK .NET que não seja o patch mais recente, utilize a UseDotNet tarefa para instalá-la como parte da compilação:

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

Alterações às tarefas PublishBuildArtifacts e DownloadBuildArtifacts

O Azure Pipelines suporta dois conjuntos de tarefas para publicar/transferir artefactos. PublishPipelineArtifact e DownloadPipelineArtifact são as tarefas mais recentes e recomendadas para executar estes passos.

PublishBuildArtifacts e DownloadBuildArtifacts são as tarefas mais antigas e não têm as mesmas otimizações de desempenho e armazenamento que estão presentes nas tarefas pipelineArtifact correspondentes. Estas tarefas mais antigas também tinham limitações de dimensionamento em termos de como foram implementadas. Alguns dos nossos clientes maiores têm-se detetado nestes limites.

Embora gostaríamos que todos os clientes se deslocassem para as tarefas PipelineArtifact, também tivemos de tomar algumas medidas para abordar a escalabilidade das tarefas mais antigas do BuildArtifact. Como parte de uma atualização recente para melhorar a escalabilidade, os agentes do Azure Pipelines irão agora interagir diretamente com artefactos de compilação através de domínios blobstore (em vez de encaminhar através de domínios tfs). Estes pipelines começarão a aceder a endereços IP e domínios que estão há muito tempo na lista de permissões do Azure DevOps, mas que podem não ter sido utilizados anteriormente por pipelines específicos.

A implementação atualizada de tarefas BuildArtifact requer uma atualização do agente, o que deve ocorrer automaticamente, a menos que as atualizações automáticas tenham sido especificamente desativadas ou as firewalls estejam configuradas incorretamente.

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

Um sintoma comum deste problema são erros repentinos relacionados com handshakes de ssl ou falhas de transferência de artefactos, geralmente em conjuntos de implementação visados pelas definições de Gestão de Versões. Em alternativa, se as atualizações do agente tiverem sido bloqueadas, poderá observar que as versões estão à espera de um agente no conjunto que nunca chega ou que os agentes ficam offline a meio da atualização (este último está relacionado com ambientes que bloqueiam erroneamente a CDN do agente).

Passos seguintes

Nota

Estas funcionalidades serão implementadas nas próximas duas a três semanas.

Aceda ao Azure DevOps e dê uma vista de olhos.

Aceda ao Azure DevOps

Como fornecer comentários

Gostaríamos de saber o que pensa sobre estas funcionalidades. Utilize o menu de ajuda para comunicar um problema ou fornecer uma sugestão.

Fazer uma sugestão

Também pode obter conselhos e as suas perguntas respondidas pela comunidade no Stack Overflow.

Obrigado,

Aaron Hallberg