Bienvenidos a ITIL 4 sin filtros, elevando en la en presentado por Con Punto y Koma.
Yo soy Julián
y yo soy Alex, y hoy vamos a sumergirnos en una confusión clásica del mundo de la gestión de servicios de TI Release management y Deployment management.
La gente los confunde todo el tiempo.
Así es.
Y lo entendemos, es fácil confundirse.
Pero hoy vamos a desmenuzando todo, no solo que son sino como trabajan juntos y como se conectan con Change Enablement los value streams y bueno, todo lo demás.
Sí, sí.
Así que si alguna vez pensaste no son lo mismo, quédate con nosotros porque, bueno, Al final del episodio,
te va a quedar clarísimo que son muy distintos, pero también inseparables.
Bueno, vamos a aclararlo de entrada.
Release management es básicamente hacer que algo nuevo o cambiado esté disponible.
Es como decir hey usuarios, aquí está lo nuevo que prometimos.
Es el momento en que los cambios se vuelven reales.
O sea realmente utilizables, puede ser una aplicación nueva, una función genial o no sé un parche de seguridad importante, pero todo gira en torno a hacerlo disponible.
Exacto.
Deployment management es más tras bambalinas.
Se trata de mover los componentes software, hardware, datos a los entornos donde deben ejecutarse.
Puede ser staging, test, producción, lo que sea.
Y aquí es donde la gente se confunde algo puede estar desplegado o deployed, pero no liberado o released.
En otras palabras, el código puede estar en producción, pero como.
En modo fantasma.
Sí, como si estuviera en modo sigiloso hasta que Release management no da la luz verde.
Los usuarios ni se enteran
hasta ahora.
Hablamos de Release y Deployment como piezas separadas del rompecabezas, no?
Sí.
Y eso está bien para explicarlos, pero en la práctica, especialmente en entornos modernos, están súper entrelazados.
Exactamente.
Y ahí es donde entra lo interesante.
Porque cada vez más organizaciones usan Agile y DevOps para, ya sabes, acelerar la entrega de valor.
Y cuando vas rápido pero rápido de verdad, Release y Deployment, no solo tienen que colaborar, tienen que fluir juntos.
Ahí es donde entra si CI/CD.
Si.
CI/CD, que significa en español, integración continua y entrega y despliegue continuo, es como la columna
vertebral de los pipelines modernos y honestamente cambia por completo.
Cómo se comportan Release y Deployment
Total.
En una cultura DevOps no esperas al próximo mes, estás empujando cambios todo el tiempo, y eso hace que Release
y Deployment sean más fluidos, más automáticos y también más riesgosos si no tienes un enfoque estructurado,
pero también más poderosos.
Así que vamos a desglosar CI/CD, porque es el motor detrás de cómo evolucionan estas prácticas en tiempo real.
CI es integración continua, o sea, los desarrolladores suben código al repositorio todo el tiempo y se compila
y prueba automáticamente así evitas desastres cuando se unen más tarde
y CD tiene dos significados.
Entrega continua significa que el software está siempre listo para liberar.
Pero alguien decide cuándo a hacerlo.
Eso es otro nivel.
El despliegue continuo, todo lo que pasa, las pruebas se despliega automáticamente.
Pum.
Producción sin la intervención humana.
Pero ojo, eso solo funciona si Release y Deployment están súper coordinados.
Muy bien sincronizados.
Se despliega.
Pero igual hay que decidir cuándo, cómo y para quién.
Sí, como cuando lanzas una funcionalidad, pero solo la activas para un pequeño grupo de usuarios, digamos a un 5%,
para probar que todo funcione bien antes de habilitarla para todos, eso se llama un "canary release".
Bueno antes de seguir, vale la pena repasar algo clave.
La cadena de valor del servicio, o service value chain.
Son seis actividades centrales en ITIL 4.
Correcto.
Planificar, mejorar, involucrar, diseño y transición, obtener y construir, y entrega y soporte.
Y Release management aparece en casi todas.
Diseño, transición, entrega, mejora.
Incluso planificación
Deployment management también, principalmente en diseño, transición y construcción.
Es el que mueve las piezas.
Pero nada de esto funciona sin Change enablement, y ojo.
No es solo para decir si o no a un cambio
Claro.
Es como el pegamento estratégico.
Asegura que cada cambio esté alineado con el riesgo, el tiempo, la prioridad y los objetivos de negocio.
Define el tipo de cambio, quien participa, cuáles son los criterios de éxito.
Todo eso se evalúa antes de aprobar, pero sigue vigilante durante todo el proceso de Release y Deployment
para garantizar que Release y Deployment ejecuten lo que se pensó, que no se desvíe.
Es como una producción de teatro: Change enablement es el productor, Deployment, el equipo técnico y Release, el director que dice "luz, cámara, acción".
Ilustremos un ejemplo.
Supongamos que lanzamos un nuevo chat bot para atención al cliente.
Veamos... el equipo de desarrollo lo construye, Change enablement da el visto bueno y Deployment
lo lleva a staging y luego a producción, pero no está activo aún
Ahí entra Release management.
Se preparan los manuales, se entrena al equipo de soporte
actualiza la base de datos de conocimiento.
Se libera la funcionalidad para un grupo pequeño.
Se monitorea el rendimiento, se identifican errores.
Y si todo está bien, se amplía a toda la base de usuarios.
Y si algo falla, todo se reversa.
Es por eso que Release and Deployment deben tener planes para regresar todo a su estado anterior.
Eso es ITSM en acción resiliente responsivo y flexible.
Julián y cómo sabremos qué tal lo estamos haciendo
Midiendo.
En Release management, debemos medir la satisfacción de usuarios, número de Releases exitosos, incidentes derivados de cambios, cumplimiento de cronogramas
y en Deployment management, porcentaje de despliegues exitosos, errores de implementación, tiempos de respuesta.
Cumplimiento de ventanas de mantenimiento
y con la automatización, las herramientas como pipelines de CI/CD, integración con pruebas automatizadas y verificación de entornos.
Hacen todo más rápido también más seguro.
Claro, siempre que haya roles definidos y modelos de gobernanza que lo respalden.
- Julián ITIL 4 se basa en un enfoque holístico y eso se refleja en sus cuatro dimensiones.
Organización y personas, información y tecnología, socios y proveedores y flujos de valor y procesos
A ver... en Release y Deployment.
Esto es clave.
Necesitas personas capacitadas, tecnología adecuada, coordinación con terceros y procesos bien diseñados.
Por ejemplo, si el proveedor de una herramienta no libera una versión compatible a tiempo, eso afecta tu
release o si tu equipo no está alineado con el proceso, el cambio puede fallar.
Cada dimensión influye en la otra.
Y cuando las cuatro están equilibradas, la entrega de valor es sostenible, confiable y ágil
Para cerrar un mensaje claro, Release y Deployment no son actividades técnicas aisladas.
Son prácticas estratégicas
Totalmente.
Y cuando están bien integradas con Change enablement, y con la cadena de valor, la organización puede entregar cambios con confianza
y eso se traduce en usuarios satisfechos, menos incidentes y más valor
y también noches tranquilas para los equipos de operaciones.
Gracias por acompañarnos en este episodio de ITIL 4 Sin Filtros presentado por Con Punto y Koma.
Si te gustó compártelo y suscríbete.
Y cuéntanos tus experiencias, liberando cambios, las buenas y las que no tanto
Te esperamos en el próximo episodio.
Hasta entonces...
...sigue entregando valor con propósito.