ServiceDesk PlusCaracteristicasGestión de versiones de ITIL

Última actualización: 2 de febrero de 2018

Gestión de versiones simplificada
con 11 mejores prácticas de ITIL

Las mejores prácticas de gestión de versiones de ITIL que se explican aquí se basan en el caso de uso de una empresa de telecomunicaciones de tamaño medio. La compañía enfrentó múltiples problemas que les costaron alrededor del 25% de sus clientes y una disminución en su productividad. La razón principal fue la falta de un proceso y procedimientos de gestión de versiones eficientes. Descubra cómo esta empresa mitigó las fallas de lanzamiento y aumentó su lanzamiento en tres meses.

¿Qué es la gestión de versiones?

"La administración de versiones es el proceso de administrar, planificar, programar y controlar una compilación de software a través de diferentes etapas y entornos" - Wikipedia

"La administración de versiones se trata de compilar, probar e implementar, mientras que la entrega continua se trata de compilar, probar e implementar mediante la automatización". - Charles Betz, analista de investigación , Forrester

"Para mí, la pieza de automatización número uno que hay que buscar es el software de prueba". -Jayne Groll CEO, DevOps Institute

Visión general

Una empresa de telecomunicaciones de tamaño medio perdió alrededor del 25 por ciento de sus clientes durante un período de tres meses debido a múltiples lanzamientos retrasados ​​de software crítico. Claramente, el proceso de administración de versiones existente no fue efectivo y la empresa tuvo que solucionar problemas y llegar a un proceso concreto para aclarar las cosas.

Muestra de documentación del proceso de gestión de implementación y gestión de versiones de software de itil
GUÍA GRATIS

La empresa formó un nuevo equipo de gestión de versiones para evaluar y optimizar el flujo del proceso de gestión de versiones existente. En los siguientes tres meses, el nuevo equipo pudo publicar los lanzamientos pendientes y dos lanzamientos programados de aplicaciones rediseñadas. A continuación, verá cómo el equipo agilizó su proceso de gestión de versiones . Los pasos que tomó el equipo reflejan las mejores prácticas que puede emplear cualquier organización de TI, incluida la suya.

1. Evaluación de los procesos de gestión de versiones existentes

El nuevo equipo quería una imagen detallada del flujo del proceso de gestión de versiones actual. Comenzaron con una serie de sesiones paso a paso con personas clave involucradas en el proceso del software. En estas sesiones, el equipo se enteró de que un software CRM había estado pendiente de lanzamiento durante dos meses después de su finalización.

Según los requisitos del cliente, el software CRM incluyó la liquidación de reclamaciones. También incluyó créditos de servicio y multas para los clientes de telecomunicaciones que enfrentaron problemas relacionados con el tiempo de inactividad, la degradación del servicio y la transferencia de un nuevo plan de facturación. La demora en la implementación del software CRM significó que varios de los clientes no pudieron obtener sus créditos de servicio o reembolsos a tiempo, y que no había un sistema de seguimiento para las solicitudes de estado actualizadas. Aproximadamente el 25 por ciento de los clientes minoristas perdió la paciencia en el sistema y se alejó.

En el proceso existente, los puntos de contacto, la validación y el proceso de verificación no fueron perfectos debido a la adquisición de hardware, el entorno de prueba y la ausencia de un ciclo de lanzamiento acordado.

marco de diagrama de flujo del proceso de gestión de versiones de itil

2. Consolidación de evaluaciones de la gestión de versiones existente

  • Los ciclos de lanzamiento eran aleatorios, en lugar de tener una ventana y frecuencia de lanzamiento estructuradas y acordadas.
  • Los entornos de prueba estaban desactualizados y no estaban disponibles bajo demanda.
  • En muchos casos, las pruebas de regresión tardaron más de tres meses y se eliminaron en muchas implementaciones.
  • Los procesos integrados de control de cambios, con configuración y gestión de versiones, estaban ausentes.
  • La moral general de los equipos estaba baja, debido a una gran cantidad de lanzamientos fallidos y retrasados.

3. Optimización de los sistemas de gestión de nuevas versiones

Para hacer frente a esta situación, el equipo de gestión de la nueva versión siguió algunos consejos de corrección de rumbo, que se enumeran a continuación:

  • Determinación y establecimiento de ciclos de lanzamiento aprobados.
  • Simplificación de procesos y pruebas tempranas.
  • Infraestructura controlada mediante sistema de gestión de la configuración (CMS).
  • Optimización del proceso de control de cambios y automatización.
  • Construyendo el triángulo mágico (proceso integrado de configuración, cambio, lanzamiento e implementación).
  • Teniendo en cuenta medidas y métricas.
  • Taller de formación y sensibilización.

4. Establecimiento del ciclo de vida de la gestión de versiones

Una vez que el equipo tuvo una idea del estado actual del proceso de gestión de versiones, decidió centrarse en definir y establecer un ciclo de versiones acordado. Para comprender la frecuencia de lanzamiento en producción, el equipo tuvo que comprender la frecuencia de las pruebas no funcionales. Después de una discusión con los equipos de ingeniería, el equipo concluyó que el proyecto requería pruebas de regresión, rendimiento e integración.

El ciclo de lanzamiento se desarrolló para lograr lo siguiente:

  • Cree una oportunidad para discutir de manera significativa cualquier prueba no funcional que el software pueda necesitar.
  • Formule un cronograma para actualizar el lanzamiento esperado de una característica o funcionalidad a las partes interesadas.
  • Establezca una rutina con la que todos los equipos puedan alinearse (incluido el marketing y la ingeniería).
  • Asegurar a los clientes de que sus pedidos serán de buena calidad y se entregarán dentro del plazo acordado.

El equipo de administración de versiones comenzó experimentando en un ciclo semanal, pero el plan resultó inviable. El entorno de la base de datos del cliente no se pudo actualizar rápidamente. Luego, el equipo probó ciclos de dos semanas. No hubo objeciones inmediatas de los participantes, pero el ciclo de dos semanas falló las dos primeras veces. Una vez que superaron algunos cuellos de botella en el cambio de entorno y automatizaron algunas de las pruebas, el equipo decidió que el ciclo de dos semanas era factible.

Finalmente, el equipo estableció un ciclo por el cual, cada dos semanas, el código listo para producción del equipo de ingeniería se puso en prueba del sistema. Dos semanas después, lanzaron ese código a producción.

El ciclo de lanzamiento no se trataba de cuándo el cliente quería el lanzamiento. Se trataba de cuándo el equipo podía entregarlo al mercado con el nivel de calidad deseado. Sin embargo, cuando el equipo involucró a los clientes y los convirtió en los tomadores de decisiones, ¡los clientes comenzaron a apoyarlo!

5. Simplificación de procesos ligeros para acelerar las versiones

Los procesos ligeros son aquellos que no requieren aprobaciones burocráticas prolongadas o reuniones interminables para llegar a un acuerdo. Por lo general, solo requieren el nivel mínimo aceptable de entrada y salida. Lo que les falta en masa y burocracia, lo compensan en respuesta al cambio y la adopción popular.

Sin embargo, la base de este enfoque era una cuestión espinosa de documentación. El equipo necesitaba registrar lo que se hizo y cómo se hizo. De lo contrario, sería imposible revisar o mejorar la situación.

6. Documentación y herramientas en la gestión de versiones

La empresa decidió avanzar hacia un estándar de documentación que permitiera a las personas (técnicas y de otro tipo) leer y actuar sobre los documentos, en lugar de dejarlos en el estante.

El equipo de ingeniería eligió Confluence, una herramienta comercial, para documentar de forma colaborativa su trabajo. Utilizaron el software para crear una documentación mínima pero eficaz de lo que acordaron construir en cada ciclo de trabajo. Registraron lo que construyeron, cómo lo hicieron y lo que se requería para que funcionara. El nuevo equipo vio el valor de este enfoque y lo implementó (tanto el enfoque como la herramienta) a todos los demás involucrados en el proceso.

Luego se creó una secuencia de tareas para liberar el software de los equipos de ingeniería. La lista de tareas incluía:

  • Garantizar la entrega, directamente desde el sistema de gestión de control de fuente.
  • Especificar la nomenclatura y definir cómo se ejecutará cada elemento (código ejecutable, scripts de base de datos, etc.) y en qué plataformas.
  • Se realizó un ensayo utilizando un código ficticio para cada elemento. La secuencia se probó mientras se documentaba lo que hizo el equipo y cómo lo hizo. Esto formó la base de las instrucciones de instalación.
  • El siguiente paso fue llevar a las personas que implementarían la versión real a través de otro ensayo, utilizando solo la documentación creada por el equipo.
  • Las personas involucradas ampliaron, modificaron y mejoraron las instrucciones del equipo. El proceso se volvió más inclusivo y todos contribuyeron a la documentación. Como formaban parte de su definición, el proceso se adoptó más ampliamente, con mejor calidad.
  • Después de cada lanzamiento, el equipo revisó el proceso, examinó la documentación e identificó los cambios realizados durante el lanzamiento. También analizaron cómo se podría mejorar la documentación e incorporaron las mejoras al proceso.

7. Establecer una infraestructura controlada usando CMS (Configuración, gestión de cambios y versiones)

El alcance

Una infraestructura de lanzamiento asegura que todo esté en su lugar para implementar software y permitir su uso. El equipo de administración de versiones se tomó el tiempo para desarrollar un sistema de administración de configuración (CMS) y comenzó por construir la estructura de árbol y la jerarquía de elementos de configuración (CI).

Gestión de versiones, cambios y configuración de software

Evaluación del proceso de gestión de la configuración

Lista de verificación y actividades de gestión de implementación y lanzamiento de ITIL

Taller de descubrimiento y herramientas

El equipo llevó a cabo talleres con los equipos de infraestructura, desarrollo de software de aplicación y administración para decidir sobre los procesos de configuración, cambio y lanzamiento. El flujo conceptual acordado, desde la perspectiva de una herramienta, se muestra a continuación.

Proceso de gestión de implementación y lanzamiento de aplicaciones web ITIL

8. Creación de una infraestructura de gestión de versiones
(simplificación del proceso de control de cambios y automatización)

La infraestructura de lanzamiento cubría el hardware, el almacenamiento, las conexiones de red, el ancho de banda, las licencias de software, los perfiles de usuario y los permisos de acceso. Los servicios humanos y las habilidades también formaron parte de la infraestructura de lanzamiento. Por ejemplo, si fuera necesario instalar y configurar un software especializado, no se podría excluir la disponibilidad o el costo de incorporar dichas habilidades en el plan de infraestructura.

Es fundamental descubrir los cuellos de botella ocultos en la adquisición del hardware necesario o las habilidades faltantes (por ejemplo, la configuración de redes seguras). El equipo tuvo que resolver estos problemas antes de la entrega.

Sin embargo, ese estándar no fue fácil de mantener. El equipo se esforzó por poner en marcha la infraestructura de lanzamiento tan pronto como comenzaron el proyecto. Sin embargo, incluso después de un plazo de seis semanas, todavía estaban esperando memoria especializada y discos duros para los servidores de prueba.

Identificación de tareas de automatización

El equipo identificó las tareas de construcción y prueba que podrían automatizarse y propuso los criterios y definiciones para cambios normales, estándar y de emergencia. La automatización les permitió realizar tareas repetitivas sin ocupar valiosos recursos humanos. También calificaron una serie de cambios estándar basados ​​en el riesgo, la repetibilidad y el tiempo involucrado en la ejecución.

Los cambios se agruparon para alinearse con el ciclo de lanzamiento de dos semanas. Los equipos de cambio trabajaron con los equipos de lanzamiento e implementación sincronizar con el calendario de lanzamiento, los tipos de lanzamiento y el soporte del ciclo de vida temprano.

Paquete manual versus automático

Antes de su participación en el proyecto, los equipos de ingeniería creaban manualmente paquetes desplegables. Debido a esto, no se garantizaba que cada nuevo paquete fuera el mismo que el anterior. De hecho, ni siquiera estaba garantizado que fuera el software que habían estado construyendo, ¡y mucho menos que funcionara! A menudo, el personal técnico necesitaba días para crear un paquete con las funciones, en una estructura que pudiera implementarse.

Aceptación y verificación del servicio

El equipo de gestión de versiones elaboró ​​inmediatamente una estructura y un criterio de aceptación del servicio para el paquete desplegable que estaba entregando el equipo de ingeniería y les ayudó a estandarizar el paquete. Esto desencadenó la implementación de procesos automatizados para construir el software en esa estructura consistente para cada punto de lanzamiento.

Como el equipo había automatizado el proceso de verificación de los criterios de aceptación, la ejecución estaba garantizada. Por ejemplo, el código debe someterse a una prueba unitaria antes de la entrega y la prueba debe implementarse para garantizar que se pueda realizar. Como resultado, el equipo de administración de versiones pudo empaquetar, versionar, probar e implementar el código terminado con un solo comando, en muy poco tiempo.

La nueva norma de ciclos de lanzamiento

El ciclo de lanzamiento recientemente establecido significó que un lanzamiento tenía que ser probado para regresión, rendimiento e integración en solo dos semanas, para que el equipo pudiera lanzarlo en producción. El equipo pudo superar diferentes tipos de pruebas (integración y rendimiento) al tener entornos separados para cada tipo. Sin embargo, el desafío de acomodar dos meses de pruebas de regresión en una ventana de dos semanas parecía imposible. Así es como lo hicieron.

  • Primero, el equipo inició un ejercicio de priorización. El cliente identificó las pruebas de regresión de alta prioridad como el mínimo que aceptarían como prueba de que existía la funcionalidad anterior.
  • Luego, el equipo comenzó a automatizar estas pruebas. Las pruebas de aceptación posteriores también se automatizaron para garantizar que el equipo pudiera realizar pruebas de regresión en cada versión en solo horas, en lugar de días.

9. Construcción del triángulo mágico
(procesos integrados de configuración, cambio, lanzamiento y despliegue)

Si bien la combinación de la gestión de la configuración, el proceso de control de cambios y los procesos de gestión del lanzamiento y la implementación se integraron sin problemas, todo el proceso requirió el vértice de las personas para ser posible.

Plan de implementación de la gestión de versiones de ITIL

Funciones y responsabilidades del equipo de gestión de versiones

El equipo de administración de versiones respaldó esta importancia al establecer que el administrador de versiones designado esperaría que el software estuviera listo en el momento acordado por los equipos. El equipo hizo un arreglo que el administrador del programa (en este caso, el usuario final y el cliente) explicaría a los equipos por qué la publicación era importante.

El equipo solicitó que los equipos de ingeniería se aseguraran de que el software que entregaron cumpliera con un estándar (versionado, probado, documentado y empaquetado). El equipo también estableció que solicitarían este paquete estándar para cada ciclo de lanzamiento. Esto hizo que el proceso automatizado fuera más fácil y consistente, y permitió la integración de comentarios.

10. 9 métricas clave de gestión de versiones

Las siguientes métricas de gestión de versiones se midieron continuamente para ajustar el proceso de gestión de versiones.

  • Número de cambios pendientes de futuras versiones del sistema (acumulación).
  • Número de cambios exitosos en una versión.
  • Número de cambios fallidos en una versión (porcentaje de cambios fallidos).
  • Número de interrupciones provocadas por un lanzamiento.
  • Número de incidencias provocadas por la liberación.
  • Porcentaje de lanzamientos entregados a tiempo para las pruebas de control de calidad.
  • Porcentaje de lanzamientos entregados a tiempo para producción.
  • Porcentaje de emisiones por prioridad o tipo.
  • Tiempo de inactividad total de liberación, en horas.

Instantánea de las métricas capturadas, desde agosto de 2014 <ETH> febrero de 2015

Métricas de gestión de versiones de ITIL

El poder está en invertir en las personas

Durante el transcurso de toda la transformación, el mayor activo fueron las personas. El equipo de administración de versiones tomó sus perspectivas, problemas y desafíos de manera justa y transparente, e informó a la administración de los mismos. Incluso enumeraron a algunos de los primeros usuarios como agentes de cambio. Invirtieron mucho en capacitación, concienciación y comunicación, instituyendo así un mecanismo de recompensa por reconocer el comportamiento positivo y el intercambio de conocimientos.

11. Taller de capacitación y sensibilización para equipos de gestión de cambios, configuración y versiones.

Los siguientes talleres se realizaron para los equipos de gestión de configuración, cambios y versiones, sin excepción. Los gerentes de línea también estuvieron disponibles para validar la efectividad de los talleres.

  • Fundamentos del taller de gestión de versiones (un día).
  • Taller básico de DevOps (dos días).
  • Taller de métricas y medición (un día).
  • Taller de acción de lanzamiento y despliegue, que incluye roles, responsabilidades, cronograma y entregables (un día).

El resultado del taller de cinco días fue una mayor claridad para los equipos involucrados en varios puntos de contacto, entregables e impacto comercial general. Se distribuyó una hoja de referencia rápida para resumir los puntos clave de aprendizaje de la capacitación.

Lecciones aprendidas

  • La gestión de los cambios organizacionales fue fundamental para que todos los equipos trabajaran en una visión y objetivos compartidos que lograran resultados comerciales definidos.
  • La decisión de la disponibilidad del lanzamiento tenía que basarse en el producto o la aplicación, incluso más que en las necesidades de urgencia del usuario final.
  • Criterios realistas del ciclo de lanzamiento, en consenso con las partes interesadas.
  • Integración de procesos y herramientas (incluidas las necesidades del usuario final) alineados con la configuración, el cambio y los procesos de gestión de lanzamiento y despliegue.

Línea de fondo

Basándose en la experiencia del equipo de gestión de versiones trabajando con otros en el proyecto, se dieron cuenta de que una buena gestión de versiones requiere trabajo duro, resolución y excelente comunicación. Sin embargo, la mayor habilidad es la capacidad de revisar, aprender y adaptar las mejoras con la colaboración efectiva de las personas junto con la configuración del triángulo mágico, el cambio y los procesos de administración de lanzamiento e implementación.

Implemente lanzamientos con mayor transparencia y menos riesgos.

ITIL ® es una marca registrada de AXELOS Limited. Todos los derechos reservados.

Confiado por las mejores organizaciones del mundo