Cuando trabajamos con servicios y lo ponemos en marcha por primera vez nos podremos dar cuenta que surgen dos cosas, fallos o mejoras para el servicio, esto gracias al monitoreo posterior del servicio después de que fue “liberado”. Cuando se decide hacer algún cambio en el servicio lo ideal es ir creando diferentes versiones de mejoras para tener un mejor control de las mismas. Dentro de la metodología ITIL existe un término llamado “Release Management” esta herramienta ayuda a los servicios a mejorar y poder sacar el mejor provecho de las versiones propuestas para un servicio.
Release Management
Una versión puede comprender muchos componentes de aplicación e infraestructura diferentes que trabajan juntos para ofrecer una funcionalidad nueva o modificada. También puede incluir documentación, capacitación (para usuarios o personal de TI), procesos o herramientas actualizados y cualquier otro componente que se requiera. Cada componente de una versión puede ser desarrollado por el proveedor de servicios o adquirido de un tercero e integrado por el proveedor de servicios.
La utilidad principal del Release Management es hacer que los servicios nuevos y los que ya han sido modificados desde su previo lanzamiento puedan ser puestos en marcha con la máxima eficiencia posible.
Las releases son variadas y pueden abarcar desde lo más pequeño como un cambio menor hasta lo más grande que puede abarcar varios componentes que entreguen un servicio completamente nuevo. En cualquier caso, un release plan especificará la combinación exacta entre los componentes nuevos y los que surgieron un cambio para que puedan estar disponibles y a tiempo para su release.
Para poder entregar los releases a tiempo se utiliza un release schedule o un calendario de versiones. Este calendario debe ser negociado y acordado por los clientes y otros stakeholders.
Existen dos formas de llevar el proceso de release management, en el ambiente tradicional/waterfall o en los ambientes Agile/DevOps.
- Tradicional/Waterfall:
El release management en un ambiente en cascada se suele llevar de la mano con el “deployment” o paso a producción de la mano, como si fueran un proceso único.
- Agile/DevOps:
En un ambiente de Agile o DevOps puede haber actividad de release management después de haber pasado a fase de “deployment” o a producción. En estos casos, el software y la infraestructura son lanzados en pequeños componentes, y la actividad del release management habilita la nueva funcionalidad en un punto más tardío.
El release management es usualmente manejado en diferentes estados o etapas, comenzando con etapas piloto para un pequeño grupo de usuarios para asegurarse que todo está funcionando correctamente antes de que sea liberado a grupos adicionales. Este escenario de estados funciona con cualquiera de los dos modelos antes mencionados.
ServiceNow Release Management
La aplicación Release Management de ServiceNow(SN) engloba la planeación, diseño, construcción, configuración y pruebas de releases ya sea hardware o software para crear un compuesto definido de componentes para el release.
Esta aplicación maneja los releases utilizando el ya conocido sistema de registros de “task”. Estos registros de task componen otras aplicaciones dentro de SN que ayudan a la conectividad entre aplicaciones. Cada característica planeada es generada como un registro de task, creando un registro con la información pertinente en cada uno de los campos requeridos. Estas tasks pueden ser asignadas a los miembros apropiados de los equipos de release management, quienes serán los encargados de trabajar y manejar las tasks hasta que el release haya sido puesto en marcha.
Como ya lo mencionamos la aplicación de Release Management en SN se compone de las fases de:
- Planear(Planning)
- Diseño(Design)
- Desarrollo(Build)
- Configuración(Configuration)
- Pruebas(Testing)
El Release Management se compone de una serie de actividades que son realizadas con el fin de asegurar que los cambios son aplicados a los ambientes de pre-producción y producción.
Esta aplicación de SN nos brinda formularios sencillos listos para ser usados y comenzar a crear releases dependiendo de nuestras necesidades. Siempre es posible modificar cualquier característica de estos formularios adecuandolos a las necesidades de cada organización.
Dentro de los campos que utiliza release de fábrica se encuentra uno que nos permite seleccionar que tipo de release será, con esto nosotros podemos especificarle a los encargados del release que tipo de trabajo es el que se estará realizando. Los valores que vienen por defecto son para empezar “Major” que nos indicaría que el release es de gran importancia o lleva consigo grandes cambios, el otro sería “Minor” que nos indicaría que el release es de menor importancia. Los otros valores nos indicarán que tipo de cambio se llevará a cambio con este release cómo podría ser, una actualización “Upgrade”, un cambio de emergencia (emergency), un release para darle mantenimiento al software o hardware y así poder registrar este mantenimiento y por último un “Patch” o parche en el caso de los sistemas de software.
Otro de los campos dentro del formulario por defecto son los estados del registro. Estos nos ayudan a identificar en qué estado se encuentra nuestro release, desde “Draft” que es un bosquejo general de lo que será el release, “Scoping” donde definiremos el enfoque que tendrá nuestro record, “Awaiting Approval” el estado en el que se solicita aprobación de los involucrados para que todos puedan estar de acuerdo con lo que se estableció en previos estados, “Work in progress” en este estado comenzaremos a ver cómo se va llevando a cabo el trabajo del release, en “Testing/QA” verificaremos que el trabajo realizado sea como fue planeado, y una vez que el trabajo fue probado y aprobado podremos pasar a “Deploy/Launch”, y en caso de que todo haya resultado como deberia por último concluiriamos con “Closed Complete” para indicar que todo salio a la perfección. Esta serie de estados nos permiten tener un control increíble sobre el flujo de trabajo de los releases, evitando problemas de comunicación entre los involucrados y habilitarlos a todos a trabajar en un solo registro a la vez.
Otro de los campos a tomar en cuenta es el “Release Phase” en el cual nuestros equipos del release podrán indicar en cuál de los estados que se usan comúnmente en el release management de ITIL se encuentra el release. ServiceNow respeta los estados definidos por ITIL y los podremos aplicar de manera sencilla dentro de nuestros releases.
Sin duda la aplicación de Release Management en servicenow está muy completa y puede brindarnos infinitas posibilidades, además de que esta aplicación es escalable dependiendo del tamaño de la organización pudiendo ser usada por pequeñas empresas hasta empresas de mayor magnitud. Utilizando los plugins de Servicenow podemos agregarle gran valor a la ya robusta y eficiente aplicación de Release Management.
Si su organización se encuentra interesada en comenzar a aplicar el Release Management como parte de su trabajo no dude en contactarnos y sin duda encontraremos la mejor alternativa para usted. En Convene contamos con experiencia implementando sistemas con release management y sin duda nuestro equipo le brindará toda la atención y ayuda que necesita.
