O que é o SMART ESOCIAL ?

O Smart e-Social é uma nova oferta TOTVS, que visa facilitar o uso e a entrega das principais obrigações legais dos produto TAF.

Trata-se de um produto SaaS e de fácil integração com as marcas, sendo transparente para o usuário final a sua utilização( todo processo de receptação e transmissão ao Governo não necessita de interação do usuário ).

Devido a ser um produto SaaS, estruturamos o time de suporte para que realize o gerenciamento da ferramenta e atualizações, assim como papeis e responsabilidade de cada ator dentro do suporte técnico.

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 no link https://docs.google.com/spreadsheets/d/1nu38EJCR6KiuhEUm vEcM0cYHzXtCI3s5dF_E8s2_yM/edit#gid=1374046759 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 ) 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 no link acima, possíveis mudanças de datas serão efetivadas diretamente na planilha;
   2. A responsabilidade por manter o calendário atualizado na planilha é da engenharia SP que controla o processo de validação conjunta entre TAF x Linhas de Produto;

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

Quando existir a necessidade de atualização do ambiente emergencialmente, a solicitação sempre será formalizada via e-mail pelo Product Owner do TAF.

As Equipes de produto (TAF/TSS) são responsáveis pelo gerenciamento dos itens críticos que deverão em um primeiro momento ser aplicados de forma manual nos seguintes diretórios:

TAF:

https://arte.engpro.totvs.com.br/engenharia/bundles/smarttaf/base/imagem/12.1.17/taf/rpo_emergencial/

TSS:

https://

Após atualização do RPO o time de produto é responsável por realizar os seguintes processos:

a. Abertura de solicitação para a equipe de SRE para atualização do ambiente c0fbc5

b. Homologação do pacote no ambiente c0fbc5

c. Abertura de solicitação para a equipe de SRE para replicação do RPO nos 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, etc ) o time de produto deve alinhar pontualmente com o time de SRE para atualização do ambiente, validar o artefato e após isso solicitar a réplica do artefato para o ambiente produtivo de todos os clientes.

Pontos a definir:

• Atualização de dicionário em casos emergenciais 
• Meio utilizado para abertura de solicitações a equipe de SRE (a principio Ryver/Slack)
• Diretório para atualização do TSS
• Criação de Robo para aplicação do Patch
• Criação de Robo para testes

Abertura de Issues

Issues de Manutenção:

A abertura de issues nos ambientes smart e-social devem seguir os mesmos critérios de DOR e DOD (https://tdn.totvs.com/x/7hW6Gw)  utilizados pelas demais equipes com execeçã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 deve ser necessáriamente o smartclient HTML (webapp).

Processo de abertura:

1 - Reprodução do problema em ambiente local utilizando webapp.

2 - Refinamento da Issue pelo P.O e planejamento do item nas Sprints.

3 - Análise do Time de Desenvolvimento e inclusão de data acordo.

4 - Correção do Incidente e testes em ambiente local.

5 - Se a Issue for critica seguir os passos do item Atualização dos Ambientes em casos Emergênciais

6 - Se a Issue tiver criticidade normal será expedida e o cliente receberá no retorno do ticket uma mensagem informando a data do pacote do WR.

Issues de Apoio: 

As issues de APOIO podem ser abertas nos casos em que o analista reponsá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/seguintos antes da abertura da Issue:

• Caso o problema esteja na integração ERPxTAF, 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.
• 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
• 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).

Expedição

Dar continuidade ao Ticket 7748413 solcitando que o pacote não seja enviado ao cliente (aguardando resposta)

Solicitação de Backups

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.