Ambiente de testes para PrestaShop: como montar uma cópia que não incomode ninguém

Testar as alterações numa cópia da loja antes de as levar para produção é das coisas mais sensatas que pode fazer. Mas uma cópia é, por definição, uma loja completa: tem os mesmos clientes, a mesma configuração de correio, as mesmas chaves dos gateways e as mesmas tarefas agendadas. Se não a desligar bem, faz exatamente o mesmo que a loja real, e isso inclui escrever aos seus clientes.

Este artigo é uma lista do que é preciso neutralizar numa cópia de testes, pela ordem em que convém fazê-lo.

Onde montá-la

Há três opções habituais, cada uma com as suas vantagens:

• Em local, no computador do programador ou num servidor interno. É a mais segura, porque não está acessível a partir da Internet, mas é mais difícil partilhá-la com quem tem de a rever.
• Num subdomínio do mesmo alojamento. É cómoda, mas partilha o servidor com a loja real: um teste pesado (uma importação, uma regeneração de imagens) tira recursos à produção.
• Num servidor à parte, com a mesma versão de PHP e a mesma configuração da produção. É o ideal para ensaiar atualizações, porque as diferenças de ambiente não o enganam.

Seja qual for, a cópia deve ter a mesma versão de PHP que a loja real, a não ser que esteja precisamente a testar uma mudança de PHP.

Passo 1: o correio, primeiro

Antes mesmo de abrir a cópia no navegador, corte o correio. Uma cópia acabada de importar tem a configuração SMTP de produção e a base de dados com clientes reais. Uma mudança de estado de uma encomenda, um carrinho abandonado que um módulo decide lembrar ou uma tarefa agendada que envia newsletters bastam para escrever a uma pessoa real a partir do seu ambiente de testes.

Opções, da mais à menos recomendável:

• Capturar o correio com um servidor SMTP de testes que recebe todas as mensagens e as mostra numa caixa web sem as entregar. Assim pode ver como ficam os e-mails sem risco.
• Desativar o envio em Parâmetros avançados → E-mail, com a opção de nunca enviar e-mails. É rápido, mas não lhe permite ver os e-mails.

Passo 2: dados pessoais anonimizados

Uma cópia de testes não precisa dos nomes, e-mails, telefones e moradas reais dos seus clientes. E tê-los num ambiente menos protegido do que a produção é um risco de proteção de dados. Substitua, no mínimo:

• E-mails de clientes por endereços fictícios de um domínio que não exista ou que controle.
• Nomes, apelidos, telefones e moradas de clientes e de moradas de envio.
• Mensagens de clientes, notas internas e dados de empresa como o NIF.
• Subscritores da newsletter e qualquer tabela de módulos que guarde dados pessoais: formulários, avaliações, listas de desejos.

Conserve as encomendas, os montantes e os produtos: são esses que precisa para testar. E mude as palavras-passe dos funcionários para outras diferentes das de produção.

Passo 3: pagamentos em modo de testes

Cada gateway tem um modo de testes com as suas próprias chaves. Na cópia, mude todas para esse modo antes de fazer a primeira encomenda. Reveja em concreto:

• Chaves de produção do gateway: substitua-as pelas de testes, não se limite a marcar uma caixa se o módulo usar as chaves que tem guardadas.
• Webhooks e notificações: o gateway verdadeiro continua a enviar os seus avisos para o URL de produção, e isso está certo. O que não pode acontecer é a cópia registar na conta real um novo webhook a apontar para si própria.
• Transferência e pagamento contra reembolso: não cobram, mas geram e-mails para o cliente com instruções. Já estão cobertos se o correio estiver capturado.

Passo 4: que ninguém a encontre

Uma cópia acessível a partir da Internet acaba indexada se não o impedir, e passa a competir no Google com a sua própria loja com o mesmo conteúdo.

• Proteção com palavra-passe no servidor web (autenticação básica). É o mais eficaz: nem motores de pesquisa nem curiosos passam do primeiro ecrã.
• Cabeçalho noindex em todas as respostas, como segunda camada.
• Modo de manutenção do PrestaShop com o seu IP autorizado, se não puder pôr palavra-passe.

Não confie apenas no robots.txt: pede aos motores de pesquisa que não rastreiem, mas não impede que um URL com ligação a partir de outro sítio apareça nos resultados.

Passo 5: as ligações ao exterior

É aqui que há mais surpresas, porque cada loja tem as suas:

• Tarefas agendadas. Se copiar também o crontab, a cópia executará as mesmas tarefas: exportações para o ERP, sincronizações com marketplaces, envios de newsletters. Desative-as e ative-as uma a uma só se as for testar.
• ERP e armazém. Um conector que cria encomendas ou atualiza o stock no ERP real é perigoso a partir de uma cópia: pode duplicar encomendas ou sobrescrever o stock com dados de teste.
• Marketplaces e feeds. Um módulo que publica produtos ou sincroniza stock com um marketplace usará as credenciais reais.
• Píxeis de seguimento e análise. As visitas da cópia sujam as estatísticas da loja real e podem enviar conversões falsas às plataformas de publicidade.
• Transportadoras. Alguns módulos geram etiquetas ou pedem recolhas através da API da transportadora.

Passo 6: o domínio

O PrestaShop guarda o domínio da loja na base de dados (na tabela de URLs da loja e na configuração). Se não o mudar, a cópia redireciona para a loja real assim que a abre. Depois de o mudar, esvazie a cache e regenere o ficheiro de URLs amigáveis. Procure também o domínio antigo na configuração dos módulos e nos conteúdos CMS: uma ligação absoluta para produção dentro da cópia pode fazê-lo acreditar que está a testar uma coisa quando está a ver outra.

Verificação antes de trabalhar

1. Faça uma encomenda de teste e confirme que o e-mail aparece capturado e não sai.
2. Procure na base de dados algum e-mail real de cliente: não deve restar nenhum.
3. Abra a cópia sem sessão a partir de outro navegador: deve pedir palavra-passe ou mostrar a manutenção.
4. Reveja que tarefas agendadas estão ativas e que módulos têm credenciais de serviços externos.

Uma cópia assim é uma ferramenta que pode usar sem receio em cada atualização, cada módulo novo e cada alteração do tema, e é a base para manter a loja em dia sem que sejam os seus clientes a testar.

Como resolver no PrestaShop

Na Rekire trabalhamos sempre sobre cópias deste tipo: correio capturado, dados anonimizados, gateways em modo de testes e ligações externas cortadas. Com um pacote de horas de suporte montamos a cópia da sua loja e deixamo-la pronta para ensaiar atualizações e alterações, ou fazemos nós essas alterações nela antes de as levar para produção. Se procura também um alojamento pensado para PrestaShop, o Hosting plan profesional da Rekire é a nossa proposta para lojas que querem deixar de se preocupar com o servidor.