wp-ship

Estágio 7: Ship (Envio)

Objetivo: staging espelha a produção, todo deploy é rotineiro, o dia do lançamento tem rollback e a primeira semana é monitorada.

O proprietário executa os deploys. Agentes preparam, verificam e explicam. Eles não acessam servidores via SSH, executam deploy-safe.sh, alteram DNS ou tocam no Cloudflare a menos que o proprietário peça exatamente essa ação. deploy-safe.sh precisa de um terminal e um id de commit digitado, então um agente não consegue concluir um sozinho.

Etapas

1. Staging (references/deploy-and-launch.md, "Staging"): sua própria pasta e banco de dados no host de produção, WP_ENVIRONMENT_TYPE=staging, atrás do Cloudflare Access, uma caixa de entrada de teste para consultas.
2. Endurecer cada servidor com o docs/reference/DEPLOY_HARDENING.md do projeto. Registre os resultados em docs/reference/SECURITY_PRELAUNCH.md.
3. Borda (Edge): configurações do Cloudflare de references/cloudflare-edge.md. Antes de ativar o proxy na frente de um host antigo, teste: alguns hosts limitam taxa por IP e bloquearão o Cloudflare.
4. Deploy de código, apenas o proprietário:
   • preencher deploy/targets.conf a partir do exemplo;
   • executar scripts/deploy-safe.sh <commit> --target staging --dry-run, ler a lista de alterações, depois executar novamente sem --dry-run;
   • a primeira execução em um servidor que já tem código precisa de --assume-live <commit>.
5. Deploy de conteúdo separadamente.
   • O código nunca carrega preços, páginas ou texto legal.
   • Registre cada alteração como docs/data/content-changes/<data>-<topico>.json (valores antes e depois por campo).
   • Aplique com scripts/apply-content-change.sh <arquivo> --target staging (dry run), depois --apply.
   • Após qualquer importação ou movimentação de banco de dados, execute scripts/check-emoji.sh --target <env>.
6. Auditoria de lançamento: execute o agente launch-auditor contra o staging, corrija o que falhar e execute-o novamente até passar.
7. Plano de corte. Escreva-o a partir de references/deploy-and-launch.md, "Cutover". O proprietário aprova a data e hora, e o parceiro de negócios também, se o site já aceitar reservas.
8. Ir ao ar: faça deploy para produção, execute o launch-auditor contra a produção, envie o sitemap para o Search Console, envie uma consulta de teste real para a caixa de entrada real.
9. Monitorar por 7 dias: erros, 404s (adicione redirecionamentos), a caixa de entrada de formulários, analytics, cobertura do Search Console.

Portão (marque em SITE_STATUS.md)

• Staging atrás do Access, noindex, e-mail protegido
• Endurecimento aplicado e registrado
• Deploy seguro para staging; teste de fumaça verde
• launch-auditor APROVADO no staging, depois na produção
• Plano de corte aprovado (data, rollback, e-mail/MX verificado)
• Monitoramento de 7 dias concluído

Incidentes que moldaram estas regras

• Um agente alterou preços ao vivo, publicou termos de serviço escritos por IA e fez deploy de uma funcionalidade sem revisão, e seu relatório omitiu o deploy. Desde então: deploys vêm apenas de commits mesclados, através do script, digitados por um humano, e as chaves SSH de produção pedem confirmação a cada uso.
• O formulário de contato no staging enviava para um serviço de formulários de terceiros com uma chave de teste, então as consultas iam para uma caixa de entrada de teste. Antes do lançamento, envie uma consulta real na produção e veja se ela chega.
• O analytics web no modo "lite" não contou visitantes da UE por semanas, o que escondeu os mercados principais. Verifique as configurações no dia 1.
• Um deploy longo (39 commits) parou em um SIGPIPE de git log | head sob pipefail. O script agora captura a saída primeiro.
• Uma importação de banco de dados de servidor transformou emoji em ????. Execute check-emoji.sh após cada importação.