Ambiente de homologação para loja Magento: o mínimo para parar de testar em produção

O que é staging numa loja Magento e o que ele evita

Staging, ou ambiente de homologação, é uma segunda instalação da loja: o mesmo código, uma cópia do banco e das imagens, num endereço que cliente nenhum acessa. É ali que o dev roda a atualização, instala o módulo e mostra o resultado antes de tocar na loja que vende.

No Magento isso pesa mais do que num site comum, porque subir código não é copiar arquivo: o setup:upgrade aplica patches que alteram o banco e o setup:di:compile gera código. Se um desses passos quebra em produção, a loja para. No staging, o mesmo erro custa só o tempo do dev.

No Adobe Commerce na nuvem da Adobe, o ambiente vem pronto: segundo a documentação da arquitetura Pro, o Staging roda em infraestrutura dedicada, com os serviços da produção, como Fastly e New Relic. No Magento Open Source, ou no Adobe Commerce hospedado por conta própria, alguém precisa montar, e com as travas abaixo.

Checklist: os 10 itens que eu confiro num staging de loja Magento

Use a tabela como pedido para o dev ou para a hospedagem. Cada linha tem uma forma de conferir que não exige ler código.

Os itens 3, 4 e 9 protegem o cliente: staging que esquece um deles manda e-mail de pedido para quem comprou na loja real. Se só couber pouca coisa agora, comece por esses três e pela senha.

Trocar a base URL do staging e desligar o e-mail sem perder tudo na próxima cópia

O erro clássico é este: o dev copia o banco da produção, corrige a base URL direto na tabela core_config_data, esquece o e-mail e, um mês depois, copia o banco de novo. Tudo volta a apontar para a loja real, inclusive o envio de e-mail.

O Magento tem um caminho melhor. O bin/magento config:set com a opção --lock-env grava o valor em app/etc/env.php, e a documentação da Adobe diz que valor presente no env.php tem prioridade sobre o que está no banco e fica travado no admin. Como o env.php não vai para o repositório e não vem junto com o banco copiado, a configuração do staging sobrevive a qualquer importação:

bin/magento config:set --lock-env web/unsecure/base_url https://staging.sualoja.com.br/
bin/magento config:set --lock-env web/secure/base_url https://staging.sualoja.com.br/
bin/magento config:set --lock-env system/smtp/disable 1
bin/magento config:set --lock-env catalog/search/opensearch_index_prefix staging_sualoja
bin/magento indexer:reindex catalogsearch_fulltext
bin/magento cache:flush

Dois cuidados. Se a loja tem base URL própria por website ou por store view, cada uma precisa do mesmo comando com --scope e --scope-code; sem isso, o valor gravado no banco naquele escopo continua valendo. E o campo de e-mail fica em Stores > Configuration > Advanced > System > Mail Sending Settings: depois do comando ele aparece travado no admin, que é justamente o sinal de que funcionou.

Como bloquear o Google no ambiente de teste da loja

Senha na porta é a trava que não depende do banco. A documentação do Google orienta proteger com senha o conteúdo que não deve ser encontrado e avisa que página bloqueada só por robots.txt ainda pode aparecer nos resultados, por exemplo quando outra página aponta para ela.

No nginx, a configuração abaixo pede senha para quem está fora e deixa passar o IP da equipe sem pedir. O par satisfy any com allow e auth_basic é o exemplo da própria documentação do nginx:

satisfy any;
allow 203.0.113.10;
deny all;
auth_basic "Staging";
auth_basic_user_file /etc/nginx/.htpasswd-staging;
add_header X-Robots-Tag "noindex, nofollow" always;

Tem uma armadilha no cabeçalho. O nginx.conf.sample do Magento declara add_header próprio dentro das locations de /static/ e /media/, e pela regra do nginx isso anula o add_header herdado do bloco de fora. As páginas recebem o X-Robots-Tag; as imagens e os arquivos estáticos, não. Por isso a senha vem antes.

A liberação por IP ajuda também em teste de integração pela API REST, em que a senha da autenticação básica e o token disputariam o mesmo cabeçalho Authorization.

Staging no mesmo servidor da loja ou separado?

Não coloco preço aqui porque ele depende da sua hospedagem. O que dá para comparar é o critério:

O que eu recomendo: o ambiente local é ferramenta do dev; o staging é seu, é onde você aprova, com acesso próprio e limitado para o dev. Loja em servidor com folga se vira com staging no mesmo servidor, com banco, prefixo e cache separados e sem reindexar em horário de venda. Loja perto do limite da máquina precisa de staging separado.

Se quiser que eu olhe como está o staging da sua loja antes de contratar alguma mudança, me chama.