Módulo 8 · 8.3
Staging: testar com segurança
Módulo 8: Cópias de segurança, ambiente de testes (staging) e atualizações de PHP · Tempo de leitura: 9 minutos
Objetivo de aprendizagem: Depois desta lição, saberá criar um ambiente de testes (staging), protegê-lo e aplicar alterações com segurança na sua site real.
Conceitos-chave: staging, produção, clonagem, subdomínio, noindex, palavra-passe na pasta, e-mail desativado, fornecedor de pagamentos em modo de teste, sincronização, substituição da base de dados, ambiente de desenvolvimento local
O que é o staging
Um ambiente de testes (staging) (ou site de testes) é uma cópia da sua site real, num endereço próprio, onde experimenta alterações. À sua site real chama-se produção. No staging pode correr mal: um novo tema, uma atualização grande, uma atualização de PHP (lição 8.4), um novo plugin. Só quando funciona é que aplica a alteração em produção.
Deve usar o staging para alterações com risco: versões importantes do WordPress ou de um plugin de loja online, um tema diferente, uma atualização de PHP, a limpeza de plugins (lição 5.4), uma reformulação do design. Para uma alteração de texto ou uma pequena atualização de plugin não é necessário.
Formas de criar um staging
| Forma | Como | Para quem |
|---|---|---|
| Função de clonagem do seu instalador | No Installatron, «Copiar» com «Create a staging site», no Softaculous «Create Staging», no WP Toolkit «Clone» | O caminho mais fácil se a sua site foi criada com um instalador |
| Staging do seu alojamento | Em alojamento WordPress gerido, muitas vezes apenas um botão | Se o seu alojamento o disponibilizar |
| Um plugin de staging | Um plugin cria uma cópia numa subpasta ou num subdomínio | Se não tiver um instalador ou função do alojamento |
| Manualmente | Restaurar uma cópia de segurança ao lado da site (lição 8.2) e ajustar os endereços | Instrutivo, e sempre possível |
| Localmente no seu próprio computador | Um programa para desenvolvimento local de WordPress ou um ambiente Docker | Para programadores e alterações maiores |
Um staging num subdomínio (staging.example.com) é normalmente melhor do que numa subpasta (example.com/staging): comporta-se mais como a sua site real, e os cookies e regras no .htaccess não se misturam. Crie primeiro o subdomínio, com um certificado.
Proteger: três coisas a tratar de imediato
Uma cópia da sua site é uma site completa, com todo o seu conteúdo e, por vezes, com todos os dados dos seus clientes. Por isso, trate já disto:
1. Afastar os motores de pesquisa
Sem proteção, o Google pode encontrar e indexar o seu staging. Isso cria conteúdo duplicado, e quem pesquisa acaba a chegar à sua site de testes. Faça pelo menos uma, de preferência duas, destas ações:
- Uma palavra-passe em todo o staging (autenticação básica através do painel de alojamento, uma «pasta protegida»). Assim, ninguém vê a site sem palavra-passe, nem os motores de pesquisa. Esta é a mais forte.
- Desencorajar os motores de pesquisa em Opções > Leitura (lição 2.4). Isso coloca
noindexem todas as páginas. Os motores de pesquisa geralmente respeitam isto, mas é um pedido, não um bloqueio.
Atenção ao contrário: se mais tarde sincronizar o staging de volta para produção, não leve consigo a opção de noindex. Uma site de produção que desaparece do Google depois de uma sincronização «bem sucedida» é um clássico. O exercício desta lição verifica ambos os casos.
2. Nenhum e-mail para pessoas reais
Uma cópia de uma loja online ou de um site de membros pode enviar e-mails: confirmações, lembretes, newsletters, ligações para repor a palavra-passe. Os clientes recebem então e-mails confusos vindos da sua site de testes. Desative o envio de e-mail no staging ou redirecione-o para o seu próprio endereço (com um plugin de interceção de e-mail, ou desativando o plugin de SMTP no staging, lição 9.1). Desative também as tarefas agendadas que enviam e-mail.
3. Pagamentos e integrações em modo de teste
Uma loja online em staging deve funcionar com o modo de teste do fornecedor de pagamentos, e não com pagamentos reais. Outras integrações (contabilidade, stock, CRM) devem ser desativadas ou ligadas a um ambiente de teste, caso contrário recebem encomendas de teste como se fossem reais.
Se trabalhar com dados reais de clientes no staging, o RGPD aplica-se da mesma forma (lição 9.3): não guardar os dados mais tempo do que o necessário, e eliminar o staging quando terminar.
Voltar à produção: a armadilha da base de dados
O passo mais difícil é aplicar as suas alterações em produção. Os instaladores e os plugins de staging têm uma função para isso (no Installatron «Synch», noutros «Push to live»). O risco:
- Cria um staging na segunda-feira. De terça a quinta-feira testa um novo tema.
- Entretanto, em produção, chegam vinte encomendas, três novos artigos e cinquenta comentários.
- Na sexta-feira, sincroniza a base de dados do staging para a produção. A base de dados do staging é a de segunda-feira: as encomendas, artigos e comentários de terça a sexta-feira desaparecem.
Por isso:
- Faça primeiro uma cópia de segurança da produção (lição 8.1), mesmo antes de sincronizar.
- Sincronize apenas o que for necessário. Atualizar um tema ou plugin é uma questão de ficheiros; a base de dados muitas vezes nem precisa de ser incluída. Muitas funções de sincronização permitem escolher: apenas ficheiros, ou apenas determinadas tabelas.
- Numa loja online ou site com muito movimento: é preferível aplicar a alteração novamente em produção (os mesmos passos usados no staging, agora que sabe que funcionam) em vez de substituir a base de dados. Ou planeie um momento mais calmo com uma breve paragem da loja.
- Verifique depois a produção: a lista de verificação da lição 8.2, e a opção de noindex.
O staging é um local para aprender o que acontece. A alteração em si é aplicada com mais segurança refazendo-a diretamente em produção.
Limpeza
Um staging que fica ativo durante meses torna-se uma site esquecida: não atualizada, com plugins antigos e dados reais. Exatamente o ponto fraco referido na lição 7.1. Elimine o staging quando terminar, ou mantenha-o como uma site completa (atualizações, palavra-passe). Um clone ocupa tanto espaço quanto o original e tem a sua própria base de dados.
Resumo
- O staging é uma cópia da sua site num endereço próprio para testar alterações com risco.
- Crie-o com o seu instalador, o seu alojamento, um plugin ou manualmente, de preferência num subdomínio com certificado.
- Proteja-o de imediato: palavra-passe e/ou noindex, nenhum e-mail para pessoas reais, pagamentos em modo de teste.
- Não sincronize às cegas de volta: a base de dados do staging substitui o que se acrescentou em produção. Faça primeiro uma cópia de segurança, sincronize apenas o necessário, ou aplique a alteração novamente.
- Elimine o staging quando terminar, e não leve a opção de noindex para a produção.
Questionário
Exercício
Exercício A8.3: O seu ambiente de testes (staging) está protegido? Indique o endereço do seu staging (um subdomínio do seu próprio domínio, por exemplo o do exercício D8.2) e o da sua site real. Comprove com o código do exercício que o domínio é seu. O programa verifica no staging: responde via https, e está protegido (um pedido de palavra-passe, ou noindex no HTML ou no cabeçalho X-Robots-Tag)? A referência REST (wp-json) aponta para o próprio staging e não para a sua site real? E na sua site real: não existe lá nenhum noindex?
Leitura adicional
Estes artigos descrevem os passos nos painéis da WebOké; noutros painéis funcionam de forma semelhante.