O documento propõe um modelo de governança para as instâncias do ServiceNow de uma empresa, com três instâncias (desenvolvimento, testes e produção) e processos para parametrizações, customizações, rastreabilidade de alterações e deploy contínuo entre os ambientes.
14. INSTÂNCIAS
TIPO EXEMPLO DE NOME AMBIENTE CARACTERÍSTICAS
non-
prod
https://capivaracompanydev.service
-now.com
Desenvolvimento
• Acesso exclusivo para desenvolvedores e administradores
• Onde ‘nascem’ os update sets
https://capivaracompanytest.servic
e-now.com
Testes
• Espaço onde donos e gestores de processo validam as
funcionalidades
• Donos e gestores de processo devem ter a funcionalidade
impersonate, garantindo a integridade dos testes
• Dados equalizados com a instância de produção, através de
clones periódicos (mensais ou trimestrais)
• Serve também como sandbox, é o ambiente ideal para provas de
conceito
prod
https://capivaracompany.service-
now.com
Produção
• É onde o rock 'n‘ roll acontece
• Deve ser possível rastrear e auditar ‘tudo’
• Só recebe update sets (customizações) que foram validados no
ambiente de testes
• Parametrizações podem ser feitas diretamente em produção
15. DESENVOLVIMENTO
exemplo de nome: https://capivaracompanydev.service-now.com
• Acesso exclusivo para desenvolvedores e administradores
• Onde ‘nasce’ o update set
16. TESTES
exemplo de nome: https://capivaracompanytest.service-now.com
• Espaço onde donos e gestores de processo validam as
funcionalidades
• Donos e gestores de processo devem ter a funcionalidade
impersonate, garantindo a integridade dos testes
17. TESTES
exemplo de nome: https://capivaracompanytest.service-now.com
• Dados equalizados com a instância de produção, através de clones
periódicos (mensais ou trimestrais)
• Serve também como sandbox, é o ambiente ideal para provas de
conceito [opinião pessoal]
18. PRODUÇÃO
exemplo de nome: https://capivaracompany.service-now.com
• É onde o rock 'n‘ roll acontece
• Deve ser possível rastrear e auditar ‘tudo’
19. PRODUÇÃO
exemplo de nome: https://capivaracompany.service-now.com
• Só recebe update sets (customizações) que foram validados no
ambiente de testes
• Parametrizações podem ser feitas diretamente em produção
21. PARAMETRIZAÇÕES E CUSTOMIZAÇÕES
• PARAMETRIZAR é a configuração através de atributos ou alterações
que não geram impacto estrutural
• Exemplos:
– Ativar ou desativar uma notificação
– Alterar as propriedades da Gestão de Incidentes
– Criar ou alterar uma homepage
22. PARAMETRIZAÇÕES E CUSTOMIZAÇÕES
• CUSTOMIZAR envolve alteração estrutural, pode afetar todos os
usuários e – o mais importante – costumam ter um alto impacto
• Exemplos:
– Inclusão de campos em uma tabela
– Criação ou alteração de scripts, workflows ou formulários
24. RASTREABILIDADE DAS ALTERAÇÕES
• A tabela Sys Audit* [sys_audit] armazena tudo que acontece nos
registros da plataforma, desde uma alteração de propriedade até a
exclusão de um registro, passando pelas alterações em tabelas e
formulários
* saiba mais sobre a tabela Sys Audit: http://bit.ly/333o0bz
25. RASTREABILIDADE DAS ALTERAÇÕES
• Principalmente nas customizações, é necessário ir além e criar uma
estrutura que permita a rastreabilidade completa, desde a solicitação
da alteração até o update set* instalado na instância de produção.
Sem esquecer, é claro, do registro da mudança**
*saiba mais sobre o update set: http://bit.ly/2Iz3C8Z
** saiba mais sobre o registro da mudança: http://bit.ly/39BGz9h
26. UPDATE SET: DEFINA UM PADRÃO DE NOME
• Algo que permita identificar a demanda (ID + descrição resumida)
• Seja fácil de vincular ao desenvolvedor
[FETR9999999] Melhorias no formulário para registro de
incidentes_ARA
27. RASTREABILIDADE DAS ALTERAÇÕES
Solicitação
[História, Item de
Catálogo, Feature,
Incidente, Tarefa, etc.]
Update set criado na
instância de
desenvolvimento
Validação do solicitante,
na instância de testes
Registro da mudança
[mudança padrão, criada
automaticamente]
Update set
instalado na
instância de
produção
Solicitação encerrada (vinculada ao
update set e ao registro da mudança)
29. CONTINUOUS DELIVERY
• Um pipeline para instalação do update set nas instâncias de Testes e
Produção facilita o trabalho do desenvolvedor / administrador e
garante a integridade do trabalho realizado
• Uma mudança padrão deve ser vinculada ao update set instalado na
instância de Produção
30. CONTINUOUS DELIVERY
• Há situações onde será necessário registrar uma mudança normal e
passar pelo CAB (Change Advisory Board)
• Exemplos:
– Mudança de versão
– Instalação de uma nova aplicação
– Mudanças que afetarão a operação dos processos
31. CONTINUOUS DELIVERY
• Por que promover o update set entre os três ambientes
(desenvolvimento => testes => produção)?
– Além do motivo óbvio (cada ambiente tem o seu propósito), a passagem do
update set da instância de desenvolvimento para testes é uma forma de
validar o processo (há o risco do update set estar incompleto)
32. CONTINUOUS DELIVERY
DEV
Update set pronto para testes
[instalação automática na instância]
Update set pronto para produção
[após validação do solicitante, a instalação é iniciada pelo
administrador e a mudança é registrada automaticamente]
TESTES
PRODUÇÃO
33. CONTINUOUS DELIVERY
IMPORTANTE
• Pode ocorrer dependência entre update sets, neste caso, a sequência
do deploy deve observar esse vínculo (é algo a ser evitado, mas pode
acontecer)