cerrar-sesion editar-perfil marker video calendario monitor periodico fax rss twitter facebook google-plus linkedin alarma circulo-derecha abajo derecha izquierda mover-vertical candado usuario email lupa exito mapa email2 telefono etiqueta

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

Escrito por Redacción Byte TI el 1 junio, 2015 en Tendencias TIC
1 comentario Haz tu comentario
Imagen de logotipo de facebook Imagen de logotipo de Twitter Imagen de Logotipo de Google+ Imagen de logotipo de Linkedin

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. 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.

ISO 12207
Nivel 2
Proceso de Planificación de Proyecto
Proceso de Evaluación y Control del Proyecto
Proceso de Medición
Proceso de Definición de Requisitos de Stakeholders
Proceso de Análisis de los Requisitos del Sistema
Proceso de Gestión de la Configuración del Software
Proceso de Aseguramiento de la Calidad del Software
Nivel 3
Proceso de Gestión de la Decisión
Proceso de Gestión de Riesgos
Proceso de Gestión de Recursos Humanos
Proceso de Análisis de Requisitos del Software
Proceso de Diseño de la Arquitectura del Software
Proceso de Integración del Software
Proceso de Verificación del Software
Proceso de Validación del Software
Proceso de Diseño de la Arquitectura del Sistema
Proceso de Integración del Sistema
Proceso de Gestión de Infraestructuras

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):

ISO/IEC 20000
De provisión del Servicio
Gestión de Nivel de Servicio
Generación de Informes del Servicio
Gestión de la Continuidad y Disponibilidad del Servicio
Elaboración de Presupuesto y Contabilidad de los Servicio
Gestión de la Capacidad
Gestión de la Seguridad de la Información
De Relación
Gestión de las Relaciones con el Negocio
Gestión de Suministradores
De Resolución
Gestión de Incidencias y Peticiones de Servicio
Gestión del Problema
De Control
Gestión de la Configuración
Gestión de Cambios
Gestión de la Entrega y Despliegue

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.

ISO 20000
De Provisión del Servicio
Gestión de Nivel de Servicio
Generación de Informes del Servicio
Gestión de la Continuidad y Disponibilidad del Servicio
Elaboración de Presupuesto y Contabilidad de los Servicios
Gestión de la Capacidad
Gestión de la Seguridad de la Información
De Relación
Gestión de las Relaciones con el Negocio
Gestión de Suministradores
De Resolución
Gestión de Incidencias y peticiones de servicio
Gestión del Problema
De Control
Gestión de la Configuración
Gestión de Cambios
Gestión de la entrega y despliegue

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).

 

Figura 1. Visión clásica de un departamento.

Figura 1. Visión clásica de un departamento.

 

 

Figura 2. Visión orientada a equipos

Figura 2. Visión orientada a equipos

 

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.

ISO 12207
Nivel 2
Proceso de Planificación de Proyecto
Proceso de Evaluación y Control del Proyecto
Proceso de Medición
Proceso de Definición de Requisitos de Stakeholders
Proceso de Análisis de los Requisitos del Sistema
Proceso de Gestión de la Configuración del Software
Proceso de Aseguramiento de la Calidad del Software
Nivel 3
Proceso de Gestión de la Decisión
Proceso de Gestión de Riesgos
Proceso de Gestión de Recursos Humanos
Proceso de Análisis de Requisitos del Software
Proceso de Diseño de la Arquitectura del Software
Proceso de Integración del Software
Proceso de Verificación del Software
Proceso de Validación del Software
Proceso de Diseño de la Arquitectura del Sistema
Proceso de Integración del Sistema
Proceso de Gestión de Infraestructuras

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:

A favor de DevOpsEn contra de DevOps
Se puede buscar un equilibrio entre ambas áreas pudiendo encontrar una zona de trabajo cómoda para todos.Poner en riesgo el entorno de producción, lo que implicaría posibles caídas en producción riesgos de seguridad, etc.
A pesar de las dificultades, entregas más rápidas y puestas al mercado más rápidamente.Pérdida de control respecto a qué hay en producción.
Aumento de la calidad, es decir, menos fallos, una mayor tasa de éxitos en cambios…Complejo identificar errores, identificar incidencias y problemas respecto a versiones en producción.
Aumento de la eficacia de la organización.Segregación de tareas entre desarrollo y operaciones.
Aspectos culturares y organizativos.

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.

 

Referencias
 
Debois, P. (2009). DevOps days ghent. Fecha de consulta: 10/21 2013. Disponible en: http://www.devopsdays.org/events/2009-ghent/
 
Garzás, J. (2010). ¿ISO/IEC 90000, 15504, 12207, 27001 O 2000?Disponible en: http://www.javiergarzas.com/2010/05/iso9000-iso15504-iso12207-iso27001-iso20000.html
 
Garzás, J. (2012). ¿Tardaríais mucho en pasar a producción un cambio en sólo una línea de código? aprende entrega contínua.Disponible en: http://www.javiergarzas.com/2012/11/entrega-continua-continuous-delivery.html
 
Garzás, J. (2013a). Caso de estudio: Cómo trabaja quora en continuous deployment.Disponible en: http://www.javiergarzas.com/2013/06/quora-continuous-deployment.html
 
Garzás, J. (2013b). DevOps, llevando a la agilidad y el lean al departamento de sistemas.Disponible en: http://www.javiergarzas.com/2013/03/devops-agilidad.html
 
Garzás, J. (2014). ¿Debería poder desarrollo directa y autónomamente a producción?Disponible en: http://www.javiergarzas.com/2014/03/deberia-poder-pasar-desarrollo-directa-y-autonomamente-produccion.html
 
Hayes, S., & Ingall, S. (2014). DevOps and ITIL – working together insights paper.<br />   .Disponible en: http://www.icore-ltd.com/wp-content/uploads/2014/01/DevOps-and-ITIL-Working-Together-Insights-Paper-Full-Version.pdf
 
Jones, I. (2014). Struggling to adopt continuous delivery or DevOps in a large enterprise? perhaps you should visit an airport.Disponible en: http://www.ianjones.co/2014/02/struggling-to-adopt-continuous-delivery.html
 
Kim, G. (2014). Trust me: The DevOps movement fits perfectly with ITSM.Disponible en: http://www.theitsmreview.com/2014/03/trust-devops-movement-fits-perfectly-itsm/
 
Fernández, CM. Piattini, M (2013). Modelo para el gobierno de las TIC basado en las normas ISO.
 
http://www.aenor.es/aenor/normas/ediciones/fichae.asp?codigo=9918
Compártelo

Noticias relacionadas

Escrito por Redacción Byte TI el 17 septiembre, 2017 en monitorización

Rabobank elige a Dynatrace para rastrear problemas de rendimiento

Escrito por Redacción Byte TI el 6 julio, 2017 en open source

SUSE Manager simplifica la gestión de los contenedores

Escrito por Redacción Byte TI el 30 mayo, 2017 en Cloud Computing

Europa lidera las estrategias cloud-first

Comentarios
  • Pablos 8 mayo, 2015

    Interesantísimo artículo! Muchas gracias por compartirlo.

    Me gustaría que pudierais revisarlo ya que la tabla 3 se indica que se marcan procesos en color rojo y amarillo y en realidad no muestran color.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Debes haber iniciado sesión para comentar una noticia.