Cuando cinco cambios necesitan entrar en producción en la misma madrugada, el riesgo no es de cada uno aisladamente — es de la coordinación. Alguien sube primero, otro depende de un servicio que aún no fue actualizado, y el rollback se convierte en un rompecabezas. La gestión de liberaciones existe para organizar ese paquete.

Esta guía detalla el módulo de Liberaciones del Portal Nyverra ITSM: qué es una liberación, cómo se relaciona con los cambios (RFC), los estados y transiciones, las validaciones de ventana y los permisos que protegen el proceso.

Interfaz del módulo en el Portal Nyverra ITSM.

Liberación × cambio

La confusión es constante — y vale la pena dejarlo claro desde ya:

Concepto	Qué es
Cambio (RFC)	La alteración individual, con tipo, riesgo, aprobación e implementación.
Liberación (release)	El paquete que agrupa uno o más cambios que entran en producción en la misma ventana.

Una liberación puede contener varios cambios, y la asociación es N:N (con orden en el paquete). El sistema genera un código automático en el formato REL-000001, REL-000002…

Atención a un falso amigo: “Solicitar liberación” en WhatsApp Inbox no tiene relación con este módulo — allí significa pedir al operador que ceda la conversación. Release ITIL es en Gestión de servicios → Liberaciones.

Los estados de una liberación

Estado	Significado operativo
Planificada	Paquete definido; ventana y cambios aún editables.
En curso	Go-live en curso.
Concluida	Release cerrado; registro cerrado para edición.
Cancelada	Paquete no será implantado (o fue abortado).

Las transiciones están controladas: de Planificada se puede ir a En curso, Concluida o Cancelada; de En curso, a Concluida, de vuelta a Planificada (reabrir) o Cancelada.

Validaciones y reglas del sistema

Situación	Comportamiento
Liberación concluida o cancelada	No edita campos; no vincula ni elimina cambios.
Eliminar liberación	Permitido solo en Planificada o Cancelada.
Fin planificado	Debe ser posterior al inicio planificado.
Implantación real	Si se informa, debe estar dentro de la ventana (inicio–fin).
Mismo cambio repetido	Se ignora (no duplica vínculo).

Un punto importante de expectativa: el Portal no bloquea concluir la liberación si alguna RFC aún no está aprobada. Muestra el estado de cada cambio vinculado, pero el “gate” de solo subir con todo aprobado es proceso de su empresa — valide en el módulo de Cambios y en las Aprobaciones.

Quién lo usa

Perfil	Uso típico
Gestor de release / técnico sénior	Planificar el paquete, definir ventana, vincular cambios y acompañar el go-live
Operador con permiso RELEASE_*	Crear, editar estado y mantener el paquete actualizado
Administrador	Conceder permisos del módulo LIBERACOES a los perfiles adecuados

Cómo usar: paso a paso

1. Cree la liberación (Gestión de servicios → Liberaciones → Nueva): título, descripción, ambiente objetivo, ventana planificada y responsable.
2. Vincule los cambios en la pestaña Cambios vinculados, pegando el UUID de la RFC (copiado del detalle del cambio).
3. Inicie el go-live cambiando el estado a En curso.
4. Registre la implantación real (fecha/hora dentro de la ventana).
5. Concluya la liberación al finalizar — o cancele si el paquete no va a subir.

Permisos (RBAC)

Permiso	Permite
RELEASE_VIEW_ALL	Ver lista y detalle
RELEASE_CREATE	Crear liberación
RELEASE_UPDATE_ALL	Editar, cambiar estado, vincular/desvincular cambios
RELEASE_DELETE	Eliminar (en los estados permitidos)

Si el menú no aparece o las acciones fallan con “sin permiso”, pida al administrador que revise el perfil.

Buenas prácticas

• Siempre agrupe en la liberación correcta los cambios que suben juntos — esto da trazabilidad y auditoría.
• Nunca marque la liberación como Concluida sin alinear con lo que fue realmente implantado.
• Solo haga el go-live con todas las RFC aprobadas (valide manualmente — el portal no lo impone).
• Asigne un responsable del release: mejora la comunicación y la coordinación.
• Mantenga releases pequeños y frecuentes: menor riesgo por ventana.

Errores comunes

Situación	Qué hacer
No puedo editar/vincular	La liberación puede estar Concluida o Cancelada.
Error al guardar fechas	Compruebe fin > inicio e implantación real dentro de la ventana.
UUID inválido	Copie el ID completo del detalle de la RFC (formato UUID).
“Liberación concluida no puede ser editada”	Esperado — cree una nueva liberación para otro paquete.

Preguntas frecuentes

¿Necesito aprobar la liberación en Aprobaciones pendientes?
No. Apruebe cada cambio en su flujo; la liberación es el registro del paquete.

¿El sistema impide concluir si una RFC está pendiente?
No — la validación es manual, siguiendo el proceso de la empresa.

¿Un cambio puede estar en dos liberaciones?
Técnicamente sí (N:N); úselo con criterio (en general una RFC pertenece a un release por ventana).

Automatice vía API

El módulo está expuesto por API (/api/liberacoes, incl. implantar/cancelar y vínculo con cambios). Referencia en developer.nyverra.com.

Escenarios de uso: releases en la práctica

1. Ventana de mantenimiento de madrugada. Cinco RFCs necesitan subir juntas a las 23h. El gerente crea una liberación, vincula los cambios aprobados, define la ventana y coordina el go-live. Al final, registra la implantación real y concluye. El paquete queda trazable de punta a punta.

2. Release con rollback parcial. Durante la ventana, uno de los cambios falla y necesita ser revertido. La liberación documenta lo que subió y lo que volvió — evitando que “producción quedó en un estado indefinido”.

3. Auditoría de cambios en producción. Meses después, se pregunta “¿qué subió aquella noche?”. La liberación responde: qué RFC, en qué orden, con qué estado y cuándo fue implantada. Sin el paquete, la respuesta se reconstruiría por suposición.

KPIs de liberación

Indicador	Qué revela
Releases por período	Cadencia de entrega
RFCs por release	Tamaño del paquete (riesgo)
Implantaciones dentro de la ventana	Disciplina de ejecución
Liberaciones canceladas	Planificación vs realidad
Releases sin cambios vinculados	Paquetes “vacíos” o mal registrados

Automatización e integración

La liberación conversa con los demás módulos: los cambios componen el paquete; el Downtime Manager suprime alertas en la ventana; la Trazabilidad guarda el historial. Para reducir riesgo, mantenga releases pequeños y frecuentes — y siempre con el plan de rollback de cada RFC validado antes del go-live.

Checklist de implantación de liberaciones

1. Defina quiénes son los gestores de release (permisos RELEASE_*).
2. Establezca la política de tamaño de paquete (prefiera releases pequeños).
3. Estandarice la ventana de mantenimiento y el vínculo con Downtime.
4. Exija plan de rollback por cambio del paquete.
5. Valide, antes del go-live, que todas las RFC están aprobadas.
6. Registre la implantación real y concluya la liberación.

Preguntas frecuentes adicionales

¿Por qué el portal no bloquea concluir con RFC pendiente?
Porque el “gate” depende del proceso de la empresa; el portal muestra el estado, pero la decisión de subir es humana.

¿Puedo vincular el mismo cambio a dos releases?
Técnicamente sí, pero lo usual es que una RFC pertenezca a un release por ventana.

¿Cómo auditar lo que subió?
Por la liberación, que reúne las RFC, la ventana y las fechas de implantación.

Conclusión

La gestión de liberaciones transforma un conjunto de alteraciones en un paquete controlado, con ventana, orden y registro de implantación. Con el módulo de Liberaciones del Portal Nyverra ITSM, la ida a producción deja de ser improvisación y pasa a ser un proceso predecible y auditable.