1.

Planejamento da Sprint

Cada cliente tende a definir regras para o modelo de trabalho em conjunto com a Alpar, alinhar as operações com a utilização do SCRUM, e na Afya as Sprints foram definidas
para ser em formato quinzenal.

Com o cenário quinzenal foi criado um calendário da vida útil de uma sprint, detalhando cada cerimônia na timeline. Importante reforçar que os deploy deverão seguir o ciclo
de vida da sprint para subidas para os ambientes.

2. Controle de Update set

Antes de entrar nas regras é importante entendermos o que é um update set e como a Servicenow faz o controle.

2.1. O que é update set?

Update set é um pacote de alteração que são trigados de forma automática pela Servicenow com base em atributo das tabelas chamado update_synch. Cada registro de
alteração dentro de um update set não passa por verificação de alteração para mapeamento dos itens que foram alterados, ou seja, quando é alterado qualquer item do
registro monitorado é realizado o save dentro do update set do registro inteiro.

Um exemplo disso é uma alteração realizada em um campo de uma tabela. Se realizarmos a alteração do label de um registro de Usuário para User, será realizado o save do
registro inteiro em um pacote XML referente ao registro atualizado.

2.2. Como a Servicenow controla os update set?

Basicamente a Servicenow identifica um registro com base no campo chamado sys_id, trata-se de um valor hexadecimal de 32 caracteres. Como os pacotes são trasladados
entre instâncias, o sys_id de origem é gravado no campo chamado origin_sys_id. Com base neste campo é possível identificar qual ambiente foi gerado o update set e se ele
seguiu a sequência correta de deploy até a instância de produção.

Por regras gerais é aplicado uma verificação no update sets com status complete, com origin_sys_id que ainda não esteja no ambiente e que não faça parte de um batch base
em andamento. Se todas essas regras forem atendidas, o pacote poderá ser transportado para a instância de solicitação.

2.3. Sprint

Para facilitar, iremos definir os papéis de cada ator durante a sprint em andamento e como deverá ser realizado os controles dos update set para facilitar e mitigar possíveis
problemas de conflito em transporte e backups de clones.

2.3.1.Líder Técnico

O LT é o responsável por controlar as tarefas e qualidade da equipe que estiver abaixo dele. Junto com a equipe, deverá ser responsável por obrigar o seguimento das regras
de nomenclatura e controle de update.

Cada sprint de cada frente deverá contar com um update set que servirá de batch base para os desenvolvimentos realizados durante a sprint. É papel do LT criar e acompanhar
a saúde do batch base durante o andamento da sprint.

O nome do update set da Sprint deverá seguir o seguinte padrão:

• [Empresa][Escopo][Projeto][Sprint]

Exemplo de nome de update set:

• [ALPAR][Global][ITSM][Sprint 1]
• [ALPAR][CSA][Autosserviço][Sprint 1]
• [ALPAR][RH][DP][Sprint 1]

O update set da sprint deverá ficar com o status In Progress até a finalização da sprint, momento que será transportado para a instância de homologação via Update Source
para o cenário de escopo Global. Para aplicação deverá ser alinhado o deploy para o Github da aplicação.

Não será permitido transporte de Update Sets ou massa de dados via XML. Estes cenários acabam por pular regras de validação padrão da Servicenow.

Não será aplicado em produção nenhum update set que esteja sem o field origin_sys_id no ambiente de desenvolvimento, com exceção o batch base de controle do produto
final. Este campo identifica o update set no ambiente de origem, no ambiente que ele foi criado.

2.3.2.Desenvolvedores

Deverão se atentar a nomenclatura dos updates sets e SEMPRE preencher o campo parent relacionado o Batch Base da sprint em andamento. Update set não inseridos no
Batch Base da sprint não serão aplicados em Homologação e, consecutivamente, deixarão de ser transportados para a instância de produção. Não serão realizados commits de
updates sets fora do batch base da sprint, para aplicações.

A instância de produção receberá somente itens de update set que estejam aplicados em Homologação.

V2.0 26/02/2022
Os updates sets da User Story devem ser nomeados da seguinte forma:

• [Empresa][Escopo][Projeto][User Story] – Breve descrição

Exemplo de nome de update set:

• [ALPAR][Global][ITSM][STRY0203349] – Portal e base de conhecimento

Obrigatoriamente toda story deverá contar com um update set dela, independente de quantas tarefas exista dentro dela.

Abaixo está representado a sequência de deploy entre ambientes, seguindo as regras de controle descritas.

2.4. Emergencial

Para casos de correção de bugs que deverão ser aplicados de forma emergencial, deverá estar descrito no update set que se trata de um item com essa característica. Itens de
correções emergencial devem ser nomeados da seguinte forma.

• [Empresa][Escopo][Projeto][User Story][Emergencial]

Leia-se emergencial somente bugs que atrapalham regras de negócio ou usabilidade com criticidade Alta, ou seja, o que pode gerar impacto financeiro ou de estrutural do
sistema para o cliente.

Para deploy emergencial é o único tipo de update set que poderá ser aplicado fora de batch base e sob demanda.

3. Aplicações

Não deverá ser aplicado NENHUM update set em nenhum ambiente por fora do Github ou versão da aplicação. Esse tipo de ação acaba dessincronizando os controles dos
itens pela aplicação e para corrigir, somente deletando toda a aplicação e instalando novamente nos ambientes que tiveram a alteração manual ou por update set.

Portanto está PROIBIDO subidas de update set para instâncias de Homologação e Produção com o escopo diferente do Global.

3.1. Deploy Branch

O desenvolvimento das aplicações deverá ocorrer em Branches de desenvolvimento, sendo que cada feature deverá estar dentro do update set já mencionado. Não serão
commitado itens que estejam fora dos update set nomeados conforme o padrão. Ao utilizar o update set criado para o usuário acaba ficando difícil rastrear as modificações
que devem ou não ser commitadas, impossibilitando o controle de bugs.

Após o a finalização do desenvolvimento e commit dos updates set da Sprint na branch. Ao finalizar o desenvolvimento do pacote como todo, deverá ser realizado o merge na
branch master. Esse processo deverá ocorrer de acordo com a documentação da Servicenow.

Documentação Merge

3.2. Emergencial

Para changes emergenciais de aplicações, o desenvolvedor deverá alinhar com o LT do Cliente um melhor cenário para que seja criado um escopo isolado para a alteração de
correção seja executada sem que haja quaisquer interferências nos itens em desenvolvimento pelas equipes.

O Desenvolvedor e LT da frente não deverão agir sozinhos, com risco de perda de desenvolvimento realizado por outros membros da equipe.

4. Nomenclatura
• Para os sistemas operacionais os caracteres <>:\/ são identificados como caracteres especiais. Em casos que o desenvolvedor utiliza o plugin disponível para VSCode
para desenvolvimento, esse tipo de nomenclatura gera erros. Para evitar esse tipo de problema, itens como Workflow, Flow, Script Include, Client Script e etc deverão
ser nomeados como ALP – <NOME DO ITEM>
• O names dos workflows e flows são gerados com base no labels e é aconselhado retirar o “ALP –“ no momento da criação para não ficar no name do objeto a sigla da
Alpar, sendo atualizado o label após a criação.
• Necessário atentar-se ao names com caractere especial, como acentos ortográficos. Neste caso a Servicenow altera a letra afetada para um underline. Todos os nomes
técnicos deverão ser inseridos em INGLÊS.
• Todos os itens, no momento da criação, já deverão passar por tradução para as duas línguas instaladas na instância do cliente. Itens não traduzidos serão reprovados
no momento da change.

V2.0 26/02/2022
5. Observações gerais

Toda customização deverá ser alinhada com o Líder Técnico do Cliente e equipe de arquitetura. Para as definições, deverão utilizados ferramentas como Teams e emails.
Qualquer modificação por conta própria será revista e com a possibilidade de ser refeita.

V2.0 26/02/2022