12.10. Gestión de versiones y despliegues.


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Una versión es un grupo de CIs de nueva creación o modificados que han sido validados para su instalación en el entorno de producción. Las especificaciones funcionales y técnicas de una versión están determinadas en la RFC correspondiente.

Las versiones pueden clasificarse, según su impacto en la infraestructura TI, en:

 

• Versiones mayores: que representan importantes despliegues de software y hardware y que introducen modificaciones importantes en la funcionalidad, características técnicas, etc.

• Versiones menores: que suelen implicar la corrección de varios errores conocidos puntuales y que a menudo son modificaciones que vienen a implementar de una manera correctamente documentada soluciones de emergencia.

• Versiones de emergencia: modificaciones que reparan de forma rápida un error conocido.

Como pueden llegar a existir múltiples versiones, es conveniente definir una referencia o código que los identifique unívocamente. El sistema universalmente aceptado es:

 

• Versiones mayores: 1.0, 2.0, etc.

• Versiones menores: 1.1, 1.2, 1.3, etc.

• Versiones de emergencia: 1.1.1, 1.1.2, etc.

Aunque en algunos casos esta clasificación se refina aún más (vea, por ejemplo, en la ayuda la versión de su navegador).

En su ciclo de vida, una versión puede encontrase en diversos estados: desarrollo, pruebas, producción y archivado.

El siguiente diagrama nos ilustra gráficamente la evolución temporal de una versión:


 

El despliegue de nuevas versiones puede realizarse de diferentes maneras y es responsabilidad de la Gestión de Cambios el determinar la forma más conveniente de hacerlo. Entre las opciones más habituales cabe contar:

 

• Versión delta: sólo se testean e instalan los elementos modificados. Esta opción tiene como ventaja su mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas e incompatibilidades en el entorno de producción.

• Versión completa: Se distribuyen todos los elementos afectados, ya hayan sido modificados o no. Aunque esta opción es obviamente más trabajosa, es más improbable que se generen incidentes tras la instalación si se han realizado las pruebas pertinentes.

• Paquete de Versiones: La Gestión de Cambios puede optar por distribuir de forma sincronizada diferentes paquetes de versiones: de esta forma se ofrece una mayor estabilidad al entorno TI. En algunos casos esta opción es obligada por incompatibilidades entre una nueva versión con software o hardware previamente instalado. Pensemos, por ejemplo, en la migración a un nuevo sistema operativo que requiere hardware más avanzado y/o nuevas versiones de los programas ofimáticos.

Biblioteca de Medios Definitivos (DML).

La Biblioteca de Medios Definitivos (DML) debe contener una copia de todo el software instalado en el entorno TI. Esto incluye no sólo sistemas operativos y aplicaciones, sino también controladores de dispositivos y documentación asociada.

La DML debe contener el histórico completo de versiones de un mismo software para proporcionar la versión necesaria en caso de que se deban implementar los planes de back-out.

La DML debe ser almacenada en un entorno seguro y es conveniente que se realicen back-up periódicos.

Recambios Definitivos (DS).

El almacén de Recambios Definitivos (DS) contiene piezas de repuesto para los CIs en el entorno de producción.

Los activos almacenados deben incorporarse a la CMDB en el caso de que los CIs correspondientes se hallen registrados en la misma (esto puede depender del alcance y nivel de detalle de la CMDB).

 

Proceso.
 

Las principales actividades de la Gestión de Entregas y Despliegues se resumen en:

 

• Establecer una política de planificación para la implementación de nuevas versiones.

• Desarrollar o adquirir de terceros las nuevas versiones.

• Implementar las nuevas versiones en el entorno de producción.

• Llevar a cabo los planes de back-out o retirada de la nueva versión si esto fuera necesario.

• Actualizar la DML, el DS y la CMDB.

• Comunicar y formar a los clientes y usuarios sobre las funcionalidades de la nueva versión.

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Entregas y Despliegues:








Planificación de entregas.

Es crucial establecer un marco general para el lanzamiento de nuevas versiones que fije una metodología de trabajo. Esto es especialmente importante para los casos de versiones menores y de emergencia, pues en el caso de lanzamientos de gran envergadura se deben desarrollar planes específicos que tomen en cuenta las peculiaridades de cada caso.

A la hora de planificar correctamente el lanzamiento de una nueva versión se deben de tomar en cuenta los siguientes factores:

 

• Cómo puede afectar la nueva versión a otras áreas del entramado TI.

• Qué CIs se verán directa o indirectamente implicados durante y tras el lanzamiento de la nueva versión.

• Cómo ha de construirse el entorno de pruebas para que éste sea fiel reflejo del entorno de producción.

• Qué planes de back-out son necesarios.

• Cómo y cuándo se deben implementar los planes de back-out para minimizar el posible impacto negativo sobre el servicio y la integridad del sistema TI.

• Cuáles son los recursos humanos y técnicos necesarios para llevar a cabo la implementación de la nueva versión con garantías de éxito.

• Quiénes serán los responsables directos en las diferentes etapas del proceso.

• Qué planes de comunicación y/o formación deben desarrollarse para que los usuarios estén puntualmente informados y puedan percibir la nueva versión como una mejora.

• Qué tipo de despliegue es el más adecuado: completo, delta, sincronizado en todas los emplazamientos, gradual...

• Cuál es la vida media útil esperada de la nueva versión.

• Qué impacto puede tener el proceso de lanzamiento de la nueva versión en la calidad del servicio.

• Si es posible establecer métricas precisas que determinen el grado de éxito del lanzamiento de la nueva versión.

Una herramienta clave para formular la planificación de entregas es el Modelo en V, que sirve para identificar los diferentes niveles de test necesarios para aceptar una versión durante el proceso de Validación y Pruebas.


 

 

 

La metodología del Modelo en V consiste en definir, en el brazo izquierdo de la V, las especificaciones del servicio que es necesario cumplir para aceptar una versión. En el brazo derecho se van indicando, de forma paralela, las pruebas mediante las cuales se van a comprobar cada una de las especificaciones de la izquierda.
 

Desarrollo del despliegue.

La Gestión de Entregas y Despliegues es la encargada del diseño y construcción de las nuevas versiones siguiendo las pautas marcadas en las RFCs correspondientes.

 

A veces el desarrollo se realizará "en casa" y muchas otras requerirá la participación de proveedores externos. En este segundo caso, la tarea de la Gestión de Entregas y Despliegues será la de asegurar que el paquete o paquetes de software o hardware ofrecidos cumple o cumplen las especificaciones detalladas en la RFC. Asimismo, la Gestión de Entregas y Despliegues será la responsable de todo el proceso de configuración necesario.

El desarrollo debe incluir, si esto fuera necesario o simplemente recomendable, todos los scripts de instalación requeridos para el despliegue de la versión. Estos scripts deberán tener en cuenta aspectos tales como:

 

• Back-up automático de datos.

• Actualizaciones necesarias de las Bases de Datos asociadas.

• Instalación de las nuevas versiones en diferentes sistemas o emplazamientos geográficos.

• Creación de logs asociados al proceso de instalación.

Parte integrante del desarrollo lo componen los planes de back-out asociados. Éstos tendrán que tomar en cuenta la disponibilidad acordada con los clientes en los SLAs correspondientes.

 

 

 

 

Implementación de la entrega.

Llegó el momento de la verdad: la distribución de la nueva versión, también conocida como rollout.

 

El rollout puede ser de varios tipos:

 

• Completo y sincronizado: se realiza de manera integral y simultánea en todos los emplazamientos.

• Fragmentado: ya sea bien espacial o temporalmente. Por ejemplo, introduciendo la nueva versión por grupos de trabajo o incrementando progresivamente la funcionalidad ofrecida.

El procedimiento de rollout debe ser cuidadosamente documentado para que todas las partes conozcan sus tareas y responsabilidades específicas. En particular, los usuarios finales deben estar puntualmente informados del calendario de lanzamiento y de cómo éste puede afectar a sus actividades diarias.

Es imprescindible determinar claramente:

 

• Los CIs que deben borrarse e instalarse y en qué orden debe realizarse este proceso.

• Cuándo debe realizarse este proceso para diferentes grupos de trabajo y/o localizaciones geográficas.

• Qué métricas determinan la puesta en marcha de los planes de back-out y si éstos deben ser completos o parciales.

Tras la distribución, la Gestión de Entregas y Despliegues debe asegurarse de que:


 

• Se incluya una copia de la versión en la DML.

• El DS incorpore repuestos funcionales de los nuevos CIs.

• La CMDB esté correctamente actualizada.

• Los usuarios están debidamente informados de las nuevas funcionalidades y han recibido la formación necesaria para poder sacar el adecuado provecho de las mismas.

Tras la implementación, la Gestión de Entregas y Despliegues debe ser puntualmente informada por el Centro de Servicios de los comentarios, quejas, incidentes, etc. que la nueva versión haya podido suscitar. Toda esta información deberá ser analizada para asegurar que las próximas versiones incorporen las sugerencias recibidas y que se tomen las medidas correctivas necesarias para minimizar el impacto negativo que puedan tener futuros cambios.

Comunicación y Formación.

Es frecuente, y a su vez un grave error, que cuando se aborden cuestiones de carácter técnico se obvie el factor humano.

 

Salvo contadas excepciones, es necesaria la interacción usuario-aplicación y ésta suele representar el eslabón más débil de la cadena.

Es inútil disponer de un sofisticado servicio TI si los usuarios, debido a una incompleta (in)formación, no se encuentran en disposición de aprovechar sus ventajas.

 

La (in)formación debe estructurarse en distintos niveles:

 

• Los usuarios deben conocer el próximo lanzamiento de una nueva versión y conocer con anterioridad la nueva funcionalidad planificada o los errores que se pretenden resolver para participar, a su discreción, en el proceso.

• Cuando se considere oportuno, se impartirán cursos presenciales o remotos mediante módulos de e-learning sobre el funcionamiento de la nueva versión.

• Se desarrollará una página de FAQs donde los usuarios puedan aclarar las dudas más habituales y puedan solicitar ayuda o soporte técnico en el uso de la nueva versión.

Control del proceso.

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Entregas y Despliegues.

Para que estos informes ofrezcan una información precisa y de sencilla evaluación es necesario elaborar métricas de referencia que cubran aspectos tales como:

 

• Número de lanzamientos de nuevas versiones.

• Número de back-outs y razones de los mismos.

• Incidencias asociadas a nuevas versiones.

• Cumplimientos de los plazos previstos para cada despliegue.

• Asignación de recursos en cada caso.

• Corrección y alcance de la CMDB y la DS.

• Existencia de versiones ilegales de software.

• Adecuado registro de las nuevas versiones en la CMDB.

• Incidencias provocadas por uso incorrecto (formación inadecuada) de la nueva versión por parte de los usuarios.

• Disponibilidad del servicio durante y tras el proceso de lanzamiento de la nueva versión.