Publicar · Criterio KATA
De staging a producción
Publicar no es copiar archivos. Es cambiar algo que ya funciona por algo que creemos que funciona mejor, y conviene poder demostrarlo y deshacerlo.
Cómo se ha elaborado esta guía
Qué estás leyendo
Esta página describe cómo despliega KATA, no cómo debe desplegar todo el mundo. Es un criterio operativo propio, formado en proyectos reales, no un estándar del sector.
Qué es criterio propio y qué es estándar externo
- Criterio propio: La secuencia, el orden y los umbrales que se describen son decisiones metodológicas de KATA.
- Experiencia observada: Lo aprendido en los proyectos de KATA. No se presenta como dato estadístico ni se cuantifica.
- Estándar externo: Cuando se cita un hecho de un tercero se identifica su fuente oficial, con entidad y fecha.
La metodología completa está en el Método KATA.
Respuesta directa
En KATA la secuencia es siempre la misma: preservar, congelar, verificar, publicar, comprobar y observar. El orden importa más que la herramienta.
La regla que gobierna todo lo demás: no se toca producción sin un camino de vuelta probado. Si no se ha probado la restauración, no hay camino de vuelta: hay una esperanza.
Las seis etapas
1 · Preservar
Copia completa fuera del servidor, con hashes por archivo y restauración probada. No basta con que la copia exista: hay que haberla restaurado alguna vez.
2 · Congelar
Se cierra el alcance. Lo que no ha pasado por QA no entra, aunque sea pequeño. Los cambios de última hora son los que rompen los despliegues.
3 · Verificar en staging
El entorno de pruebas debe parecerse a producción en lo que importa: mismo contenido, mismas rutas, mismas cabeceras. Un staging que no se parece no verifica nada.
4 · Publicar de forma reversible
Ventana acordada, runbook escrito de antemano y un procedimiento de vuelta atrás que alguien ha leído antes de necesitarlo.
5 · Comprobar
Humo, enlaces, formularios, cabeceras y seguridad. Inmediatamente, no al día siguiente.
6 · Observar
A 60 minutos, a 24–72 horas y a 7 días. Muchos problemas no aparecen en el minuto uno: aparecen cuando llega tráfico real.
Por qué en este orden
Cada etapa existe porque su ausencia produce un fallo concreto y caro.
- Sin preservar primero, un error obliga a reconstruir en caliente con prisa y sin red.
- Sin congelar, se publica algo que nadie ha verificado entero.
- Sin staging representativo, se verifica un sitio distinto del que se publica.
- Sin reversibilidad, la única salida ante un fallo es arreglarlo bajo presión.
- Sin comprobar, el fallo lo descubre un visitante.
- Sin observar, se descubre en la factura del mes siguiente.
Dónde este criterio NO aplica
- Proyectos con despliegue continuo y decenas de publicaciones diarias: esta secuencia es demasiado pesada y conviene automatizarla.
- Cambios de contenido menores sobre un sistema ya estable y con vuelta atrás automática.
- Entornos con equipo de operaciones propio y procedimientos ya establecidos: ahí este criterio se adapta, no se impone.
- Emergencias de seguridad, donde la prioridad es contener y el orden puede alterarse a conciencia.
Preguntas frecuentes
¿Cuánto tarda esta secuencia?
Depende del proyecto y no publicamos plazos genéricos porque serían falsos. Lo que sí es constante es el orden: la etapa que más tienta a saltarse —preservar— es la que más caro sale omitir.
¿Aplica a un cambio pequeño?
El tamaño del cambio no predice el tamaño del fallo. Lo que se adapta es la profundidad de cada etapa, no su existencia: un cambio menor sigue necesitando copia previa y comprobación posterior, aunque ambas duren minutos.
Siguiente decisión
Continúa con una pregunta concreta
Snapshots, hashes y vuelta atrás
Una lectura relacionada dentro del mismo método.
Snapshots, hashes y vuelta atrás →
Webs corporativas y transaccionales
Qué podemos abordar contigo y cómo delimitamos el trabajo.
Webs corporativas y transaccionales →
Ilustraciones conceptuales; no son fotografías de clientes.