Implantar seu app

  • Versão de lançamento: Xanadu
  • Atualizado 1 de ago. de 2024
  • 5 min. de leitura
  • Depois que a aplicação é criada e validada, ela precisa ser movida para o ambiente de produção. As aplicações podem ser movidas por meio de um repositório de aplicações ou usando conjuntos de atualizações. As aplicações devem ser implantadas para testar ambientes antes de passar para a produção.

    Repositório de aplicações (repositório de aplicações)

    A publicação de uma aplicação no repositório de aplicações disponibiliza essa versão da aplicação para todas as instâncias da ServiceNow de uma organização. Use o repositório de aplicações para implantar uma aplicação em instâncias de CQ/Teste (para testes) e, por fim, em instâncias de produção (Prod).

    Implantar apps por meio do repositório de aplicações

    Para obter mais informações, consulte Publicação de uma aplicação no repositório de aplicações, Instalação de uma aplicação.

    Conjuntos de atualizações

    Se o repositório de aplicações não puder ser usado para implantar aplicações, use Conjuntos de atualizações. O diagrama mostra o ciclo de vida de prática recomendada de um conjunto de atualizações para implantar uma personalização da instância de desenvolvimento na instância de teste.

    Implantar apps usando conjuntos de atualizações

    Práticas que levam a um processo de desenvolvimento e versão de qualidade:

    • Sempre mova as personalizações da parte inferior da pilha para cima.
      • Garante que as instâncias de pilha para baixo correspondam às instâncias de pilha para cima.
      • As personalizações introduzidas no meio da pilha podem ser substituídas por pushes futuros da pilha para baixo.
      • Os cenários comuns incluem:
        • Corrige a necessidade em teste ou produção - sempre os envie do desenvolvimento para cima
        • Personalização comum do administrador de produção, como listas de seleção - sempre envie atualizações de desenvolvimento para cima
    • Sempre revise as atualizações contidas em um conjunto de atualizações antes de transferir.
      • Procure atualizações associadas a outros esforços de desenvolvimento e atualizações associadas a testes.
      • Observe as propriedades do sistema e as mudanças nos endpoints de integração. Por exemplo: envio de mudança sys_properties que direciona todos os e-mails para a conta de e-mail de teste
      • Mova as atualizações para um conjunto de atualizações de “scrap” em vez de excluir a atualização.
    • Sempre teste após o envio para garantir que todas as personalizações desejadas sejam capturadas e aplicadas conforme o esperado.
    • Em situações com várias versões paralelas, garanta a comunicação e a coordenação entre as equipes de desenvolvimento.
    • Evite fazer experiências na instância de desenvolvimento, pois as personalizações podem ser capturadas acidentalmente e migradas por outros membros da equipe.
    • Não capture o desenvolvimento no conjunto de atualizações padrão.

    Liste todos os números de história do usuário com uma descrição resumida no campo Descrição de um conjunto de atualizações. Inclua todas as etapas manuais necessárias para implantar o conjunto de atualizações.

    Alguns exemplos típicos de etapas manuais necessárias para uma implantação que não são capturadas em um conjunto de atualizações:

    • Ativação do plug-in.
    • Transferência de tabelas que não são rastreadas no conjunto de atualizações (normalmente, começando com "x_" ou "u_").
    • Criação de índices de banco de dados nas tabelas. A criação do índice não é rastreada por meio do conjunto de atualizações e precisa ser feita manualmente.

    Gestão de conjunto de atualizações

    Certifique-se de que o conjunto de atualizações correto esteja selecionado ao trabalhar em uma história ou um defeito e verifique os registros no conjunto de atualizações diariamente.

    Não mova manualmente registros sys_update_xml entre conjuntos de atualizações. A única exceção é mover um registro para o conjunto de atualizações padrão.

    Os conjuntos de atualizações capturam informações de configuração, mas não dados de tarefa ou processo. Por exemplo, os Conjuntos de atualizações rastreiam definições de item do Catálogo de serviços e dados de configuração relacionados, como variáveis e opções de variáveis. No entanto, os pedidos (solicitações, itens, tarefas de catálogo) feitos em teste não são rastreados por Conjuntos de atualizações.

    Esteja ciente do que o conjunto de atualizações deve e não deve fazer:

    • Para remover um registro sys_update_xml específico do conjunto de atualizações atual, mova o registro para o conjunto de atualizações padrão e preencha o campo sys_update_set.comments do registro com o motivo para mover o registro para o conjunto de atualizações padrão.
    • Nunca mova registros de personalização de um conjunto de atualizações para outro.
    • Nunca exclua um conjunto de atualizações a menos que o conjunto de atualizações tenha sido mesclado com sucesso em um novo conjunto de atualizações.
    • Sempre use extrações de dados ou Conjuntos para importação para mover dados de uma instância para outra (e não Conjuntos de atualizações).

    Lote de conjunto de atualizações

    Conjuntos de atualizações em lote para visualizar e confirmar conjuntos de atualizações em massa.

    Lidar com vários conjuntos de atualizações pode levar a problemas, incluindo a confirmação de conjuntos de atualizações na ordem errada ou a omissão inadvertida de um ou mais conjuntos. Evite esses problemas agrupando Conjuntos de atualizações concluídos em um lote.

    O sistema organiza os lotes de conjunto de atualizações em uma hierarquia. Um conjunto de atualizações pode atuar como primário para vários conjuntos de atualizações secundários. Um determinado conjunto pode ser secundário e primário, permitindo hierarquias de vários níveis. Um conjunto de atualizações no nível superior da hierarquia atua como o conjunto de atualizações base.

    A visualização ou confirmação do Conjunto de Atualizações de base visualiza ou confirma o lote inteiro. O sistema determina a ordem de processamento e verifica se há colisões com base nas datas em que as mudanças foram registradas e em sua ancestralidade sequencial. Seus ancestrais são as instâncias específicas nas quais ocorreram as mudanças nos conjuntos de atualizações.

    O lote de conjunto de atualizações pode ser aplicado a versões, em que um conjunto de atualizações primário vazio é criado para a versão e os conjuntos de atualizações reais são incluídos na versão como secundários.

    As vantagens de usar o lote de conjunto de atualizações são:

    • Os conjuntos de atualizações individuais podem ser removidos da versão no último momento.
    • O envio em lote é semelhante à mesclagem, exceto que o envio em lote permite que as atualizações sejam removidas.
    • Os conjuntos de atualizações em lote são fáceis de implantar. Somente o conjunto de atualizações primário precisa ser processado.

    Para obter mais informações, consulte Conjuntos de atualizações do sistema.

    O que fazer a seguir

    Agora que o app foi implantado, pense em como melhorá-lo e aprimorá-lo. Aqui estão algumas sugestões para determinar para onde ir em seguida:

    • As pessoas que usam a aplicação diariamente serão a melhor fonte de feedback. Fale com eles sobre quais novos recursos ou mudanças eles gostariam de ver.
    • Determine se fluxos de processo relacionados adicionais podem ser automatizados por meio do Flow Designer.
    • Determine se os novos spokes do IntegrationHub podem ser aproveitados para novas integrações.