As sugestões apresentadas aqui representam o básico para uma boa governança das instâncias. Se em sua empresa é comum realizarem customizações diretamente na instância de produção ou não há rastreabilidade entre os update sets, lamento dizer, mas vocês podem ter um grande problema em breve (se é que ainda não tiveram). Espero que as dicas sejam úteis.

1. SERVICENOW
modelo para governança das instâncias
[proposta, v1.0]
Alessandro Almeida | medium.com/@alessandro1982

2. SOBRE ESTE MATERIAL
• As sugestões apresentadas aqui representam o
básico para uma boa governança das instâncias

3. SOBRE ESTE MATERIAL
• Se em sua empresa é comum realizarem
customizações diretamente na instância de
produção ou não há rastreabilidade entre os update
sets, lamento dizer, mas vocês podem ter um
grande problema em breve (se é que ainda não
tiveram)
• Espero que as dicas sejam úteis

4. SOBRE AS INSTÂNCIAS

5. O ideal é que a empresa tenha, no
mínimo, três instâncias...

6. INSTÂNCIAS
PROD
NON-PROD
https://<nome da sua empresa>.service-now.com
https://<nome da sua empresa>dev.service-now.com https://<nome da sua empresa>test.service-now.com

7. 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.service-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

8. PARAMETRIZAÇÕES E
CUSTOMIZAÇÕES

9. 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

10. 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

11. RASTREABILIDADE DAS ALTERAÇÕES

12. 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: https://goo.gl/dki57S

13. 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: https://goo.gl/GWbXdH
** saiba mais sobre o registro da mudança: https://goo.gl/d3gu4T

14. 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 automaticamente
(vinculada ao update set e ao registro da
mudança)

15. CONTINUOUS DELIVERY

16. 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

17. 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

18. 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)

19. 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

20. 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)

21. PRÓXIMOS PASSOS
[proposta, v2.0]

22. PRÓXIMOS PASSOS
• As propostas apresentadas aqui representam o básico para
uma boa governança das instâncias
• Se o arroz com feijão estiver sendo feito com maestria, os
próximos passos podem ser:
– Product Owner definir o momento que o update set será
instalado em produção
– Criação (automática) de Release Notes
– Integração com o ATF (Automated Test Framework)*
* saiba mais sobre o ATF: https://goo.gl/5dhuiK

23. DÚVIDAS?
Crédito da imagem: I doubt my mission for the Dark side - sir..., por @kalexanderson

24. MUITO OBRIGADO!
alessandro.almeida@uol.com.br | 11 9 9229-2043
slideshare.net/alessandroalmeida
linkedin.com/in/alessandroalmeida
medium.com/@alessandro1982
Praia do Jacaré – João Pessoa - PB