Azure Pipelines - Atualização do Sprint 230
Funcionalidades
- As tarefas do Azure Pipelines usam o Nó 16
- Anunciando a aposentadoria de tarefas preteridas
- A tarefa AzureRmWebAppDeployment suporta a autenticação de ID do Microsoft Entra
- Melhorias na API REST de aprovações
- Suporte para GitHub Enterprise Server na verificação de modelo necessário
- Ignorar aprovações e verificações
- Execute novamente as verificações da função do Azure Invoke
As tarefas do Azure Pipelines usam o Nó 16
As tarefas no pipeline são executadas usando um corredor, com Node.js usado na maioria dos casos. As tarefas do Azure Pipelines que utilizam um Nó como corredor agora usam o Nó 16. Como o Node 16 é a primeira versão do Node a suportar nativamente o silício da Apple, isso também completa o suporte completo de tarefas para macOS no silício da Apple. Os agentes que executam silício da Apple não precisam do Rosetta para serem executados.
À medida que a data de fim de vida útil do Nó 16 avançou, iniciamos o trabalho para executar tarefas com o Nó 20.
Anunciando a aposentadoria de tarefas preteridas
O Azure Pipelines tem muitas tarefas preteridas. As tarefas preteridas serão desativadas em 31 de janeiro de 2024. Para ajudá-lo a identificar pipelines que estão usando tarefas preteridas, os pipelines mostrarão avisos se tal tarefa for usada. Atualizámos a Referência de Tarefa para transmitir claramente o estado de substituição e a data de reforma.
As seguintes tarefas foram preteridas e começarão a emitir avisos:
- AppCenterDistributeV1,
- AppCenterDistributeV2
- AzureMonitorV0
- ChefKnifeV1
- ChefV1
- CondaAmbienteV1
- DeployVisualStudioTestAgentV2
- DotNetCoreInstallerV1
- IISWebAppDeployment
- QuickPerfTestV1
- RunJMeterLoadTestV1
- RunLoadTestV1
- SqlServerDacpacDeploymentV1
- XamarinTestCloudV1
Atualize seus pipelines para usar uma versão de tarefa mais recente ou uma alternativa antes de 31 de janeiro de 2024.
A tarefa AzureRmWebAppDeployment suporta a autenticação de ID do Microsoft Entra
As tarefas AzureRmWebAppDeploymentV3 e AzureRmWebAppDeployment@4 foram atualizadas para dar suporte ao Serviço de Aplicativo com a autenticação básica desabilitada. Se a autenticação básica estiver desabilitada no Serviço de Aplicativo, as tarefas AzureRmWebAppDeploymentV3/4 usarão a autenticação de ID do Microsoft Entra para executar implantações no ponto de extremidade Kudu do Serviço de Aplicativo. Isso requer uma versão recente do msdeploy.exe instalada no agente, que é o caso dos agentes hospedados windows-2022/windows-latest (consulte a referência da tarefa).
Melhorias na API REST de aprovações
Melhorámos as aprovações de localização atribuídas a um utilizador ao incluir os grupos a que o utilizador pertence nos resultados da pesquisa.
As aprovações agora contêm informações sobre a execução do pipeline a que pertencem.
Por exemplo, a seguinte chamada https://dev.azure.com/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending GET REST API retorna
{
"count": 1,
"value":
[
{
"id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
"steps":
[],
"status": "pending",
"createdOn": "2023-11-09T10:54:37.977Z",
"lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
"executionOrder": "anyOrder",
"minRequiredApprovers": 1,
"blockedApprovers":
[],
"_links":
{
"self":
{
"href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
}
},
"pipeline":
{
"owner":
{
"_links":
{
"web":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
},
"self":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
}
},
"id": 73222930,
"name": "20231109.1"
},
"id": "4597",
"name": "FabrikamFiber"
}
}
]
}
Ignorar aprovações e verificações
Aprovações e verificações ajudam a proteger o acesso a recursos importantes, como conexões de serviço, repositórios ou pools de agentes. Um caso de uso comum é usar Aprovações e Verificações ao implantar na produção, e você deseja proteger a conexão de serviço ARM.
Digamos que você adicionou as seguintes verificações na conexão de serviço: uma verificação de Aprovação, uma verificação de Horário Comercial e uma verificação Invocar Função do Azure (para impor um atraso entre regiões diferentes).
Agora, imagine que você tenha que fazer uma implantação de hotfix. Você inicia uma execução de pipeline, mas ela não prossegue, aguarda a conclusão da maioria das verificações. Você não pode se dar ao luxo de esperar que as aprovações e verificações sejam concluídas.
Neste sprint, tornamos possível ignorar aprovações e verificações em execução, para que você possa concluir seu hotfix.
Você pode ignorar as aprovações em execução, o horário comercial, invocar a função do Azure e invocar verificações da API REST.
Ignorar uma aprovação.
Ignore a verificação do horário comercial.
Ignorar a verificação Invoke Azure Function. Ignore a verificação do horário comercial.
Quando uma verificação é ignorada, você pode vê-la no painel de verificações.
Você pode ignorar uma verificação somente se for um administrador do recurso no qual as verificações foram definidas.
Suporte para o servidor empresarial GitHub na verificação de modelo necessária
Os modelos são um mecanismo de segurança que permite controlar os estágios, trabalhos e etapas dos pipelines em sua organização.
A verificação Exigir modelo permite impor que um pipeline se estenda a partir de um conjunto de modelos aprovados antes de acessar um recurso protegido, como um pool de agentes ou conexão de serviço.
A partir deste sprint, você pode especificar modelos localizados nos repositórios do GitHub Enterprise Server.
Execute novamente invocar verificações de função do Azure
Imagine que você implanta seu sistema em vários estágios. Antes de implantar o segundo estágio, há uma verificação de Aprovação e uma verificação de Invocar Função do Azure que executa uma verificação de sanidade na parte já implantada do sistema.
Ao analisar a solicitação de aprovação, você percebe que a verificação de sanidade executada dois dias antes. Nesse cenário, você pode estar ciente de outra implantação que afetou o resultado da verificação de sanidade.
Com essa atualização, você pode executar novamente as verificações Invoke Azure Function e Invoke REST API. Essa funcionalidade está disponível apenas para verificações bem-sucedidas e sem tentativas.
Nota
Você pode executar novamente uma verificação somente se for um administrador do recurso no qual as verificações foram definidas.
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.
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.
Você também pode obter conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.