DevOps, ¿Qué es?

Para las metodologías de desarrollo de software la meta final será siempre entregar un producto funcional al usuario. Esto comprende un conjunto de pasos que abarca desde la conceptualización de la aplicación hasta su instalación y mantenimiento. Con una visión cerrada y limitada del manejo de la aplicación, el equipo de desarrollo trabaja incansablemente para encontrar la manera óptima de poder entregar en tiempo y forma el resultado de su trabajo. Al sólo preocuparse de construir y liberar, el equipo de desarrollo entra en una constante fricción con el área de sistemas encargada de implementar esta nueva aplicación: Infraestructura (Operaciones).

A fin de cuentas, el equipo de Infraestructura es el último manipulador de un sistema de software previo a su liberación a ambiente de Producción. Historias de terror se cuentan de ese paso del ambiente de Desarrollo a Producción: conflictos, desvelos, fines de semana, marchas de la muerte. Esto genera un esfuerzo mal enfocado donde por un lado el área de Desarrollo busca demostrar que la construcción del producto fue correcta para poder alcanzar su liberación, mientras que el área de Infraestructura se dedica a demostrar que aunque por fuera la manzana es roja, en su interior guarda un conjunto de problemas al intentar ser instalado. Conflicto seguro entre las áreas de Desarrollo e Infraestructura.

Acuñado por Patrick Debois [1] en 2009 para un evento tecnológico de nombre DevOpsDays en Bélgica, el término DevOps no tiene una definición formal. Esto genera un conjunto de definiciones que enriquecen el alcance y características del concepto. DevOps no es un software, no es un título/puesto, no es un estándar. No formalizado de manera escrita, el movimiento DevOps es generado de practicante a practicante, a partir del conjunto de experiencias reales que se comparten por medio de una comunidad que colabora de forma descentralizada y abierta. Basta revisar el hashtag #Devops en Twitter para verificar la constante participación y flujo de ideas al respecto.

Con la interacción de los conceptos de Ágil, Kanban, Integración Continua y Cloud Computing el movimiento reúne al área de Desarrollo e Infraestructura en una visión global en el ciclo de vida de la aplicación para la entrega de valor al negocio. Ver Figura 1.

Uso de ágil y otras metodologías de software

Las metodologías ágiles se destacan por la continua entrega de pequeños pedazos de código funcional a un ritmo y velocidad. Entregas que solo abarcan el ciclo de vida de software y al área de Desarrollo, dejando de fuera todo aquello que conlleva la administración de la configuración y la preparación de los componentes para su liberación a Producción.

El ritmo generado por las metodologías ágiles como Scrum y Kanban empuja componentes al área de Pruebas e Integración para que al finalizar de manera exitosa, se entregue a Infraestructura de manera continua y rápida para su instalación, siendo un problema cuando Pruebas o Infraestructura tienen la costumbre de liberar en ventanas de tiempo ya definidas y controladas. Esto genera presión entre todas las áreas involucradas, no todos fueron preparados para trabajar ágilmente y ahora el exceso de entregables rompe con las rutinas prestablecidas de trabajo.

En el caso de peticiones continuas para la resolución de nuevas funcionalidades o incidentes en el código con un flujo de trabajo limitado se implementa Kanban. Kanban que utiliza la teoría de restricciones sobre el trabajo en progreso (WIP), este da las herramientas para que no importando el área involucrada el trabajo sea atendido ágilmente y se vea como un todo y no silos de funcionalidad en sistemas.

Amplia disponibilidad de virtualización en la nube

Si las liberaciones continuas alteran la operación en el área de Infraestructura, la administración, prueba y configuración en el ambiente de Producción del nuevo producto se vuelve algo complejo, ya que los tiempos de implementación y los respectivos ambientes de trabajo, deben de cumplir con los requisitos del producto para su funcionamiento (ej. El ambiente de Desarrollo nunca es igual al de Producción). La complejidad de esto se resuelve con la virtualización de ambientes, que pueden crearse y atenderse de una manera tan rápida que vaya a la par de las entregas del área de desarrollo. Además de utilizar máquinas virtuales, también se está popularizando la utilización de contenedores, como Docker. Si se trabaja con un nuevo desarrollo, se debe de preparar todos los elementos relacionados de ambiente al mismo tiempo, pruebas, control de versiones, etc.

Esto permitirá involucrar al área de Infraestructura desde el inicio del proceso de desarrollo y estará lista para avanzar con el proyecto. A esta respuesta a la metodología ágil de desarrollo se le llama Infraestructura Ágil. La administración de la configuración es un tema importante para la administración de los ambientes virtuales, así como la administración de la infraestructura como código bajo esquemas como SaaS y APIs que permiten el manejo de la infraestructura en la nube. Esto disminuye el impacto de la entrega continua generada por las metodologías ágiles.

Incremento en las entregas a producción

Con ambos escenarios en la mesa, se forma el movimiento DevOps que remueve las barreras entre Infraestructura y Desarrollo para generar valor al cliente. Con un esfuerzo combinado se busca generar la inercia suficiente para responder ante el cambio continuo del negocio.

Generar una entrega continua exige un manejo ágil en el desarrollo de software y la infraestructura, flujos continuos de trabajo bajo tiempos definidos.

Se debe revisar la composición de los procesos del área de tecnología para poder mapear el valor generado y eliminar el desperdicio existente entre tareas. Conviene implementar una política de cero tolerancias a errores y si estos se presentan, tener la capacidad de detener el flujo de trabajo tanto en Desarrollo como en Infraestructura para verificar la situación. Para alcanzar la mejora continua se debe de resolver desde el principio cualquier error que se presente.

Los silos que se generan entre las áreas que promueven la liberación de la aplicación a producción deben de desaparecer, la integración entre las áreas de Desarrollo e Infraestructura debe ser completa en el sentido de responsabilidad sobre los componentes que se generan.

Los problemas son compartidos, se tiene que superar la visión cerrada que cada área tiene sobre las responsabilidades que desempeña. Trabajando con la filosofía de que el área de Tecnología es un gran sistema que trabaja en conjunto para generar valor al cliente esto facilita el compromiso de las áreas involucradas.

Los problemas al liberar a Producción no son problemas individuales de las áreas sino son problemas de negocio que restan la generación del valor al cliente. Se tieneque enfocar el esfuerzo en hacer con calidad los productos tecnológicos, de forma integral (Desarrollo-Infraestructura) y no sólo generar productos por generarlos. La generación del producto debe someterse a métricas que evalúen toda la línea de liberación, para poder implementar la mejora continua. Las entregas se realizarán de manera más rápida al negocio, generando el valor esperado.

La innovación estará presente al momento de generar la colaboración entre áreas. Toda esta mejora en proceso y administración se ve apoyada por la automatización del software para realizar las tareas, desde los sistemas de administración de la configuración, pasando por los sistemas de pruebas automáticas, hasta la generación automatizada de ambientes virtuales para la puesta en marcha de los productos tecnológicos. Estos elementos técnicos ya existían el mercado, ahora con DevOps se les da relevancia y apoyan para que el flujo de trabajo sea continuo en el proceso de liberación de productos.

Todo esto implica un cambio cultural, una reestructuración de la relación entre Desarrollo e Infraestructura para buscar el bien común del negocio y generar valor al cliente. ¿Complicado? Solo el tiempo lo dirá, la madurez de las áreas y la organización debe permitir ejecutar este nuevo enfoque sin problema. Esos raspones que existen entre Desarrollo e Infraestructura pueden sanar si se implementa una filosofía de métodos ágiles y nos empeñamos en alcanzar la colaboración y comunicación que los distinguen.

Referencias

[1] Barton Geroge, DevOpsDays Austin: Patrick Debois Recuperado de https://www.youtube.com/watch?v=xL3iW-F3Gqw

[2] CityTV.nl, T-DOSE 2010, Dev/Ops to DevOps, Patrick Debois and Kris Buytaert. Recuperado de https://www.youtube.com/watch?v=ty6iHN4EilY