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 no seu 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 do seu site real, num endereço próprio, onde experimenta alterações. Ao seu 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

Um staging num subdomínio (staging.example.com) é normalmente melhor do que numa subpasta (example.com/staging): comporta-se mais como o seu 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 do seu site é um site completo, 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 ao seu 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ê o 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 noindex em 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. Um 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 do seu 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:

1. Faça primeiro uma cópia de segurança da produção (lição 8.1), mesmo antes de sincronizar.
2. 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.
3. 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.
4. 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 um site esquecido: não atualizado, 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 um site completo (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 do seu 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 do seu 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 o seu site real? E no seu 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.

• Manual DirectAdmin 13.7: Clonar e criar um ambiente de teste (staging)
• Criar um ambiente de staging do WordPress
• Manual DirectAdmin 15.9: Proteção de pastas com senha
• Manual DirectAdmin 4.5: Criar e remover subdomínios
• Manual DirectAdmin 13.8: Eliminar uma instalação