Nós da Linx e-Millennium, sabemos dos transtornos que uma atualização de versão pode gerar aos nossos clientes. Com isto, não queremos parar o ambiente produtivo, para que não gere prejuízos nas operações. 
 
Para minimizar e até zerar estes problemas, a equipe de atualização e SaaS implantaram um novo processo de atualização, onde será efetuada a homologação da versão em um ambiente clonado do ambiente produtivo e seguiremos alguns passos.




  1. Inicialmente, o novo processo se aplica apenas para a atualização do sistema e-Millennium, outros produtos estão temporariamente fora do novo processo.
  2. Em caso de exceções, será necessária a autorização mútua dos diretores de P&D Gustavo Maimone Hispagnole do Help Desk  Marcelo Marega Machado  
  3. Clientes em fase de implantação só entrarão neste novo processo a partir do momento do Go-Live.
  4. Em caso de problemas com a atualização efetuada fora deste roteiro, a solução será um rollback para que volte ao estado anterior. 
  5. As atualizações serão feitas apenas com os instaladores disponíveis no ftp://desenv.millenniumhosting.com.br.
  6. Todo o processo de atualização será monitorado através do sistema TraceGP da Linx, onde deverão ser feitas as autorizações.
  7. Servidores SaaS e Hosting que já estiverem em produção deverão ser sempre atualizados pela equipe de atualizações ou pelos canais homologados listados abaixo, é proíbido mexer nesses servidores quando estão em produção.
  8. Para correção de Bugs de clientes que foram recentemente atualizados, será disponivbilizado um sub-release da messma versão para atualizar e as ataulizações de versão somente será liberada após 3 meses da última atualização (exceto para release)
  9. A atualização do ambiente de produção precisa ser autorizada pelo setor de atualizações - Arlindo Aparecido Rodrigues, pelo Help Desk - Paulo Gonçalves Junior  e pelo P&D Isabel Cristina Da Palma .


Passos para a atualização:

  • Abertura de caso no SalesForce

Para darmos andamento ao processo de atualização, é necessário que haja um caso em aberto contendo as seguintes informações: 
Motivo da atualização 
Versão Atual 
Versão Desejada 
 
A prioridade deste chamado será classificada de acordo com os motivos citados. 

Em caso de erro/bug onde existe uma Issue no Jira, o chamado será transferido para P&D com as informações já mencionadas. 

Informação importante

Chamados vindo do suporte ou implantação, sem ou Issue do Jira ou sem um laudo tecnico "release/atualização" serão negados. Para a criação do laudo,  o tecnico deve solicitar a criação de um ambiente de testes (se o cliente o cliente não tiver) ou ainda criar um confirme o Procedimento para criar um servidor de testes e fazer os testes nesse ambiente para evidenciar que funcionou na versão sugerida. É indispensável validar se existe um sub-release para a versão do cliente.


 

  • Criação do ambiente de testes

Antes de qualquer atualização, será criado um ambiente de testes para que o cliente valide as operações principais do sistema.  Deverá ser enviado à equipe de atualização as evidências desses testes, que são: notas fiscais, cupom SAT do emulador, alguns relatórios e print de algumas telas. 

No caso de atualização solicitada por algum técnico ou no caso de retorno da Issue do Jira antes de fazer os testes acima, o cliente precisa validar se o erro ocorrido, e em conjunto com o colaborador (Help-Desk, P&D, Implantação, franqueado, etc) que solicitou a atualização,  para ver se o problema citado anteriormente foi resolvido. Se o erro ainda persistir, a equipe de atualizações irá devolver a Issue para P&D ou se não for issue a TP para quem solcitou a ataualização até que o problema seja solucionado.  

Já em caso das Issues do Jira serem testadas, seguiremos com o processo de certificação da versão, seguindo o Roteiro de testes pré-atualização de versão para validar se está tudo de acordo. Se houver algum problema, o cliente deve solicitar apoio ao P&D antes de  seguir, abrir Issues em situações que impeçam a atualização e pedir prioridade para a solução.  
 
Se não houver erros na validação do cliente, a atualização será efetuada. 

 

Qualquer ajuste de banco ou método no ambiente de testes deverá ser anotado, pois será aplicado no ambiente de produção. 

Deve-se manter os instaladores, os mesmos deverão ser instalados no servidor de produção. Caso for necessário instalar um release diferente do testado, deverá ser avisado solicitar aprovação na reunião de GMUD. 


  • Abertura de Tarefa no Jira

Após todos os testes estarem de acordo, abriremos uma Tarefa no Jira para a execução da atualização. Aberta a tarefa, ela deverá passar pelo processo de aprovação na reunião de CCM, todas as sextas-feiras.

  • Reunião para aprovação de mudanças

Nesta reunião, que irá ocorrer todas as sextas-feiras, o gestor de atualizações juntamente com o gestor do Help Desk e o gestor do P&D deverão avaliar todos os chamados que estão cadastrados no Jira e ainda não foram aprovados. As situações pertinentes serão aprovadas para a próxima semana ou colocar na fila de espera para a semana seguinte.

  • Execução da atualização

Após aprovada a tarefa, um analista entrará em contato com o cliente para agendar a atualização nos 3 primeiros dias úteis da semana e deve ter ao menos 2 dias úteis após a atualização para um possível acerto ou necessidade de rollback. Nenhuma atualização pode ser feita em finais de semana exceto sob autorização prévia dos dois diretores citados no item 2 das informações. 
 
A execução consiste em:
  1. Fazer o Backup da pasta wts e do banco de dados para retorno em caso de Rollback, que deve ser feito em até 2 dias uteis após a atualização
  2. Rodar os instaladores que foram utlizados nos testes para a atualização
  3. Fazer os ajustes que foram anotados no ambiente de testes
  4. Instalar os módulos que o cliente porventura possa ter
  5. Colocar o sistema no ar e validar se esta acessando normalmente


  • Monitoramento da atualização

Após a atualização, a equipe que fez a atualização irá monitorar o cliente 5 dias úteis e findado esse período, todos os atendimentos voltam para o Help Desk. 

Importante

Qualquer atualização feita por outras equipes ou consultores externos serão de inteira responsabilidade desses e em caso de pane, deve-se fazer rollback da atualização.


Os seguintes canais estão autorizados à fazer as atualizações dos clientes:

  • TOP Software Informática - canal RJ
  • Siaccon Software - canal MG
  • MD Software - canal CE
  • Masters Consultoria - canal ES
  • Parra e Melo - canal SP
  • MWTS - canal RS
  • JL Infiormática - canal GO
  • Jean - canal Ribeirão Preto

Agradecimento à Lais Carla Trajano Da Silvapela revisão do documento.


  • Sem rótulos