¿Qué es una lista de verificación de release?
Una lista de verificación de release convierte el lanzamiento a producción en pasos marcables en el elemento de trabajo: preparación previa, build y artefactos, aprobación del cambio, el despliegue en sí, smoke tests y monitoring, rollback y cierre. Los encabezados se quedan estables; las marcas, los SHA y las notas cambian con cada despliegue.
Los equipos envían de formas distintas. Los equipos de continuous delivery recortarán las filas de ventana de cambio. Los trenes de release semanales las conservarán. Trata la lista como un runbook de partida y guarda tu versión para que el cambio de producción del viernes no dependa de la memoria.
Por qué los equipos dejan la lista de release en la incidencia
Un runbook que vive en una wiki o en un hilo de Slack se pierde fácil cuando arranca el despliegue. Una lista de verificación en el elemento de trabajo deja el SHA, la ventana, los smoke tests y el camino de rollback donde ya está el cambio: release managers, on-call y desarrolladores ven el mismo trabajo restante.
El mismo andamiaje sirve si envías en continuo o en una ventana de cambio: abres la incidencia, ves lo que falta, marcas sobre la marcha y escribes qué pasó cuando algo falla. Los flips de flag de bajo riesgo pueden recortar filas de aprobación, comunicación y rollback; los de alto riesgo las conservan.
Cuándo aplicarla
Usa una lista de verificación de release cuando un cambio va a producción: en la story que se envía, o en una incidencia de change dedicada cuando el despliegue tiene owner, fechas y workflow propios. Aplícala automáticamente cuando el estado pasa a Ready to release o Deploying para que el runbook aparezca antes de la ventana. Recorta filas en despliegues continuos de bajo riesgo; conserva aprobación, comunicación y rollback cuando el cambio es visible para usuarios o difícil de revertir.
Release vs. pruebas QA vs. Definition of Done
La lista de verificación de pruebas QA es el pase de pruebas antes de abrir la ventana. Definition of Done es el listón de salida compartido en la story: review, tests y preparación de release que cada elemento debe al final. La lista de verificación de release es el runbook de lanzamiento en el cambio que realmente se envía. Déjalas como listas separadas para que el pase de pruebas, el listón de envío y la ventana de producción se vean distintos. Acceptance criteria siguen describiendo el comportamiento que estás poniendo en vivo.
Release y despliegue: un ejemplo para empezar
Para armar tu primera lista de verificación de release, empieza con el ejemplo de abajo. Copia la lista y pégala en el campo de Checklist for Jira en un elemento de change o de release. Lo ideal es guardarla como plantilla y aplicarla automáticamente cuando el trabajo pasa a Ready to release: cada despliegue tiene un andamiaje consistente y reutiliza los mismos encabezados cada vez. Recorta filas que tu equipo se salta; añade las que tu proceso necesita.
Release y despliegue
- Preparación previa al release
- Change, feature flag y claves de ticket están listados en este elemento de trabajo
- Stakeholders y on-call conocen la ventana, o el motivo de que sea continua
- El riesgo, el blast radius y qué vigilar están escritos en el elemento de trabajo
- Build y artefactos
- El artefacto de build o el SHA del commit está registrado
- La verificación en pre-prod o staging está hecha, o eximida por escrito
- Secrets, certificados y acceso de despliegue están en su sitio
- Seguridad y aprobación del cambio
- La revisión de seguridad o las notas de amenaza están vinculadas cuando el cambio es sensible
- Las aprobaciones que exige tu política están registradas en el elemento de trabajo
- Despliegue
- Los pasos de despliegue a producción se ejecutaron en el orden documentado
- Las migraciones o cambios de config se completaron sin errores sin respuesta
- Los feature flags coinciden con la audiencia prevista
- Smoke testing y monitoring
- Los smoke tests en el camino de producción pasaron
- Tasa de error, latencia y KPIs de negocio se ven normales para la ventana
- Los dashboards de monitoring y las alertas del servicio cambiado están abiertos
- Rollback, comunicación y cierre
- El camino de rollback o desactivación está lo bastante probado para usarlo
- Support, success o la página de estado está actualizada cuando los usuarios pueden ver el cambio
- La incidencia o el elemento de trabajo de seguimiento está vinculado cuando el release causó daño
- Las notas post-release y las tareas restantes están capturadas en esta incidencia
Ese andamiaje va en el cambio que se envía. En Checklist for Jira añades o marcas puntos en el panel de la incidencia, guardas los encabezados como plantilla de proyecto o global, y la aplicas automáticamente cuando el estado pasa a Ready to release — o a mano desde Add → Add from template cuando la necesites.
Deje la checklist en el elemento de trabajo, no en la descripción
Checklist for Jira aporta plantillas, automatización, validadores de flujo y un agente Rovo. Gratis para equipos de hasta 10 usuarios.
Guarda un starter, automatiza el runbook
- Checklist for Jira añade un panel de checklist en la vista de la incidencia. Pega el ejemplo de arriba en un elemento de change o de release, ajusta las filas a tu proceso y guarda la forma como plantilla de proyecto o global en Checklist settings.
- Marca la plantilla como Protected si quieres el runbook bloqueado mientras la gente marca puntos, para que los pasos no se encojan en silencio de un despliegue al siguiente.
- Usa la automatización por plantilla para adjuntar el andamiaje de release cuando el estado pasa a Ready to release o Deploying. Estas automatizaciones vienen en Checklist for Jira y corren sin créditos de Jira Automation.
- Si tu equipo quiere una puerta dura, añade un validador de finalización en el estado shipped, limitado a esta plantilla. Una post function puede resetear la lista si haces rollback y lo intentas de nuevo. Jira Automation puede aplicar, completar o resetear la misma lista cuando la condición es más rica que un solo estado.
- Combínala con la lista de verificación de pruebas QA antes de la ventana y Definition of Done en la story — ver la guía de automatización.
Combínala con el resto del set de delivery
Deja la lista de verificación de pruebas QA en la incidencia hasta que el pase esté en verde. Adjunta Definition of Done en la story para que el listón de envío se vea desde el día uno. Usa Definition of Ready durante el refinement si la calidad del intake ayuda a tu equipo. Recorre el hub de plantillas para el conjunto completo.
Preguntas frecuentes
¿El release debería vivir en una incidencia de Jira aparte?
Si el despliegue es un proyecto real con owner, fechas y workflow propios, una incidencia o subtarea dedicada es lo correcto. Si el runbook es una lista de comprobaciones sobre un cambio que ya tienes, deja una lista de verificación en ese elemento de trabajo.
¿Cada equipo necesita la misma lista de verificación de release?
No. Empieza con una plantilla y recorta. Los equipos de continuous delivery suelen soltar filas de ventana de cambio y de aprobación. Un tren semanal regulado conservará aprobaciones, comunicación y rollback. Guarda una segunda plantilla cuando dos productos mantienen runbooks distintos.
¿Las plantillas globales pueden servir a todos los proyectos?
Sí. Los administradores de Jira guardan plantillas globales; los administradores de proyecto, las de proyecto. Los runbooks globales Protected son un valor por defecto sólido cuando varios equipos deben enviar del mismo modo.
¿Cómo reseteamos la lista después de un rollback?
Añade una post function o un reset-all de Jira Automation en la transición de vuelta desde shipped, limitado para que solo se vacíe la lista de release. La guía de automatización recorre el reset y los validadores de finalización.
Deje la checklist en el elemento de trabajo, no en la descripción
Checklist for Jira aporta plantillas, automatización, validadores de flujo y un agente Rovo. Gratis para equipos de hasta 10 usuarios.