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.
- Inicialmente, o novo processo se aplica apenas para a atualização do sistema e-Millennium, outros produtos estão temporariamente fora do novo processo.
- 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
- Clientes em fase de implantação só entrarão neste novo processo a partir do momento do Go-Live.
- Em caso de problemas com a atualização efetuada fora deste roteiro, a solução será um rollback para que volte ao estado anterior.
- As atualizações serão feitas apenas com os instaladores disponíveis no ftp://desenv.millenniumhosting.com.br.
- Todo o processo de atualização será monitorado através do sistema TraceGP da Linx, onde deverão ser feitas as autorizações.
- 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.
- 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)
- 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
Reunião para aprovação de mudanças
Execução da atualização
- 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
- Rodar os instaladores que foram utlizados nos testes para a atualização
- Fazer os ajustes que foram anotados no ambiente de testes
- Instalar os módulos que o cliente porventura possa ter
- Colocar o sistema no ar e validar se esta acessando normalmente
Monitoramento da atualização
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