7. Gestión de versiones (2015)

Resumen Español
Universidad Universidad Autónoma de Barcelona (UAB)
Grado Ingeniería Informática - 3º curso
Asignatura Models de qualitat en la Gestió de les TIC
Año del apunte 2015
Páginas 7
Fecha de subida 03/04/2016
Descargas 18
Subido por

Vista previa del texto

Gestión de versiones 1. Visión general - Gestión de versiones: encargada de la implementación y control de calidad de todo el SW/HW instalado en el entorno de producción. Colabora con la de Cambios y Configuraciones para asegurar la actualización permanente de la CMDB. Además, mantiene actualizada la DSL (Biblioteca Software Definitivo) y el DHS (Depósito Hardware Definitivo).
Cabe destacar: Todo el proceso debe estar monotorizado para asegurar que la CMDB, DSL y DHS están actualizadas permanentemente y cuando se instala una nueva versión, los cambios deben verse reflejados en CMDB, DSL y DHS.
2. Introducción y objetivos Tiene la misión de diseñar, poner a prueba e instalar en el entorno de producción los cambios preestablecidos con una cuidadosa planificación y coordinación con el resto de proceso.
Sus principales objetivos son:  Establecer una política de implementación de nuevas versiones de HW y SW e implementarlas en el entorno de producción tras su verificación.
 Garantizar que el proceso de cambio cumpla las especificaciones de la RFC correspondiente.
 Asegurar, en colaboración con la Gestión de Cambios y Configuraciones, que todos los cambios se ven correctamente reflejados en la CMDB.
 En la DSL archivar copias idénticas del software en producción y su documentación  Mantener actualizado el Depósito de Hardware Definitivo (DHS).
Sus principales beneficios son:  El proceso de cambio se realiza sin deterioro de la calidad de servicio.
 Las nuevas versiones cumplen objetivos propuestos.
 Se reduce el número de incidentes por incompatibilidades con otro SW/HW  El proceso de pruebas asociado permite conocer opinión de los usuarios  El buen mantenimiento de la DSL impide que se pierdan copias de los archivos fuente.
 Se reduce el número de copias de software ilegales.
 Control centralizado del software y hardware desplegado.
 Protección contra virus y problemas asociados a versiones de software incontroladas.
Sus principales dificultades son:       No hay una clara asignación de responsabilidades No hay entorno de pruebas adecuado donde testear de forma realista Resistencia en los diferentes departamentos a la centralización del proceso de cambio.
Cambios sin tener en cuenta a la Gestión de Versiones (se cree que sólo son responsabilidad de un determinado grupo de trabajo) Resistencias a aceptar posibles planes de "back-out". Ciertos entornos de producción pueden elegir "ignorar" lo problemas que una nueva versión puede provocar en otras áreas y resistirse a volver a la última versión estable.
La implementación sincronizada de versiones en entornos altamente distribuidos 2.1 Conceptos básicos  Versión: 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 están determinadas por la RFC correspondiente.
Las versiones pueden clasificarse, según su impacto en la infraestructura TI, en:  Versiones mayores: importantes despliegues de SW/HW. Introducen novedades en funcionalidad, características técnicas, etc.
Representación: 1.0, 2.0...
 Versiones menores: corrección de varios errores conocidos puntuales Representación: 1.1, 1.2, 1.3….
 Versiones de emergencia: modificaciones que reparan de forma rápida un error conocido.
Representación: 1.1.1, 1.1.2… Evolución temporal de una versión: Despliegue de nuevas versiones (responsabilidad: Gestión de Cambios). Opciones:  Versión delta: sólo se testean e instalan los elementos modificados.
Ventaja: simplicidad / Peligro: pueden aparecer problemas en el entorno de producción  Versión completa: se distribuyen todos los elementos afectados, modificados o no.
Ventaja: mejor probabilidad de incidentes  Paquete de versiones: distribución sincronizada de diferentes paquetes de versiones.
Ventaja: mayor estabilidad entorno TI Idea: pensado para una migración a un nuevo SO que requiere HW más avanzado.
  DSL (Biblioteca Software Definitivo): debe contener copia de todo el software instalado en el entorno TI (SO, aplicaciones, documentación y controladores), histórico completo de versiones de ese SW y se le deben realizar back-ups periódicos.
DHS (Depósito Hardware Definitivo): contiene piezas de repuesto para los CIs en el entorno de producción.
3. Proceso Principales actividades de la Gestión de Versiones:         Establecer política de planificación para la implementación de nuevas versiones.
Desarrollar o adquirir de terceros las nuevas versiones.
Poner a prueba las nuevas versiones en un entorno que simule el entorno de producción.
Validar 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 DSL, el DHS y la CMDB.
Comunicar y formar a los clientes y usuarios sobre las funcionalidades de la nueva versión.
3.1 Planificación 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.
CIs que se verán directa o indirectamente implicados durante y tras el lanzamiento Cómo ha de construirse el entorno de pruebas para ser reflejo del entorno de producción.
Planes de back-out son necesarios y cuándo y cómo implementarlos 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/formación deben desarrollarse para informar a los uuarios Qué tipo de despliegue es el más adecuado: completo, delta… 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.
3.2 Desarrollo Cuando el desarrollo es realizado por proveedores externos, la Gestión de Versiones debe asegurar que el paquete de SW/HW ofrecido cumple las especificaciones en la RFC.
El desarrollo debe incluir todos los scripts de instalación necesarios 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 BD asociadas.
 Instalación nuevas versiones en diferentes sistemas o emplazamientos geográficos.
 Creación de logs asociados al proceso de instalación.
3.4 Validación Deben realizarse pruebas de validación de carácter técnico y funcional con usuarios reales, incluyendo incluir los planes de back-out para asegurarnos que se podrá volver a la última versión estable de una forma rápida, ordenada y sin perdidas de valiosa información.
Las principales actividades realizadas en el proceso de prueba deben incluir:  Pruebas del correcto funcionamiento de la versión en un entorno realista.
 Pruebas de los procedimientos automáticos o manuales de instalación.
 Listas de "bugs" o errores detectados, si se diera el caso.
 Pruebas de los planes de back-out.
 Documentación para usuarios y personal de servicio.
La Gestión de Cambios se encargará de realizar la validación final.
3.5 Implementación El rollout (distribución de la nueva versión) puede ser de varios tipos:  Completo y sincronizado: integral y simultáneamente en todos los emplazamientos.
 Fragmentado: ya sea bien espacial o temporalmente.
Debe ser documentado para que todas las partes conozcan sus tareas y responsabilidades específicas. Los usuarios finales deben estar informados del calendario de lanzamiento.
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  Que métricas determinan la puesta en marcha de los planes de back-out y si estos deben ser completos o parciales.
Tras la distribución la Gestión de Versiones debe asegurarse de que:  Se incluya una copia de la versión en la DSL.
 El DHS incorpore repuestos funcionales de los nuevos CIs.
 La CMDB esté correctamente actualizada.
 Los usuarios están 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 Versiones debe ser puntualmente informada por el Service Desk de los comentarios, quejas, incidentes, etc. que la nueva versión haya podido suscitar.
3.6 Comunicación y formación Se debe tener en cuenta la interacción usuario-aplicación (a veces es el eslabón más débil de la cadena). La (in)formación debe estructurarse en distintos niveles:  Los usuarios deben conocer el próximo lanzamiento de una nueva versión.
 Conocer con anterioridad la nueva funcionalidad planificada o los errores que se pretenden resolver para participar el proceso.
 Las pruebas de carácter funcional: realizadas por un selecto grupo de users finales.
Se documentará la experiencia subjetiva del user, sus comentarios y sugerencias y dudas.
 Posibilidad de hacer cursos presenciales o remotos sobre funcionamiento de la versión.
 Desarrollo página de FAQs para aclarar dudas.
4. Control de proceso Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Versiones. Deben cubrir aspectos como:  Número lanzamientos de nuevas versiones y sus incidencias asociadas.
 Número back-outs y razones de los mismos.
 Cumplimientos de los plazos previstos para cada despliegue.
 Asignación de recursos en cada caso.
 Corrección y alcance de la CMDB y la DHS. Y registro de las nuevas versiones en la CMDB.
 Existencia de versiones ilegales de software.
 Incidencias provocadas por uso incorrecto 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.
5. Caso práctico La Gestión de Cambios ha aprobado un RFC que tiene como principales objetivos:  Aumentar la capacidad de los servidores de Internet para mejorar su conectividad y capacidad de respuesta.
 Desarrollar una serie de WebServices que permitan  o Integrar directamente el sistema de pedidos online en el ERP de la empresa.
o Realizar un seguimiento de todo el proceso de pedido.
o Gestionar remotamente junto a los proveedores toda la cadena de suministro.
Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación La Gestión de Versiones es la encargada del proceso de desarrollo, compra, prueba y distribución de las nuevas versiones de hardware y software asociadas. Para ello: - Evalúa las necesidades del nuevo hardware Hace compra y configuración (con las Gestiones de Capadidad y Disponibilidad) Contacta con sus proveedores habituales para establecer especificaciones del SW Se compran servers nuevos Crea scrips de traducción para salvar nuevos datos en versión anterior - - Establece calendario de pruebas con usuarios reales para que estos puedan probar y "aprobar" el nuevo servicio.
Planifica un despliegue en dos fases: o Se implementa toda la estructura web pero los datos no se incorporan directamente en el ERP de la empresa.
o Se completa el proceso con la integración mediante WebServices de los pedidos web en el ERP.
Se desarrolla manual de usuario para la nueva versión Se crea página de FAQs Se informe a los users de la nueva versión y se instala Se guarda una copia maestra de todo el software en la DSL.
Se actualiza la CMDB.
...