DevOps: rompiendo las barreras entre desarrollo y operaciones bajo el marco de la agilidad, la ISO 20000 y la ISO 15504/12207

Escrito por Javier Garzas, María Morales y Carlos Manuel Fernández
A la gente de Quora le gusta comentar cómo entre las 12:00 am y las 23:59, el 25 de abril hicieron… 46 pasos a producción, para ellos fue un día como otro cualquiera; aplican DevOps  y “Continuous Deployment”. Necesitan seis o siete minutos, de media, para pasar un cambio en desarrollo a producción. Los desarrolladores solo necesitan un comando para pasar a producción su código: git push (Garzás, 2013a).
Otro de los casos de estudio DevOps más populares es lo que logró Flickr, llegaron en su día  más de 10 despliegues diarios (Garzás, 2013b).
Como comenta Gene Kim (Kim, 2014), las organizaciones IT se enfrentan hoy a dos maneras de ver la creación y explotación de las TI, e incluso de crear negocios: la visión tradicional, basada en la separación entre desarrollo y operaciones y la ágil, que llevada a operaciones se conoce como DevOps y que rompe las barreras entre ambos mundos.
Aunque la idea es más antigua, el término “DevOps” como tal se popularizó en 2009, debido a los “DevOps Days” de Bélgica (Debois, 2009), que luego se han repetido en varios países. DevOps es la abreviatura de “development and operations” (desarrollo y operaciones).
DevOps es una tendencia cuyos seguidores crecen rápidamente, sobre todo entre las medianas empresas, más agiles para el cambio, en la que desarrollo y operaciones colaboran en un mismo equipo (y no tanto en departamentos separados y aislados) para asegurar que los cambios en el software se ejecutan lo más rápidamente posible y con el mínimo de problemas.
DevOps aplica principios nacidos en el desarrollo ágil a operaciones, permitiendo al negocio maximizar la velocidad de las entregas de funcionalidades del producto, mejorando la experiencia del usuario, aumentando la capacidad de innovar por parte del equipo y aportando valor al cliente lo más rápidamente posible.

Los procesos en los que se basa DevOps

Adoptar en una organización este movimiento implica a las personas, a los procesos y a la tecnología; no se puede tener éxito si no se consideran estos tres aspectos mencionados.
Sin venir dados en ninguna norma o modelo, la comunidad ágil y por extensión la DevOps ha ido configurando de manera ad hoc un conjunto de procesos y prácticas clave a la hora de implantar el Devops, destacando:

• Planificación de Releases: conjunto de historias de usuario agrupadas por “releases” o versiones del producto que se van a poner en producción, a disposición de los usuarios incrementando el valor para estos respecto de la anterior. Ayuda, al Product Owner y al equipo, a decidir cuánto se debe desarrollar y cuánto tiempo se tardará antes de tener un producto entregable.

• Integración Continua: se basa en integrar el software (compilarlo, probarlo y desplegarlo) automáticamente (con herramientas como Jenkins) lo más frecuente posible (todos los días o en cada “commit”), y así poder detectar fallos cuanto antes, rápidamente. Es una de las bases de la entrega continua o continuous delivery.

• Entrega Continua: es  el proceso de poder liberar software (con la seguridad de que no va a fallar en producción) rápidamente, lo cual se basa, obviamente, en tener todo automatizado al máximo, y en un robusto proceso de pruebas.

• Pruebas Continuas y automatizadas: reducir potencialmente la pérdida de tiempo resultante de la ejecución de pruebas manuales. Algunas técnicas de testing típicas en este contexto de integración continua y/o devops:

1. 1. Smoke Test: conjunto de comprobaciones preliminares a las que se somete una versión para evaluar si funciona correctamente y la calidad con que ha sido desarrollada.
   2. Pruebas Exploratorias: se define como el aprendizaje, el diseño de casos de prueba y la ejecución de las pruebas de forma simultánea. Se refiere a ejecutar pruebas a medida que se piensa en ellas.
   3. BDD: es un proceso de desarrollo software basado en el desarrollo guiado por pruebas, TDD (primero el desarrollador escribe un caso de prueba automatizado, a continuación produce un mínimo de código para pasar la prueba y finalmente refactoriza).
   4. Pruebas Unitarias: prueba o pruebas de todos los elementos unitarios que componen un proceso. Sirve para asegurar que cada uno los elementos funcionen correctamente por separado. Luego con las Pruebas de Integración se podrá asegurar el correcto funcionamiento del sistema, o de la versión.

• Supervisión Continua y Retroalimentación de la versión en producción: para ampliar el aprendizaje y acelerar la mejora de proceso

Las tecnologías juegan también un papel determinante, herramientas como Puppep, Vagrant y Docker se han consolidado, llevando “la administración de sistemas” al desarrollo y han ayudado a la adopción de DevOps ya que sirven para administrar la configuración de sistemas, automatizando las tareas repetibles, simular entornos virtuales…

La visión tradicional y/o la visión ágil

Pero frente a los anteriores procesos, tradicionalmente, las organizaciones trabajan estructuradas en dos grandes áreas, separadas por una “gran muralla”: por un lado desarrollo, usando sus propios modelos, normas (como la ISO/IEC 12207) y metodologías, y por otro lado el de operaciones con sus modelos y metodologías, destacando ISO/IEC 20000 e ITIL
Un ejemplo típico de procesos de desarrollo son los de la ISO/IEC 12207 – ISO/IEC 15504, buenas prácticas a nivel de procesos para el desarrollo y mantenimiento software (Garzás, 2010). A continuación podemos observar la Tabla 1 con los procesos de este modelo, que además está en el modelo y hoja de ruta de AENOR, en concreto los procesos de los niveles de madurez 2 y 3.

Por otro lado, si nos vamos el entorno de operaciones, es típico encontrar la ISO/IEC 20000, para la gestión del servicio que ofrecen las tecnologías de la información, aunque en la versión del 2011 se habla de la calidad del servicio en términos generales. Los procesos que contempla este modelo son los siguientes (Tabla 2):

En las organizaciones más clásicas, con departamentos separados para desarrollo y explotación, ambos modelos funcionaban, evolucionaban, trabajaban, de manera casi totalmente autónoma. Hay algunos puntos de unión, principalmente entre aquellos procesos que iban desde desarrollo hacia operaciones, a la hora de pasar software a producción, y en el camino contrario, cuando operaciones detectaba un problema en el software que implicaba un cambio en el desarrollo.
Pero ¿y en DevOps? ¿Cómo funciona todo esto? Veamos a continuación primero qué procesos de la ISO 20000 no pueden trabajar de manera tan asilada de desarrollo si una organización va a implantar prácticas Devops. En amarillo están los que se modifican moderadamente y en rojo los más afectados.

Los procesos más afectados serán:

• Gestión de Cambios: el objetivo de este proceso es asegurar que todos los cambios son evaluados, aprobados, implementados y revisados de una manera controlada.
• Gestión de la Entrega y Despliegue: el objetivo de este proceso es entregar, distribuir y realizar el seguimiento de uno o más cambios en la entrega en el entorno de producción real.

Los anteriores procesos ahora son parte tanto de desarrollo como de operaciones e incluso de testing, no pertenecen a departamentos separados, son un único todo, basado en los procesos de Devops.
Además, los anteriores estarán altamente automatizados desde desarrollo hacia producción, evitando el papel humano, el paso entre departamentos, las pérdidas de tiempo por coordinación humana, comités, listas y “pulls” de paso a producción, etc.
Todo ello, en muchas ocasiones, de la mano de la modificación de los anteriores procesos respecto a su visión clásica, tendrá incluso un reflejo en la estructura organizacional, más orientada a equipos y productos que a proyectos y departamentos.
Las figuras siguientes muestran una visión clásica de un departamento (Figura 1) y la siguiente una visión orientada a equipos (Figura 2).

DEVOPS actúa como interlocutor/evangelizador entre los equipos de desarrollo/sistemas (explotación) / control de calidad de desarrollo de SW.
Los procesos de la ISO 20000 que se verán mínimamente afectados por DevOps serán:

• Gestión de las relaciones con el Negocio: el objetivo de este proceso es establecer y mantener una buena relación entre el proveedor del servicio y el cliente, basándose en el entendimiento del cliente y de los fundamentos de su negocio.
• Gestión de Suministradores: el objetivo de este proceso es gestionar los suministradores para garantizar la provisión, sin interrupciones, de servicios de calidad.
• Gestión del Problema: el objetivo de este proceso es minimizar los efectos negativos sobre el negocio de las interrupciones del servicio, mediante la identificación y análisis reactivo y proactivo de la causa de los incidentes y la gestión de los problemas para su cierre.

Los dos primeros por aceleración en la entrega de valor al negocio y gestión de problemas por la necesaria robustez para identificar rápidamente problemas en versiones de desarrollo.
En lo que refiere a desarrollo, la siguiente tabla muestra qué procesos de la ISO 12207 se verán afectados.

Los procesos afectados serán:

• Gestión de la Configuración del Software: el propósito de este proceso es asegurar la disponibilidad de versiones consolidadas de cualquier documento que forma parte del ciclo de vida del proyecto.  Está enfocado a garantizar la integridad del código fuente del proyecto, así como garantizar la correcta reproductibilidad y evolución de las aplicaciones software, tanto durante el desarrollo como en el mantenimiento.
• Aseguramiento de la Calidad del Software: tiene como objetivo asegurar a los clientes (tanto internos como externos) la entrega de productos de la calidad acordada, proporcionando visibilidad a la línea jerárquica de la organización sobre los procesos seguidos para el desarrollo de los proyectos y los productos intermedios y finales obtenidos.
• Integración del Software: contiene las prácticas específicas asociadas con la generación  de una estrategia de integración, integrando los componentes de producto y entregando el producto al cliente.
• Verificación del Software: define las actividades (para el adquiriente, el proveedor u organización independiente)  para verificar  los productos y servicios de software.
• Integración del Sistema: trata la planificación completa de todas las prácticas específicas en esta área de proceso, desde la integración del producto hasta la entrega del producto final.

Principalmente todo lo relacionado con Testing, ya que en Devops toma un papel crítico el testing, y el testing automatizado. También los procesos de integración deben hacerse frecuentes y automáticos y los de control de versiones deben soportarse en estrategias robustas y automatizadas.
Como ya se ha comentado, el mundo está dividido en este tema  (Garzás, 2014), por un lado están los que piensan que desarrollo debe poder pasar a producción autónomamente cuando quiera, y por otro lado están los que piensan que el paso a producción debe estar autorizado y revisado puesto que esto puede conllevar algunos riesgos. Desde la experiencia propia y de la documentación acerca del tema, hay opiniones de todo tipo, en la Tabla 5 podemos ver argumentos o razones de profesionales por los que se posicionan a favor y en contra de DevOps:

No obstante, hay quienes no se posicionan explícitamente ni a favor ni en contra de DevOps, simplemente piensan que seguir o no esta tendencia depende de ciertas circunstancias como por ejemplo:

• El riesgo en el negocio, ya que hay despliegues más críticos, cambios más complicados… Según lo cual habrá que saber gestionarlo adecuadamente.
• El producto, el sector, la filosofía de la empresa, el modelo de negocio…

Kim Gene fue parte del equipo que escribió el libro “The Phoenix Project: A Novel About IT, DevOps and Helping Your Business Win” cuyo objetivo era crear una guía que muestra cómo los profesionales del desarrollo y de las operaciones de TI e ITSM pueden trabajar juntos para crear resultados que no podrían lograr por separado. Steve Hayes y Steve Ingall (Hayes & Ingall, 2014) nos muestran unas estadísticas acerca de la adopción de DevOps por organizaciones y de lo que ha mejorado en las mismas, dichas estadísticas fueron obtenidas a través de encuestas a profesionales TI y desarrolladores. En resumen estos profesionales fueron un 30% más rápido en realizar las entregas, obtuvieron un 50% de menos fallos y fueron 12 veces más rápidos que sus compañeros en establecer los servicios.
Tanto ITIL/ISO 20000 como DevOps tienen un factor clave en común, que es la colaboración. La agilidad define una relación de colaboración. Ambas están destinadas a apoyar la prestación de servicios de calidad a las empresas. ITIL/ISO 20000 y otras buenas prácticas pueden ayudar a aumentar el valor de la iniciativa DevOps. DevOps necesitará de una cierta adaptación de procesos de ITIL/ISO 20000, estos procesos clave son gestión de versiones, gestión del cambio y gestión de incidencias, que puedes ver más detalle de cada uno de los procesos en (Kim, 2014), epígrafe 11.

Concluyendo y aventurando el futuro

Si nos hacemos la pregunta, ¿Tardaríais mucho en pasar a producción un cambio en sólo una línea de código? (Garzás, 2012). Si tu empresa tarda semanas en pasar a producción un pequeño cambio en el software, seguramente tienes un proceso poco automatizado y/o sistemas y desarrollo están poco compenetrados. Si esto pasa estás perdiendo competitividad, tardarás mucho en validar versiones del producto con el usuario real.
En definitiva, los estándares como ya hemos señalado anteriormente (ISO 15504/ISO 12207 e ISO 20000-1), tendrán que adaptarse a las nuevas funcionalidades: reforzando la productividad,  reduciendo los costes y consiguiendo mayor agilidad y adaptación al cambio en el mantenimiento y creación del software.