¿Os imagináis desde un punto de vista de gestión de IT realizando cincuenta cambios todos los días en un entorno en producción? Si simplemente os pregunto esto sin ninguna explicación, probablemente pensaréis que estoy chalado, igual que lo pensé yo de la primera persona que me lo comentó a mí.

Básicamente para que ambos mundos funcionen correctamente, es necesario que existan unos fuertes lazos de unión a través de la confianza, entre los equipos encargados del desarrollo y el despliegue, con los equipos de operación.

Antes de explicar como se pueden conseguir estos lazos de unión, me gustaría comentaros como desde mi punto de vista, se ven estos grupos. Para le gente de desarrollo y despliegue, los de operación son esos tipos agrios, de mal carácter y que siempre tienen un no o un pero por respuesta a lo que se les plantea. Para los equipos de operación, la gente de desarrollo y despliegue son esos individuos que tratan de colar cualquier cosa y como sea, sin pensar en el más allá, que siempre falla y que a quien luego llaman a horas intempestivas es a nosotros y no a ellos.

Visto así, establecer estos lazos es complicado, pero voy a tratar de describiros como conseguirlo.

El primer objetivo es conseguir que los grupos de operación tengan la confianza suficiente para aceptar con garantias las nuevas versiones que se van a poner en producción. En este sentido, la herramienta que utilizan y con la que se sienten más tranquilos es ITIL y siendo más concretos, la Gestión del Cambio. Muchas organizaciones tienen pesados procesos de gestión del cambio que generan largos periodos de bastantes días entre que se solicita una petición de cambio y es aprobada para su despliegue en producción. Esto supone un importante bloqueo para equipos que intentan implementar Despliegue Continuo. A menudo «frameworks» como ITIL son acusados de imponer este tipo de gravosos procesos. Sin embargo es posible seguir las prácticas y principios de ITIL de una forma ligera para alcanzar los objetivos de una eficiente gestión del servicio y al mismo tiempo posibilitar despliegues rápidos y fiables.

Para aligerar estos procesos de gestión del cambio se puede aprovechar mucho más la figura de cambios estándar, definida en ITIL v3 y que se corresponde con cambios pre-autorizados y de bajo riesgo. Cada organización decidirá que tipo de cambios estándar va a autorizar, el criterio para que un cambio se considere estándar, quién está autorizado para aprobarlos, así como el proceso para gestionarlos – al igual que los cambios normales, deben ser documentados y aprobados. Sin embargo la aprobación puede ser realizada por alguien cercana a la acción a realizar – por ejemplo únicamente el CAB (Change Advidsory Board), pero no siendo necesario tener la aprobación de otros comités como puede ser el comité de gestión de TI o el ejecutivo de negocio.

Como todos sabemos ITIL sigue la doctrina del sentido común por lo que cada cambio que se va a realizar debe de ser evaluado, entre otras cosas y principalmente en términos de riesgo. Con esto y con lo comentado anteriormente, para poder asegurarnos de ejecutar el mayor número de cambios estándar, debemos de reducir el riesgo de los mismos y el valor que estos aportan al negocio, y como os voy a describir, el Despliegue Continuo, puede colaborar en que se cumpla.

En un ciclo de despliegue tradicional, la primera versión suele llevar algo de tiempo (seis meses o un año dependiendo de la complejidad del proyecto). Las versiones posteriores típicamente ocurren a un ritmo regular, pocos meses para una versión mayor o un mes para una menor.

El objetivo del Despliegue Continuo es el de tener una versión disponible cuanto antes y una vez puesta en producción, ya no hacer versiones mayores o menor e, sino micro versiones, tan frecuentes como sea posible. Esto significa en muy corto periodo de tiempo, la versión va a estar en el entorno de producción disponible, lo que obliga a que los equipos de operación junto a desarrollo y despliegue, empiecen a preparar este entorno desde el inicio del proyecto.

Al estar operaciones desde el principio pueden aportar sus requerimientos, dar sus comentarios y que estos se tengan en cuenta durante la construcción y no al final en el momento de ponerlo en producción. Los desarrolladores, al trabajar en entornos idénticos a los de producción, e incluso en los de producción, pueden hacer pruebas mucho más realistas y obtener una retroalimentación, que les lleven a diseñar una arquitectura de software más robusta y fiable.

Si a esto sumamos que los cambios se realizan de forma periódica, y no en modo «Big Bang» como en el método tradicional, los ítems a cambiar son mucho menores y su impacto ante un posible fallo, mucho más reducido. Así mismo, la marcha atrás será más sencilla y rápida.

Igualmente importante para la reducción del riesgo es que la cadena de despliegue sea segura y de garantías. Primero de todo, debe proveer los mecanismos a través de los cuales los riesgos del cambio son evaluados y entonces aplicados. Cada propuesta de cambio en los sistemas, deben ser realizados mediante al control de código. La cadena de despliegue debe obligar a ejecutar pruebas automáticos para determinar si el cambio no romperá el sistema, y hacer los cambios necesarios para desplegar adicionalmente pruebas manuales en entornos de producción en modo «pulsar el botón», con las consiguientes autorizaciones y controles.

Una buena implementación de la cadena debería ser capaz de generar los informes que nos permitan saber exactamente que ha cambiado desde la última vez que se desplegó. Las personas encargadas de aprobar los despliegues pueden usar esta información, más informes de las pruebas manuales y automáticas que se ejecutan a través de la cadena, así como otras métricas tales como el tiempo desde el último cambio, para evaluar el riesgo del cambio. En este sentido es muy importante disponer de una herramienta de despliegue que permita ejecutar las pruebas indicadas y obtener la información necesaria.

Sin embargo en ocasiones, aunque solo intervenga el CAB, puede ser un proceso largo y doloroso. Pero no debería serlo ya que ITIL v3 manifiesta que no son necesarias reuniones presenciales del CAB para aprobar un cambio y este puede hacerse de forma electrónica, siempre y cuando este tenga conocimiento de antemano de la información necesaria para decidir cuando aprobar o no. Esto puede convertir el proceso en algo «legal» y que puede ser ejecutado en segundos.

Para ello, una colaboración cercana entre el CAB y los equipos de desarrollo y de despliegue es también importante a la hora de hacer el proceso de aprobación eficiente. Un posible modo de conseguirlo es que asistan los miembros más relevantes del CAB a cada reunión de planificación de una iteración de desarrollo (a través de una multiconferencia si es necesario). De este modo, pueden ver exáctamente que es lo que está llegando para aprobar, plantear cuestiones y dar comentarios para asegurarse de que estarán tranquilos dando su aprobación cuando llegue el momento.

Si cumplimos con los objetivos descritos anteriormente, reduciendo el riesgo de los cambios y convirtiendo el proceso de gestión de cambios en algo ligero, a través de los cambios estándar y la participación del CAB desde los inicios de cada iteración de software, es muy seguro que satisfagamos con creces el segundo y último de los objetivos, hacer feliz a los equipos de desarrollo y despliegue.

Resumiendo y tras lo expresado anteriormente, creo que es posible utilizando ITIL y el Despliegue continuo, satisfacer las necesidades de dos mundos, desarrollo y despliegue por un lado, y operaciones por el otro.

Eso es todo amigos…