Abertura de Issues

A abertura de issues nos ambientes

SMART e-social devem seguir os mesmos critérios de DOR

(https://tdn.totvs.com/x/7hW6Gw)  utilizados pelas demais equipes com

exceção da necessidade de verificação de fontes e versão de ambiente, porém o ambiente utilizado para reprodução do erro deve estar atualizado, em casos de erros em tela o remote utilizado para simular deve ser

OBRIGATORIAMENTE o último smartclient HTML (webapp) liberado no portal do cliente.

Processo de abertura da Issue de Manutenção:

a. Analista do suporte deve reproduzir erro em ambiente local utilizando última versão do produto liberada oficialmente ( Último Acumulado do TAF Expedido - Ambiente local utilizando o último atualizador automático do produto TAF expedido - De acordo com a versão do SMART eSocial - Calendário compartilhado no início deste  documento );

b. Quando reproduzido o erro precisa estar evidenciado na issue ( Documento ou Vídeo | Passo a Passo para reproduzir o erro | Versão do produto TAF que foi utilizada para reproduzir ) é ainda responsabilidade do time de suporte:

I. Avaliar se o erro impede a entrega da obrigação pelo cliente, se sim, junto com a abertura da issue deve ser enviado ao Product Owner do TAF/TSS e-mail informando sobre a abertura;

II. Avaliar se já existe issue aberta para o mesmo erro, se sim, associar o ticket e caso o erro seja impeditivo seguir o mesmo fluxo descrito no item ( I ) acima;

III. Quando não se tratar de um erro impeditivo deve-se apenas abrir/associar a issue de manutenção no backlog do produto TAF/TSS;

c. É de responsabilidade do Product Owner do TAF priorizar as issues citadas como emergenciais ( pois impedem a entrega do cliente );

d. Para issues não impeditivas é de responsabilidade do time de desenvolvimento do TAF/TSS informar ao cliente do SMART eSocial via ticket quando a correção estará disponível no seu ambiente, para isso deverá ser criado um texto padrão para que sempre quando informada a data acordo, além da mensagem padrão seja complementado o texto com o incremento que para clientes do SMART eSocial a correção estará disponível no ambiente no dia xx/xx/xxxx. As datas estarão disponíveis no calendário compartilhado citado no início deste documento. Seguir os passos do item "Processo de Expedição Contínua"

e. Para issues impeditivas é de responsabilidade do time de desenvolvimento do TAF/TSS informar ao cliente do SMART eSocial via ticket a data de quando a correção estará disponível no ambiente, essa data precisará obrigatoriamente estar previamente alinhada com o time de SRE visto que existe a dependência para liberação do ambiente. Seguir os passos do item Atualização dos Ambientes em casos Emergenciais;

Issues abertas fora do processo definido acima serão rejeitadas para correção e adaptação.

Processo de abertura da Issue de Apoio:

As issues de APOIO podem ser abertas nos casos em que o analista

responsável pelo ticket não consiga reproduzir o problema reportado ou tem dúvidas sobre um processo não documentado. Nos casos em que a

Issue for referente a  processo crítico e sem contorno o P.O deve ser notificado para priorização da análise evitando acionamentos do cliente na ouvidoria.

Os seguintes itens devem ser Obrigatoriamente analisados e anexados a issues antes da sua abertura:

a. Caso o problema esteja na integração ERP x TAF, o Json enviado pelo ERP deve ser analisado, para isso é necessário solicitar para a equipe de SRE a alteração da chave FWTraceLog para o valor 1, o log pode ser baixo pelo Rancher ( Neste cenário o erro pode ser reproduzido utilizando-se de ferramentas como o POSTMAN );

b. Caso o problema esteja em algum processo de integração do TAF (Job2-Integração, Job4-Transmissão ou Job5-Consulta), será necessário habilitar a chave TafConOut no serviço REST (por default o Schedule é iniciado neste container) e verificar se o serviço está operacional, caso não esteja solicitar primeiramente uma avaliação da equipe de SRE. O Log deverá ser anexado na Issue de Apoio juntamente com o console.log do TAF

c. Se o problema estiver relacionado a Interface("Tela") o mesmo deve ser reproduzido em um ambiente On Premisse, caso o problema só ocorra no webapp a Issue deve ser aberta para a Tecnologia (em caso de dúvidas, procurar o P.O).

Atualização dos Ambientes

Como a grande maioria dos módulos da linha Protheus o SMART E-SOCIAL OBRIGATORIAMENTE precisa de um processo de expedição contínuo e outro processo de expedição emergencial ( pontual ), abaixo iremos detalhar como e quando cada um dos processos ocorre:

Processo de Expedição Contínua:

Seguindo o calendário compartilhado abaixo sempre ao final de um processo de validação conjunta entre TAF e linhas de produto será expedido um pacote acumulado contendo todo o produto TAF ( FrontEnd | BackEnd | Lib | Binário | DbAccess | Dicionário de Dados ) no portal do cliente. Esse mesmo pacote será aplicado seguindo a data contida na linha "Expedição Smart e-Social" da planilha. 

1. 1. Para a aplicação do pacote no SMART e-Social NÃO será necessária a formalização por e-mail do Product Owner, o time de SRE deve seguir o calendário compartilhado previamente nos links abaixo, possíveis mudanças de datas serão efetivadas diretamente na planilha;
   2. A responsabilidade por manter o calendário atualizado na planilha é do PO do TAF e da engenharia SP que controla o processo de validação conjunta entre TAF x Linhas de Produto;

        Calendário de Expedição Continua e WR: https://docs.google.com/spreadsheets/d/1rUXpMvep_m-U5pugOKgvhbmFkKizn1DU26c8BNG-CEg/edit?usp=sharing

Atualização Emergencial de artefatos no ambiente do SMART E-SOCIAL:

Para aplicação de um pacote emergencial, o time de produto deverá vincular uma LABEL na issue expedida com a informação "smartesocial". A issueType deve ser de "manutenção" e status "CONCLUIDO".

Após o processo de vinculação da issue expedida, o time de produto deverá realizar os seguintes processos:

a. Abertura de solicitação para equipe de SRE (Slack ou e-mail ou chat) solicitando a atualização do ambiente c0fbc5, indicando quais pacotes deverão ser atualizados (Somente das labels + ultima expedição continua expedida) e/ou a próxima expedição continua gerada não homologada. Importante: O dicionário sempre será o gerado pela expedição continua vigente.

b. Homologação do ambiente c0fbc5; 

c. Abertura de solicitação à equipe de SRE para atualização dos demais ambientes; 

 Quando se fizer necessária a atualização emergencial de outros artefatos que não são aplicados no RPO ( binário, dbaccess, dicionário de dados, etc ) o time de produto(TAF | TSS ) deve alinhar pontualmente com o time de SRE para atualização do ambiente c0fbc5, seguindo exatamente o mesmo fluxo acima.

Pontos futuros a definir ( Não impacta no processo adotado atualmente ):

•  Criação de Robô para testes
•  Dar continuidade ao Ticket 7748413

• solicitando que o pacote não seja enviado ao cliente

• (aguardando resposta)

Solicitação de Backups / Saída do SMART e-Social

Com relação aos novos cancelamentos:

• Mensalmente será enviado pelo time de Contratos ao Product Owner do TAF a relação de clientes que solicitaram cancelamento da funcionalidade;
• O Product Owner irá enviar ao time do SRE uma solicitação via e-mail para desativação do serviço do cliente e disponibilização do backup do banco no mesmo ticket do cancelamento;
• No mesmo momento o banco de dados será excluído e o cliente não terá mais acesso a plataforma;
• O time do SRE informou que é possível resgatar o banco do cliente por 5 anos através da AWS, ou seja, se por qualquer necessidade for necessário recuperar o banco do cliente após a exclusão existe essa possibilidade;

Os Tickets referentes a solicitação de backup de base de dados por conta de cancelamento de assinatura devem ser direcionados para as equipes de CST e Cloud.