Preparación de publicación y reversión
Lleva un cambio a un entorno con las comprobaciones, la vigilancia, las señales de parada y la vuelta atrás escritas antes de salir.
Entregable
Un documento Markdown, release-runbook.md, con la estructura fijada en Salida más abajo. Se ejecuta en el momento de publicar y se guarda con el registro de lo que ocurrió.
Entradas obligatorias
- El conjunto de cambios que sale — qué incluye, en qué revisión, y qué cambia para quienes usan el sistema.
- El entorno de destino — a dónde va, qué corre ya allí, y quién es responsable de él.
Si falta cualquiera de las dos, detente y repórtalo. Un manual escrito sin saber qué está corriendo ya no puede decir qué cambia la publicación.
Entradas opcionales
- El mecanismo de despliegue, y si puede sostener dos versiones a la vez
- Monitorización, alertas y las señales que ya se vigilan en ese entorno
- Cambios de datos en el conjunto: migraciones de esquema, rellenos, cambios de formato
- La ventana de publicación, quién está disponible durante ella, y quién debe aprobar
- Sistemas dependientes y las personas que los tienen a su cargo
- El registro de publicaciones anteriores a este entorno, y cómo fueron
Cuando falta una entrada opcional, el manual la nombra como hueco en la lista de adelante / no adelante y no da por supuesta la capacidad.
Ejecución
1 — Inventariar lo que sale. Cada cambio del conjunto, con su revisión, y qué cambia cada uno para quienes usan el sistema. Lo que esté en el conjunto y nadie esperaba publicar se detiene aquí, en lugar de descubrirse después.
2 — Escribir las comprobaciones previas con su condición de aprobación. Cada comprobación declara qué se ejecuta, quién lo ejecuta, y qué resultado permite seguir adelante. Una comprobación sin condición de aprobación es un rito: se hará y no decidirá nada.
3 — Ordenar los pasos de despliegue. Cada paso en secuencia, con qué hace, quién lo hace, y cómo se confirma que funcionó antes de empezar el siguiente. Cuando los sistemas dependientes deben moverse en un orden concreto, ese orden forma parte de la secuencia y nombra al responsable de cada uno.
4 — Definir la vigilancia. Qué se observa después de publicar, dónde se observa y durante cuánto tiempo — declarado como un periodo al que alguien se compromete, no como una vigilancia indefinida. Incluye las señales que eran normales antes de publicar, para que un cambio en ellas se vea.
5 — Fijar las señales de parada. Las observaciones concretas que terminan la publicación y disparan la reversión, decididas antes de publicar en lugar de discutidas durante. Cada una nombra a quién puede declararla.
6 — Escribir la reversión como procedimiento propio. Sus pasos, quién los ejecuta, cómo se confirma que el sistema ha vuelto, y cuánto tiempo cuesta. Una reversión que no está escrita es un plan para improvisar bajo presión.
7 — Nombrar lo que no se puede revertir. Cambios de datos, migraciones irreversibles, mensajes ya enviados, sistemas externos ya avisados. Son los que fijan el punto de no retorno real, y se listan explícitamente con el paso a partir del cual se aplican.
Salida
release-runbook.md, en este orden:
- 1. Conjunto de cambios — qué sale, en qué revisión, y qué cambia para quienes usan el sistema
- 2. Entorno de destino — dónde, qué corre ahora allí, y quién lo tiene a su cargo
- 3. Comprobaciones previas — por comprobación: qué se ejecuta, quién lo ejecuta, y el resultado que permite publicar
- 4. Pasos de despliegue — ordenados; por paso: la acción, el responsable, y la confirmación antes del siguiente
- 5. Vigilancia — qué se observa, dónde, durante cuánto tiempo, y qué era lo normal antes
- 6. Señales de parada — las observaciones que terminan la publicación, y quién puede declarar cada una
- 7. Reversión — los pasos, el responsable, la confirmación, y el tiempo que cuesta
- 8. No reversible — los cambios que no se pueden deshacer, y el paso a partir del cual se aplican
- 9. Adelante / no adelante — una línea por condición, respondida sí, no o
desconocido
- 10. Huecos — qué no se pudo establecer, y quién puede establecerlo
Validación
El manual está listo cuando se cumple todo esto:
- Cada elemento de la sección 1 nombra su revisión y qué cambia para quienes usan el sistema
- Cada comprobación de la sección 3 declara una condición de aprobación, no solo una acción
- Cada paso de despliegue nombra un responsable y una confirmación
- La sección 5 declara un periodo y qué era lo normal antes de publicar
- La sección 7 da una reversión cuyos pasos son tan concretos como los de despliegue, con su coste en tiempo
- La sección 8 está poblada o declara explícitamente que nada del conjunto es irreversible
Falla la ejecución si la reversión está menos detallada que el despliegue, o si la sección 9 lleva una condición respondida desconocido y la lista se presenta igualmente como adelante.
Gestión de fallos
- No hay reversión posible — dilo en la sección 7, nombra qué la hace imposible, y exige que la lista de adelante / no adelante la apruebe sobre esa base quien figure como responsable en la sección 2.
- Un cambio de datos sin ensayar en el conjunto — responde esa condición como
no en la sección 9. Un cambio de datos que no se ha ensayado contra una copia de los datos de destino es el único paso de una publicación que no se puede deshacer.
- Sin monitorización en el entorno de destino — declara en la sección 5 que la publicación queda sin observar, describe las comprobaciones manuales que la sustituyen, y registra el hueco en la sección 10.
- Condiciones desconocidas al publicar — lista cada una de ellas en la sección 9 como
desconocido y presenta la lista como no adelante. Una lista de adelante / no adelante con incógnitas no es un adelante.
- La ventana se cierra a mitad — párate en el último paso que llevaba confirmación, revierte hasta él si el paso actual no puede completarse, y registra dónde se detuvo. Una publicación aplicada a medias es peor que una no empezada.
