Paquete de corte a producción y día de lanzamiento (con IA)

En proyectos con cliente, el “pase a producción” suele ser cambiar DNS un viernes a las 17:00 y mirar Slack hasta que alguien grite. Así se pierden disparadores de rollback, no hay humo escrito en producción y nadie sabe quién manda la primera hora en vivo. El corte a producción es la ventana controlada en la que pasas de staging aprobado a sistemas reales: no es la semana de UAT, no es la aceptación de hito para facturar, y no es el hipercare de varias semanas.

Este playbook va después del go/no-go de UAT y antes del hipercare. Combina ChatGPT (listas FACT/ASSUMPTION), un Brief de corte en Google Docs, un registro de humo en Google Sheets y tres correos Gmail de sala de guerra hasta T+0 y la primera hora en producción.

Cuándo usar el pack de corte

Ábrelo cuando:

• UAT terminó con go escrito y un ID de build congelado.
• DNS, claves de pago o contenidos tienen ventana acordada.
• Hay que una fuente de verdad escrita durante el flip.
• El rollback es viable y el cliente nombra un decisor en T+0.

No lo uses si aún hay bloqueantes de UAT, si negocias alcance con solicitudes de cambio, o si es un despliegue interno sin corte visible para el cliente.

Flujo de extremo a extremo

Paso 1 — Checklist solo con hechos (ChatGPT)

Pega el resumen go/no-go, build RC y mapa de entornos:

Eres líder de entrega escribiendo un corte a producción de una hora. Hechos: [resumen UAT go, versión RC, URLs, dueño DNS, dueño pagos, método rollback].

Reglas:
- Cada línea: FACT (verificado) o ASSUMPTION (verificar antes de T+0)
- Salida: pasos ordenados con dueño, duración, verificación
- Salida: 8–15 pruebas de humo en 15 minutos
- Salida: disparadores de rollback (cualquiera = parar y volver atrás)
- Formato tabla para Google Docs.

Tú validas cada ASSUMPTION antes de compartir con el cliente.

Paso 2 — Brief de corte de una página (Google Docs)

Sección	Contenido
Cabecera	Proyecto, build RC, fecha/hora (TZ cliente + UTC)
Participantes	Líder de corte, aprobador cliente, dueño DNS/hosting, soporte
Pre-vuelo (T-24h)	Backups OK, página mantenimiento, borradores de comms
Secuencia	Pasos numerados: quién, qué, señal de éxito
Humo	Enlace a Sheets; regla pass antes de decir "en vivo"
Rollback	Última versión buena, TTL DNS, quién ejecuta, tiempo máx. decisión
Fuera de alcance hoy	Ítems aplazados con ticket (sin scope creep oculto)
Puente hipercare	Fecha inicio, canales, severidades al backlog

Comparte solo lectura a dirección; comentarios a técnicos hasta firmar T-1.

Paso 3 — Registro de humo (Google Sheets)

Columnas: ID, Área, Pasos, Esperado, Real, Pass/Fail, Tester, Hora (UTC), Enlace evidencia.

Ejecuta el humo inmediatamente tras el último paso de corte—no al día siguiente. Bloquea el Gmail de "estamos en vivo" hasta que los caminos P0 estén en verde o el aprobador cliente acepte la excepción por escrito.

Disparadores de rollback (ejemplos): fallo de cobro de prueba, login roto para admin, tasa de error API sobre umbral, DNS aún apuntando al viejo IP tras la ventana TTL.

Paso 4 — Cadencia Gmail (tres correos)

Correo 1 (T-24h) — Asunto: [Proyecto] Corte a producción mañana — roles y ventana

• Ventana en hora local del cliente
• Enlace al Brief de corte
• Quién entra en call/hilo; aprobador en T+0
• Confirmación: "Aceptamos el plan de rollback tal cual"

Correo 2 (T-1h o inicio) — Asunto: [Proyecto] Corte iniciado — actualizaciones

• "Ejecutando paso 1 de N"
• Actualizaciones en hitos (DNS, deploy, humo)
• Un solo hilo reply-all

Correo 3 (tras humo o rollback) — Asunto: [Proyecto] Producción en vivo o [Proyecto] Rollback completado

• Resumen humo (pass/fail)
• Inicio hipercare + cómo reportar defectos
• Si rollback: estado factual y próxima ventana, sin culpas

Tú envías; ChatGPT solo redacta. No automatices correos de producción sin revisión humana.

Paso 5 — Ejecutar, decidir, documentar

Durante la ventana:

1. Un líder de corte comunica estado; el resto ejecuta.
2. Anota tiempos reales en el Brief (auditoría para garantía e hipercare).
3. Si un paso falla, pausa—no saltes verificaciones para "ganar tiempo".
4. En decisión de rollback, el aprobador cliente responde por escrito en el hilo.

Tras humo en verde:

• Actualiza el Brief: "Producción en vivo desde [timestamp]."
• Abre o refresca el backlog de hipercare para que fixes no se pierdan en DMs.
• Programa check-in a 24h (puedes reutilizar email semanal de estado).

Errores frecuentes

• Mezclar UAT con corte — UAT valida el build; el corte mueve tráfico.
• Rollback verbal — "Redeployeamos" no es plan. Nombra versión, comando y reloj de decisión.
• Anunciar live antes del humo — Marketing espera pass técnico salvo riesgo aceptado por escrito.
• Heroísmo viernes noche — Ventana laboral del cliente con tiempo de rollback el mismo día.

Qué hacer después

Resultado	Siguiente playbook
En vivo + humo estable	Hipercare
En vivo + cláusula garantía	Garantía post-entrega
Rollback, reintento	Revisar UAT en rutas fallidas
Soporte continuo vendido	Arranque retainer

Semilla de humo (tabla inicial)

ID	Área	Pasos	Esperado
S1	Auth	Login usuario admin prueba	Panel carga, sesión OK
S2	Flujo core	Happy path completo	Estado éxito + email confirmación
S3	Pagos	Cargo sandbox o mínimo	Gateway capturado, pedido pagado
S4	Contenido	Top 3 URLs públicas	200, sin mixed content
S5	Integraciones	Webhook o job sync	Última ejecución < 5 min
S6	Rendimiento	Spot check acordado	Bajo umbral del brief
S7	SEO/redirect	URL legacy si migras	301 correcto
S8	Admin	Crear y borrar registro prueba	Auditoría si aplica

En resumen

UAT da derecho a cortar; el corte da derecho a decir en vivo. Un Brief de corte, Sheets de humo y tres Gmail mantienen honesto el momento del lever—el hipercare empieza con hechos, no con rumores.

Más guías para entrega con cliente.