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

  • Versão de lançamento: Zurich
  • Atualizado 31 de jul. de 2025
  • 6 min. de leitura
  • Crie solicitações de mudança mesmo com erros na recuperação de dados do DevOps.

    Visão geral da criação de solicitação de mudança

    Nota:
    A criação de solicitação de mudança com erros de recuperação de dados do DevOps é compatível somente com Azure DevOps, GitHub Actions, GitLab, Jenkins E Pipelines de chicote.

    Você pode criar uma solicitação de mudança com ou sem erros na recuperação de dados do DevOps. Esta funcionalidade pode ser controlada pelo Habilite a criação de solicitação de mudança mesmo com erros na recuperação de dados do DevOps propriedade. . Habilite a criação de solicitação de mudança mesmo com erros na recuperação de dados do DevOps Se a propriedade estiver habilitada e ocorrer um erro na recuperação de dados do DevOps, como itens de trabalho, confirmações, resumos de testes ou resumos de segurança, a solicitação de mudança correspondente ainda será criada. Os dados que podem ser recuperados ainda serão associados à solicitação de mudança. Para os dados que não podem ser recuperados, o motivo do erro será notificado para o usuário no console de terceiros e as mesmas informações também serão adicionadas ao Comentários de mudança Campo no registro de Execução de etapa e a mudança Anotações de trabalho .

    . Habilite a criação de solicitação de mudança mesmo com erros na recuperação de dados do DevOps a propriedade não está habilitada, uma solicitação de mudança é criada somente quando não há erro em nenhuma etapa de uma execução de pipeline. Quando ocorre um erro, o pipeline é anulado e o motivo do erro é adicionado aos eventos de entrada Processando detalhes e o mesmo é notificado ao usuário no console de terceiros.

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

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

    Para solicitações de mudança criadas com erros de recuperação de dados do DevOps, o. is_change_with_partial_dataa entrada de política está definida como Verdadeiro 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 depois de verificar manualmente os dados de DevOps nela. No subfluxo DevOps Coletar dados da política de mudança, o. Is change with partial dataA ação 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 do DevOps

    Quando uma solicitação de mudança é 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 Amarelo. IU de pipeline exibindo cartão de fase de erro em amarelo para mudança com erros

    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 do DevOps da ServiceNow receberá e processará os eventos de pipeline de versão antes de criar eventos de pipeline. Nesse caso, a mudança será criada com os dados de DevOps do pipeline de compilação, mesmo que haja um erro ao recuperar alguns dos dados. Você pode observar esse comportamento mesmo no Habilite a criação de solicitação de mudança mesmo com erros na recuperação de dados do DevOps a propriedade está habilitada. . is_change_with_partial_dataNeste caso, a entrada de política será falsa, e o processo de aprovação será aplicado da maneira definida nos fluxos de aprovação, ao contrário de sempre manual, no caso de solicitações de mudança com erros de recuperação de dados do DevOps.

    Tempo limite do retorno de chamada

    Se um evento de entrada entrar no estado Aguardando durante uma execução de pipeline, o sistema tentará processar a mudança até o valor de tempo limite em sn_devops.change _request_callback_timeouta propriedade foi excedida, depois que o pipeline é 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 de DevOps para aumentar o valor do tempo limite no sn_devops.change_request_callback_timeoutpropriedade. O valor padrão desta propriedade é 120 minutos e o valor mínimo é 60 minutos. Para obter mais informações, consulte Propriedades de Velocidade de mudança para DevOps.

    Nota:
    Se você estiver usando a ação personalizada de automação de mudanças do GitHub, a ação personalizada de automação de mudanças do Docker do GitLab ou a ação personalizada de automação de mudanças do Docker do Harish no pipeline correspondente para criar solicitações de mudança, será necessário fornecer intervalo Na ação personalizada, que permite que o GitHub, GitLab ou Harness pesquisem o ServiceNow DevOps para o status da mudança. Quando a mudança atinge um estado apropriado na ServiceNow dentro do intervalo especificado, o status apropriado, dependendo do resultado da mudança, será enviado para o pipeline GitHub, GitLab ou Harness, que retomará ou anulará o pipeline. Consulte Ações personalizadas do ServiceNow DevOps do GitHub Marketplace e. Implemente ações personalizadas para pipelines usando a imagem genérica do contêiner do Docker para obter mais detalhes. Portanto, quando seu pipeline com a ação personalizada de mudança for executado e se alguma notificação de etapa do GitHub, GitLab ou Harness não atingir o DevOps da ServiceNow, a associação de retorno de chamada, execução de etapa e execução de tarefa não acontecerá no DevOps da ServiceNow. 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, GitHub, GitLab ou Harness pesquisarão a ServiceNow para o status da mudança até que o tempo especificado no intervalo seja atingido. Se o intervalo for aprovado e também o tempo limite especificado em sn_devops.change_request_callback_timeoutA propriedade foi atingida, o ServiceNow DevOps não encerrará seu pipeline como deveria, mas o deixará para o tempo limite padrão definido na etapa GitHub, GitLab ou Harness que eventualmente encerrará o pipeline. A informação importante neste cenário é que o ServiceNow DevOps não poderá notificar o usuário de que os eventos de etapa não atingiram o ServiceNow DevOps nos logs do console GitHub, GitLab ou Harness.

    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 esperar indefinidamente) e o motivo do erro é adicionado ao evento de entrada Processando detalhes 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, habilite o. Habilite a criação de solicitação de mudança mesmo com erros na recuperação de dados do DevOps propriedade. Isso fornece valor aos aprovadores de mudança e às equipes de AppDev, obtendo as mudanças criadas automaticamente com evidências de DevOps coletadas e devidamente notificadas nas anotações de trabalho de solicitação de mudança e logs de console de terceiros com erros ou dados que podem estar ausentes.

    Limitação

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