Criação de solicitação de mudança com erros de recuperação de dados do DevOps

Crie solicitações de mudança mesmo com erros na recuperação de dados do DevOps.

Criação de mudança com visão geral de dados do DevOps

Nota:

A criação de solicitação de mudança com erros de recuperação de dados do DevOps é compatível somente com os pipelines Azure DevOps, GitHub Actions, GitLabe Jenkins.

Você pode criar uma solicitação de mudança com ou sem erros na recuperação de dados do DevOps. Essa funcionalidade pode ser controlada pela propriedade Habilitar criação de solicitação de mudança mesmo com erros na recuperação de dados do DevOps. Quando a propriedade Habilitar criação de solicitação de mudança mesmo com erros na recuperação de dados do DevOps está habilitada e ocorre um erro na recuperação de dados do DevOps, como itens de trabalho, confirmações, resumos de teste ou resumos de segurança, a solicitação de mudança correspondente ainda é criada. Os dados que podem ser recuperados ainda estarão associados à solicitação de mudança. Para os dados que não podem ser recuperados, o motivo do erro será notificado ao usuário no console de terceiros e as mesmas informações também serão adicionadas ao campo Comentários de mudança no registro de execução da etapa e nas anotaçõesde trabalho de mudança .

Se a propriedade Habilitar criação de solicitação de mudança mesmo com erros na recuperação de dados do DevOps não estiver habilitada, uma solicitação de mudança será criada somente quando não houver erro em nenhuma etapa de uma execução de pipeline. Quando ocorre um erro, o pipeline é anulado e o motivo do erro é adicionado ao campo Detalhes de processamento do evento de entrada, e o mesmo é notificado ao usuário no console de terceiros.

Para obter mais informações, consulte Propriedades Velocidade de mudança para DevOps.

Aprovação de solicitações de mudança com erros de recuperação de dados de DevOps

Para solicitações de mudança criadas com erros de recuperação de dados do DevOps, a entrada de política is_change_with_partial_data é definida como Verdadeira para todas as políticas de aprovação de mudança. Somente uma decisão de aprovação de mudança manual é aplicada a essas mudanças para que você possa aprovar ou rejeitar a mudança após verificar manualmente os dados de DevOps nela. No subfluxo Coletar dados da política de mudança de DevOps, a ação Is change with partial data determina se uma mudança é criada com erros de recuperação de dados do DevOps ou não.

IU de pipeline para solicitações de mudança com erros de recuperação de dados de DevOps

Quando uma solicitação de mudança for criada com erros de recuperação de dados do DevOps, o cartão que especifica a fase em que ocorreu o erro será exibido na cor amarela.

Nota:

Se o pipeline de compilação (IC) estiver configurado para acionar um pipeline de versão (CD) e uma mudança for criada no pipeline de versão, os dados serão coletados do pipeline de compilação e associados à solicitação de mudança. Pode haver uma situação em que a Velocidade de mudança para DevOps da ServiceNow receberá e processará os eventos do pipeline de versão antes dos eventos de pipeline de compilação. Nesse caso, a mudança será criada com dados de DevOps do pipeline de compilação, mesmo que haja um erro na recuperação de alguns dados. Você pode observar esse comportamento mesmo que a propriedade Habilitar criação de solicitação de mudança mesmo com erros na recuperação de dados do DevOps esteja habilitada. Além disso, a entrada de política is_change_with_partial_data será falsa neste caso e o processo de aprovação será aplicado da forma como é definido nos fluxos de aprovação, ao contrário de sempre manual, em caso de solicitações de mudança com erros de recuperação de dados do DevOps.

Tempo limite de retorno de chamada

Se um evento de entrada entrar no estado de espera durante uma execução de pipeline, o sistema tentará processar a mudança até que o valor de tempo limite na propriedade sn_devops.change _request_callback_timeout seja excedido, depois que o pipeline for anulado. O motivo do erro é exibido nos logs do console da ferramenta de terceiros. Quando um pipeline é cancelado devido ao tempo limite de retorno de chamada, as mesmas informações são adicionadas ao registro de retorno de chamada da execução da etapa correspondente. Você pode entrar em contato com o administrador do DevOps para aumentar o valor do tempo limite na propriedade sn_devops.change_request_callback_timeout. O valor padrão desta propriedade é 120 minutos e o valor mínimo é 60 minutos. Para obter mais informações, consulte Propriedades Velocidade de mudança para DevOps.

Nota:

Se você estiver usando a ação personalizada de automação de mudança do GitHub ou a ação personalizada de automação de mudança do GitLab Docker no pipeline correspondente para criar solicitações de mudança, será necessário fornecer o intervalo na ação personalizada, o que permite que o GitHub ou o GitLab pesquise o status da mudança no ServiceNow DevOps. Quando a mudança atingir um estado apropriado na ServiceNow dentro do intervalo especificado, o status apropriado, dependendo do resultado da mudança, será enviado para o pipeline do GitHub ou GitLab, que retomará ou anulará o pipeline. Consulte Ações personalizadas do ServiceNow DevOps do mercado do GitHub e ServiceNow ações personalizadas para GitLab para obter mais detalhes. Portanto, quando o pipeline com a ação personalizada de mudança for executado e se qualquer notificação de etapa do GitHub ou GitLab não tiver atingido o ServiceNow DevOps, a associação de retorno de chamada, execução de etapa e execução de tarefa não acontecerá no ServiceNow DevOps. Como a associação não está disponível, a mudança não será criada e o ServiceNow DevOps aguardará até que a associação esteja em vigor. Ao mesmo tempo, o GitHub ou o GitLab pesquisará o status de mudança na ServiceNow até que o tempo especificado no intervalo seja atingido. Se o intervalo for aprovado e também o tempo limite especificado na propriedade sn_devops.change_request_callback_timeout for atingido, o ServiceNow DevOps não encerrará o pipeline como deveria, mas o deixará para o tempo limite padrão definido na etapa do GitHub ou GitLab que encerrará o pipeline. As informações importantes neste cenário são que a ServiceNow DevOps não poderá notificar o usuário de que os eventos de etapa não alcançaram a ServiceNow DevOps nos logs do console do GitHub ou do GitLab.

Upgrade

Após o upgrade, a propriedade será definida como falsa por padrão. Seu processo de mudança atual funcionará como está, mas a única diferença que você verá é que, quando ocorre um erro na recuperação de dados do DevOps, o pipeline é anulado (em vez de aguardar indefinidamente) e o motivo do erro é adicionado no evento de entrada Campo de detalhes de processamento e o mesmo é notificado ao usuário no console de terceiros. Se você quiser criar solicitações de mudança com erros na recuperação de dados do DevOps e também não falhar no pipeline, poderá habilitar a propriedade Habilitar criação de solicitação de mudança mesmo com erros na recuperação de dados do DevOps. Isso agrega valor aos aprovadores de mudança e às equipes do AppDev, obtendo as mudanças criadas automaticamente com evidências de DevOps que são coletadas e notificadas corretamente nas anotações de trabalho da solicitação de mudança e nos logs do console de terceiros com erros ou dados que podem estar ausentes.

Limitação

Se a propriedade Habilitar criação de solicitação de mudança mesmo com erros na recuperação de dados do DevOps estiver habilitada e a etapa do pacote de artefatos do ADO no pipeline resultar em erro, a mudança será criada sem artefatos do ADO associados a ela, mas o erro correspondente não será notificado em Anotações de trabalho, comentários de mudança de execução de etapa ou no log do console do ADO.