Azure Pipelines - Atualização da Sprint 230
Recursos
- As tarefas do Azure Pipelines usam o Nó 16
- Anunciando a aposentadoria de tarefas preteridas
- A tarefa AzureRmWebAppDeployment dá suporte à 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
- Executar novamente as verificações de função do Azure Invoke
As tarefas do Azure Pipelines usam o Nó 16
As tarefas no pipeline são executadas usando um executor, com Node.js usado na maioria dos casos. As tarefas do Azure Pipelines que utilizam um Nó como executor 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 para o macOS no silício da Apple. Os agentes executados no 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 retiradas em 31 de janeiro de 2024. Para ajudá-lo a identificar pipelines que estão usando tarefas preteridas, os pipelines mostrarão avisos se essa tarefa for usada. Atualizamos a Referência de Tarefa para transmitir claramente o status de depreciação e a data de aposentadoria.
As seguintes tarefas foram preteridas e começarão a emitir avisos:
- AppCenterDistributeV1,
- AppCenterDistributeV2
- AzureMonitorV0
- ChefKnifeV1
- ChefV1
- CondaEnvironmentV1
- 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 dá suporte à autenticação de ID do Microsoft Entra
As tarefas AzureRmWebAppDeploymentV3 e AzureRmWebAppDeployment@4 foram atualizadas para oferecer suporte ao Serviço de Aplicativo com 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
Melhoramos a localização das aprovações atribuídas a um usuário incluindo os grupos aos quais o usuário 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 de Chamada de Função do Azure (para impor um atraso entre regiões diferentes).
Agora, imagine que você precisa fazer uma implantação de hotfix. Você inicia uma execução de pipeline, mas ele não prossegue, ele espera que a maioria das verificações sejam concluídas. Você não pode se dar ao luxo de esperar que as aprovações e verificações sejam concluídas.
Nesta sprint, tornamos possível ignorar as aprovações e verificações em execução, para que você possa concluir o hotfix.
Você pode ignorar as verificações de Aprovações, Horário Comercial, Invocar Função do Azure e Invocar a API REST.
Ignorar uma aprovação.
Ignorar verificação do horário comercial.
Ignorar a verificação de função do Azure Invoke. Ignorar verificação do horário comercial.
Quando uma verificação é ignorada, você pode vê-la no painel de verificações.
Você só poderá ignorar uma verificação se for um Administrador do recurso no qual as verificações foram definidas.
Suporte para o servidor corporativo GitHub na verificação de modelo necessária
Os modelos são um mecanismo de segurança que permite controlar os estágios, os trabalhos e as etapas dos pipelines em sua organização.
A verificação Exigir modelo permite impor que um pipeline se estenda 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 dessa sprint, você pode especificar modelos localizados nos repositórios do GitHub Enterprise Server.
Executar novamente as 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 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 foi 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.
Observação
Você só poderá executar novamente uma verificação se for um Administrador do recurso no qual as verificações foram definidas.
Próximas etapas
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.
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 receber conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.