No es la primera, ni la última vez que escribo sobre la enorme complejidad inherente al desarrollo de software. De la necesidad -siempre creciente- de conocimiento que soportan todos los actores en la industria actual. Y lo fácil que es perder el ritmo para mantenerse en la cresta de la ola tecnológica.
Las metodologías, procesos y procedimientos intentan ordenar el caos hacia donde tienden las construcciones de aplicaciones informáticas. Mientras que las herramientas, a su vez, ganan en profundidad y ámbito de actuación en una búsqueda permanente de liberar al factor humano de las tareas repetitivas o tendentes al error, para que se pueda centrar en utilizar su talento y capacidad intelectual en la codificación y los retos algorítmicos que se presentan.
Los orígenes
Como con muchas de las cosas relacionadas con la informática, no existe un origen claro, y definido del termino DevOps. Algunos opinan que es una evolución natural y esperada del concepto de ALM (Gestión del Ciclo de Vida de las Aplicaciones), de lo cual Andrew Clay Shafer y Patrick Debois hablaron en la conferencia Agile del 2008 de Toronto; y donde utilizaron por primera vez el término de "Infraestructura Agile".
Mike Loukides, publicó un completo análisis en donde sostiene que DevOps era la forma natural de trabajar en los tiempos iniciales de la informática (el programador también cambiaba las cintas), y que se separaron las funciones de Programación y Operaciones en los años 60. Mike, continua con un análisis detallado del artículo de Adrian Cockcroft, en donde se refiere a NoOps, término en donde se unen los conceptos de DevOps y PaaS (Plataforma como servicio). Siendo esto un estado final extremo, en donde los departamentos de IT estarían vacíos de sentido en la industria de desarrollo de software.
Incluso, el origen de DevOps pudiera provenir del libro The Phoenix Project, que describe el compendio de todas las cosas que pueden ir mal en un proyecto de desarrollo de software, y cómo paliar los impedimentos por medio de la automatización. Lo que es indudable es que esta obra se ha convertido en una referencia del movimiento DevOps.
Descripción del ciclo de DevOps
¿Pero cuál es el ciclo al que se llama DevOps? De forma simplificada, se podría resumir en la siguiente imagen:
Como se puedo observar al primer vistazo, DevOps tiene sus raíces en metodologías Iterativas, y más específicamente en la evolución de las herramientas para desarrollo Agile.
Reúne en un solo bucle dos mundos de la industria que hasta ahora estaban meridianamente separados, y que ha sido fuente de rivalidades y discusiones durante las últimas décadas: Desarrollo y Operaciones.
Sin embargo, el objetivo de DevOps es que ambos grupos de trabajo se coordinen, se comuniquen y establezcan lazos de cooperación que dejen atrás esas diferencias artificiales, frente a las necesidades de integración que los sistemas informáticos requieren.
Planificación.
Esto, que en metodologías en Cascada es el principal escollo para un desarrollo iterativo, en Agile se convierte en una conversación continuada con el cliente. En donde se define el trabajo a realizar, se prioriza de acuerdo a su complejidad y valor, o se cambia el alcance de forma dinámica, quitando o añadiendo requisitos dentro del tiempo acordado.
Es esta planificación, la inicial para sentar las bases del proyecto y las que se suceden de forma continuada durante todos los sprint, sobre la que trabaja el equipo. Decidiendo cual es la forma óptima de construir y tomando las decisiones tecnológicas que correspondan.
Con la actualización diaria de la herramienta de visualización del flujo de trabajo, y las liturgias de descritas por la metodología, se realiza un seguimiento del estado del proyecto y de los impedimentos que estuvieran afectando al desarrollo.
Desde el punto de vista de las herramientas de DevOps, partiendo de una visión Agile, estas soportan todos los trabajos de documentación, modelado de la planificación y las priorizaciones. También, la gestión del flujo de trabajo por medio de tableros electrónicos, la obtención de métricas y la visibilidad del estado de avance de forma sencilla e inmediata.
Desarrollo y pruebas
En este capítulo lo que más impacto tiene, desde el punto de vista de DevOps, es la automatización del almacenamiento del código. Para ello existen plataformas de control de versiones que permiten realizar conceptos básicos como versionado, histórico y trabajo colaborativo por medio de estructuras de desarrollo en ramas.
Estos repositorios de código han dado un paso adelante al asociar el código al flujo de tareas, permitiendo una trazabilidad absoluta, e integrando las herramientas de pruebas, rendimiento y calidad, en el flujo de trabajo diario del desarrollador.
Pero nada de ello tendría sentido si no hubiera una (re) evolución cultural (nacida en los años 90) en la industria de la codificación de software, que ha traído nuevos baremos de calidad y buenas prácticas; donde ya no solamente importa que las aplicaciones funcionen bien, si no también el cómo lo hacen. Y que aún dista de estar implantada en la generalidad de nuestro sector.
Publicación continúa
Si tengo código versionado, y tengo baterías de pruebas que aseguran tanto la calidad como el funcionamiento de toda la aplicación, automatizando dichos procesos he llegado al concepto de Integración Continua.
Cada vez que yo actualice mi código en el repositorio, se va a lanzar la ejecución de todas las pruebas necesarias que revisen su integración con el resto del software, y que no “rompe” nada.
Fácil es de ver que el siguiente paso dentro del flujo de automatizaciones es que, ese código compilado y comprobado, pueda ser desplegado de forma automática -previa las validaciones necesarias- en los diferentes servidores de la plataforma (QA, Pre, Pro, etc.)
Y, fíjate, aquí ya estamos saliendo del ámbito exclusivo del desarrollador, y hemos entrado en el área de Sistemas. Ya no hablamos de código, sino de infraestructura. Y de las necesidades que tiene un IT para asegurar que las actualizaciones o mejoras no producen incidencias en Producción. Es decir, disponer de las herramientas necesarias para poder visualizar tempranamente los problemas y actuar sobre ellos.
Análisis de operación
El gran cambio que representa DevOps en comparación con lo que hasta ayer se llamaba ALM, viene de la automatización del análisis de las operaciones: monitorizar de forma constante la salud de la aplicación y de la infraestructura.
No solamente se trata que IT, por medio de contadores y alertas, siga realizando sus labores de auditorías del estado de los servidores y comunicaciones; si no que ahora se aboga por el uso de herramientas específicas que obtengan las métricas que supervisan el estado de salud del funcionamiento del software y que permitan el acceso al histórico de resultados en donde poder visualizar - de forma sencilla - la evolución del producto.
Así, se pueden tomar decisiones estratégicas relacionadas con la escalabilidad, con la infraestructura como software, y con los trabajos correctivos y evolutivos que todo programa soporta durante su vida útil. Cerrando el círculo de DevOps al utilizar las conclusiones de los Análisis de operación como parte de la planificación de los trabajos que se deben realizar sobre el software.
¿Es DevOps una moda?
Sí, pero no.
Sí, en la realidad de que quien más está solicitando servicios de DevOps son los departamentos de IT de las empresas. Quienes, en muchos casos, se están haciendo eco del runrún de la industria que tiene palabras como Agile o iteración como paradigma del cambio necesario en la búsqueda de evitar los fracasos de los proyectos; pero sin tener un conocimiento firme sobre – tan siquiera- la gestión del ciclo de vida de las aplicaciones o metodologías de desarrollo Agile.
No, ya que DevOps trata sobre plasmar sentido común a las complejas operaciones de codificación y sistemas que comprenden el desarrollo de productos informáticos. Y que, cuanto más tiempo pase y más empresas lo implanten, más se mostrará de forma indiscutible el aumento de productividad que conlleva.
Como señalaba anteriormente, DevOps incluye los propios mecanismos para validar la mejora que implica aplicar esta cultura empresarial en los departamentos de desarrollo y sistemas. Siendo esto, junto con la flexibilidad de cambiar la orientación del desarrollo hacia el camino más óptimo en cada ocasión, la semilla de su propio éxito y del sobrevivir al estado actual de moda.
Foto | Flickr
