umairmsm/wp-ship

Etapa 7: Ship

Objetivo: staging es un espejo de producción, cada despliegue es aburrido, el día del lanzamiento tiene un plan de reversión y la primera semana se monitorea.

El propietario ejecuta los despliegues. Los agentes preparan, verifican y explican. No se conectan por SSH a los servidores, no ejecutan deploy-safe.sh, no cambian DNS ni tocan Cloudflare a menos que el propietario solicite esa acción exacta. deploy-safe.sh necesita una terminal y un ID de commit escrito, por lo que un agente no puede completarlo solo.

Pasos

1. Staging (references/deploy-and-launch.md, "Staging"): su propia carpeta y base de datos en el servidor de producción, WP_ENVIRONMENT_TYPE=staging, detrás de Cloudflare Access, una bandeja de prueba para consultas.
2. Endurecer cada servidor con el docs/reference/DEPLOY_HARDENING.md del proyecto. Registrar los resultados en docs/reference/SECURITY_PRELAUNCH.md.
3. Edge: configuraciones de Cloudflare desde references/cloudflare-edge.md. Antes de activar el proxy frente a un servidor antiguo, pruébalo: algunos servidores limitan la velocidad por IP y bloquearán a Cloudflare.
4. Desplegar código, solo el propietario:
   • completar deploy/targets.conf a partir del ejemplo;
   • ejecutar scripts/deploy-safe.sh <commit> --target staging --dry-run, leer la lista de cambios, luego ejecutarlo nuevamente sin --dry-run;
   • la primera ejecución en un servidor que ya tiene código necesita --assume-live <commit>.
5. Desplegar contenido por separado.
   • El código nunca transporta precios, páginas ni texto legal.
   • Registrar cada cambio como docs/data/content-changes/<fecha>-<tema>.json (valores antes y después por campo).
   • Aplicarlo con scripts/apply-content-change.sh <archivo> --target staging (simulación), luego --apply.
   • Después de cualquier importación o movimiento de base de datos, ejecutar scripts/check-emoji.sh --target <env>.
6. Auditoría de lanzamiento: ejecutar el agente launch-auditor contra staging, corregir lo que falle y ejecutarlo nuevamente hasta que pase.
7. Plan de corte. Redactarlo a partir de references/deploy-and-launch.md, "Cutover". El propietario aprueba la fecha y hora, y también el socio comercial si el sitio ya acepta reservas.
8. Salir en vivo: desplegar a producción, ejecutar launch-auditor contra producción, enviar el sitemap a Search Console, enviar una consulta de prueba real a la bandeja de entrada real.
9. Vigilar durante 7 días: errores, 404 (agregar redirecciones), la bandeja de formularios, analíticas, cobertura de Search Console.

Puerta (marcar en SITE_STATUS.md)

• Staging detrás de Access, noindex, correo protegido
• Endurecimiento aplicado y registrado
• Despliegue seguro a staging; prueba de humo verde
• launch-auditor PASA en staging, luego en producción
• Plan de corte aprobado (fecha, reversión, correo/MX verificado)
• Vigilancia de 7 días completada

Incidentes que dieron forma a estas reglas

• Un agente cambió precios en producción, publicó términos redactados por IA y desplegó una función sin revisión, y su informe omitió el despliegue. Desde entonces: los despliegues provienen solo de commits fusionados, a través del script, escritos por un humano, y las claves SSH de producción piden confirmación en cada uso.
• El formulario de contacto en staging publicó en un servicio de formularios de terceros con una clave de prueba, por lo que las consultas iban a una bandeja de prueba. Antes del lanzamiento, envía una consulta real en producción y verifica que llegue.
• Las analíticas web en modo "lite" no contaron visitantes de la UE durante semanas, lo que ocultó los mercados principales. Verifica la configuración el día 1.
• Un despliegue largo (39 commits) se detuvo por un SIGPIPE de git log | head bajo pipefail. El script ahora captura la salida primero.
• Una importación de base de datos de un servidor convirtió emojis en ????. Ejecuta check-emoji.sh después de cada importación.