Pipelines e implantações fluxo de trabalho versão 24.1.2

  • Versão de lançamento: Zurich
  • Atualizado 31 de jul. de 2025
  • 4 min. de leitura
  • À medida que você gerencia solicitações de implantação de apps em Central de gestão do App Engine( AEMC), use este fluxo de trabalho para entender como as implantações de aplicações se movem pelos pipelines na versão 24,1.2, lançada em novembro de 2023.

    Figura 1. Fluxo de trabalho do Pipelines e implantações
    Infográfico que descreve um fluxo de trabalho de implantações e pipelines padrão. Para obter uma descrição de texto, consulte as etapas do fluxo de trabalho a seguir.
    Neste fluxo de trabalho:
    1. O solicitante seleciona Enviar em App Engine Studio, Creator Studio, ou ServiceNow Studio, que aciona o fluxo principal.
    2. O sistema executa as seguintes tarefas nos bastidores:
      1. Valida a carga.
      2. Busca o manifesto do app do sys_app registro na instância de origem.
      3. Cria uma solicitação de implantação na instância do controlador.
      4. Envia um e-mail da instância do controlador para notificar o solicitante de que a solicitação foi criada.
      5. Publica a aplicação no Repositório de aplicações.
    3. O sistema executa ações diferentes dependendo se há erros ou não durante a publicação.
      1. Se houver erros na publicação do app e a gravidade do erro for Erro , em seguida, o sistema cria e aguarda a aprovação do registro atualizado.
      2. Se não houver erros, ou se houver erros, mas a gravidade do erro não for Erro , Em seguida, o sistema pesquisa o próximo ambiente no registro de pipeline.
        1. Se o próximo ambiente não existir, o sistema enviará um e-mail da instância do controlador para notificar o solicitante de que a solicitação foi encerrada e que o app foi publicado na instância de destino. Esta ação encerra o fluxo de trabalho.
        2. Se o próximo ambiente existir, o sistema atualizará o. Ambiente de destino campo na solicitação de implantação para o próximo ambiente. Em seguida, o sistema cria e aguarda a aprovação do registro atualizado.
    4. O sistema executa ações diferentes dependendo se o novo registro foi aprovado.
      1. Se o registro não for aprovado, o sistema enviará um e-mail da instância do controlador para notificar o solicitante de que a solicitação não foi aprovada e que a solicitação foi encerrada. Esta ação encerra o fluxo de trabalho.
      2. Se o registro for aprovado, e se o. Ambiente de destino é Teste , em seguida, o sistema executa as seguintes ações:
        1. Implanta o app no ambiente de teste, se o app não estiver disponível lá.
        2. Executa a Verificação de instância de definições de app com escopo e todos os outros pacotes na tabela Pacotes de verificação [[scan_suites]] na instância de teste.
          Nota:
          A tabela Pacotes de verificação deve ser preenchida na instância do controlador.
        3. Executa o pacote ATF (Automated Test Framework) do pacote de testes de implantação de aplicações e todos os pacotes na tabela Scan Suites [scan_suites] na instância de teste.
        4. Grava os resultados da verificação de instância e do teste ATF na tabela de resultados do ambiente de implantação e no fluxo de atividades na solicitação de implantação.
        5. Retorna o fluxo de trabalho para a etapa 3, onde verifica se há erros.
      3. Se o registro for aprovado, e o. Ambiente de destino é Produção , O app inicia o processo de implantação agendado com a integração da Gestão de mudanças.
        1. . App Engineo administrador seleciona Aprovar e criar solicitação de mudança . Uma solicitação de mudança é criada com base no modelo escolhido durante a Configuração assistida.
        2. O sistema executa ações diferentes dependendo se o app está registrado como um item de configuração (IC).
          1. Se o app não estiver registrado como IC, o sistema registrará o app como IC e adicionará o IC afetado à solicitação de mudança.
          2. Se o app estiver registrado como IC, o sistema adicionará o IC afetado à solicitação de mudança.
        3. O sistema executa ações diferentes, dependendo se a solicitação de mudança está no Implementar estado.
          1. Se o estado da solicitação de mudança não for Implementar e o estado não é Avaliar ou Autorize , O sistema envia um e-mail da instância do Controlador para notificar o solicitante de que sua solicitação não foi aprovada e foi encerrada. Isso encerra o fluxo de trabalho.
          2. Se o estado da solicitação de mudança não for Implementar e o estado é Avaliar ou Autorize , o sistema aguarda até que o estado seja Implementar .
          3. Se a solicitação de mudança estiver em Implementar estado, o sistema cria uma tarefa de mudança para programar a implantação da aplicação.
        4. Se o estado da solicitação de mudança for Implementar e o. Data de início planejada não é Agora ou, no passado, o sistema espera que essas duas condições sejam verdadeiras
        5. Se o estado da solicitação de mudança for Implementar e o. Data de início planejada é Agora ou no passado, mas a solicitação é Rejeitado ou Cancelado , O sistema envia um e-mail da instância do Controlador para notificar o solicitante de que sua solicitação não foi aprovada e foi encerrada. Isso encerra o fluxo de trabalho.
        6. Se o estado da solicitação de mudança for Implementar e o. Data de início planejada é Agora Ou, no passado, o sistema agenda a implantação do app para produção com base em Data de início planejada na solicitação de mudança. O sistema fecha a tarefa de mudança e, em seguida, fecha a solicitação de implantação. Isso encerra o fluxo de trabalho.
      4. Se o registro for aprovado, e o. Ambiente de destino não é Teste ou Produção , em seguida, o sistema implanta o app no ambiente de destino, se ele não estiver disponível lá.

        O fluxo de trabalho reinicia quando um solicitante seleciona Enviar novamente em App Engine Studio, Creator Studio, ou ServiceNow Studio.