Cultura Devops - No hablemos de mejores prácticas o herramientas, preguntémonos cuál es nuestro tiempo de entrega de valor

Hoy en día se habla en muchos lugares de devops. Realmente parece un término de moda y se discute sobre qué herramientas utilizar, mejores prácticas, entre otros, pero en muchas ocasiones no se habla del por qué es clave implementarla. Esto, ocasiona que se escojan plataformas y se implementen automatizaciones sin tener en cuenta cuál es la razón de fondo para involucrarse; ¿qué ganaremos? ¿cuál es la meta? ¿qué desperdicios atacaremos?, entre otros.

Esta entrada busca enfocar a los interesados respecto a la adopción de una cultura devops en una organización, proyecto o una iniciativa que genere un producto de software.

Ya entrando en detalles, DevOps es un acrónimo inglés de development (desarrollo) y operations (operaciones), que se refiere a la implementación de una cultura de generación de valor mediante la construcción de software que se centra en la comunicación, colaboración e integración entre desarrolladores, áreas de negocio, testers, seguridad, y los profesionales de sistemas en las tecnologías de la información (IT).

DevOps es una respuesta a la interdependencia del desarrollo de software y las operaciones IT. Su objetivo es ayudar a una organización a producir productos y servicios de software más rápidamente, de mejor calidad y a un coste menor.

La implementación de una cultura Devops busca eliminar peajes, o más bien acelerar su pago evitando desperdicios, que para este caso se traducen en pérdida de tiempo. Esto, teniendo en cuenta que cualquier entrega de valor implica un viaje desde que nace un producto o una funcionalidad hasta que finalmente se entrega y se opera brindándosela finalmente a nuestros Clientes.

Como se aprecia en la anterior figura, en una entrega de valor de un producto de software intervienen diferentes equipos. Cada equipo implementa actividades de definición, diseño, implementación, verificación, despliegue, pruebas, aseguramiento y operación. El ejemplo en un modelo de peajes busca reproducir lo que cada uno de nosotros sentimos cuando estamos haciendo fila para pagarlo. Esto, sin duda alguna es un desperdicio del tiempo; ¿cuanto tiempo perdemos en estas actividades al año?

¿SABEMOS CUÁLES SON NUESTROS DESPERDICIOS EN NUESTRA ENTREGA DE VALOR CONTINUA A NUESTROS CLIENTES?

Imaginen el siguiente escenario en el cual los peajes manuales se cambian por Telepeajes. En este caso, se reduce el tiempo de viaje en la creación de un producto o una funcionalidad automatizando los cobros por cada equipo que interviene en la entrega de valor, evitando los tiempos de espera que finalmente se traduce en reducción de desperdicios.

Lo anterior se logra implementando flujos automatizados de verificación en cada peaje. Esto se hace en la práctica con la construcción de pipelines en herramientas para lanzar dichas verificaciones una vez se aprueba un cambio en un componente de software.

En los ciclos de entregas de valor se desarrollan prácticas de integración continua y entregas continuas en  diversas plataformas (GitHub Actions, Bamboo, Travis, CircleCi, Jenkins, etc). En estas herramientas cada paso se define y enlaza los diferentes artefactos de cada peaje de acuerdo al área de interés (desarrollo, qa, despliegue, seguridad, etc.).

Para llegar a identificar cómo disminuir los desperdicios para automatizar lo que más genere valor se implementan diferentes técnicas. Una de ellas es la de Value Stream Mapping que hace parte del marco Lean del modelo Toyota de mejora continua, en donde se identifican tiempos muertos que no aportan ningún valor al flujo y a partir de esto se prioriza dónde realizar automatizaciones que reduzcan estos desperdicios.

Algo práctico al identificar desperdicios es iniciar por el tiempo total desde que una funcionalidad (feature) es definida, diseñada, implementada, probada, asegurada y desplegada en un entorno productivo. La idea es encontrar los puntos donde más se tardan las actividades y se genera desperdicio; seguramente allí es donde hay que intervenir para mejora el ciclo de entrega de valor.

En las implementaciones clásicas de entrega de valor de desarrollo de software, se elaboran requisitos de parte de áreas de negocio. Esto, se hace con definiciones formales, que luego de ser diseñados (por lo general por áreas de arquitecturas de solución) y revisados por analistas de negocio se entregan a equipos de desarrollo.

Una de las maneras de reducir desperdicios en la interacción con equipos de negocio es quizás la que hoy en día se hace con la implementación de marcos de metodología como Scrum, Crystal, Kanban, entre otros, en donde el negocio mismo está integrado con el equipo de desarrollo en un mismo lugar (célula, squad, equipo, etc), reduciendo desperdicios al tener una interacción directa (face 2 face), mejorando la comunicación y comprensión de la visión de producto o funcionalidad. Esto, también genera espacios de co creación con los miembros del equipo.

Quizás las técnicas más conocidas para equipos de negocio que se integran con equipos de desarrollos incluyen la implementación de incepciones, historias de usuario, criterios de aceptación, planificaciones ágiles, planning poker, entre otros para crear una línea clara de interacción entre dueños de producto y el equipo que construye la solución de software.

Los precursores de la agilidad en la implementación de software se remontan al año 2001, cuando se reunieron para compartir experiencias respecto a las buenas prácticas para construir software, creando el manifiesto ágil que hoy en día es ampliamente conocido. Sin embargo, para aquella época ya se conocía extreme programming una metodología que tuvo gran aceptación entre muchos desarrolladores de software, con un conjunto de prácticas como se aprecia en la siguiente figura.

Extreme programming creo un marco de prácticas que se conocen hoy en día en la mayoría de los proyectos de desarrollo de software. Muchas de estas se utilizan en los equipos que implementan una solución de software.

Quizás una de las prácticas más relevantes que introdujo extreme programming fue la de integración continua CI, porque permitió construir flujos automatizados que integran el código de uno o varios desarrolladores en un repositorio de código (controlador de versiones), pudiendo así detectar fallos cuanto antes. Se entiende por CI la compilación y ejecución de pruebas de todo un proyecto una vez un desarrollador introduce un cambio; este se envía al repositorio de código que lanza las validaciones automáticas una vez se integra el código.

El proceso de CI se realiza cada cierto tiempo (horas), descargarse las fuentes desde el control de versiones. Si las pruebas fueron exitosas se permitirá la mezcla del código o en caso contrario se rechazará informando al desarrollador.

Es clave para automatizar el peaje de generación de componentes de software que el equipo de desarrollo automatice las pruebas de unidad en alguna tecnología (Node Js, Java, Scala, Phyton, Angular, React, etc.), implementaciones de verificación de calidad de código (cobertura de pruebas, código redundante, complejidad y smells, entre otros) con Sonar por ejemplo, incluyendo todos éstos pasos en el pipeline de ejecución.

Éstas prácticas permiten automatizar el desarrollo de software reduciendo desperdicios en el ciclo de implementación. Adicional a esto, se implementan prácticas relacionadas con calidad de código que hoy son ampliamente difundidas: TDD, refactorización, integración continua, cobertura de pruebas unitarias, estandarización de código entre otras.

El caso del peaje de pruebas quizás es uno de los puntos más relevantes en la reducción de desperdicio de las entregas de valor. Es clave implementar pruebas funcionales e2e, pruebas de regresión, APIs, y de integración. En muchos equipos de desarrollo se ha avanzado muchísimo en la implementación de éstas pruebas, pero aún existe un peaje allí, al no tener las pruebas funcionales y de regresión como mínimo integradas al pipeline verificando de manera automatizada cada promoción de código.

Si se logra automatizar las pruebas incluyéndolas en nuestro pipeline podremos eliminar el peaje manual que nos impide poder implementar integración continua. Una vez tengamos las pruebas incluidas en el pipeline podremos llegar a la implementación de entregas continuas.

¿TU PRODUCTO DE SOFTWARE TIENE INTEGRACIÓN CONTINUA, ENTREGAS CONTINUAS O DESPLIEGUE CONTINUO?

Para llegar al nivel de despliegue continuo es necesario incluir las pruebas de seguridad como parte de la automatización de nuestros peajes. Allí, es clave verificar el código garantizando que se cumpla con prácticas de desarrollo seguro (Ej. OWASP), pruebas de controles y lineamientos de seguridad establecidos.

La automatización de las verificaciones de seguridad hoy en día se hace a través de prácticas DevSecOps implicando pensar desde el principio en la seguridad de las aplicaciones y de la infraestructura. 

Finalmente, una vez se aceleré la entrega de valor mediante la automatización entra en acción el equipo de operaciones. No todo termina allí, porque también es necesario que se implementen peajes automatizados que permitan monitorear la infraestructura, la operación y los resultados de negocio a través de herramientas que habiliten dashboards y alertas que faciliten la intervención de un equipo de soporte.

No todo termina allí, porque la automatización del ciclo de entrega de valor también requiere que el aprovisionamiento de infraestructura no tenga peajes manuales. Para ello es clave la implementación de prácticas de infraestructura como código IaC brindando velocidad a los equipos de trabajo al controlar todos los artefactos que requiera una solución de software.

La IaC permite promover el código entre diferentes entornos a través de ciclos de aprobación en la plataforma de control de código (ej. Git) entre los roles involucrados, brindando autonomía a los equipos de desarrollo que participen en la entrega de valor. La promoción del código de IaC se verifica en la plataforma de control de código lanzando el pipeline generando los artefactos en el entorno como se muestra en la siguiente figura.

Este enfoque hace que el equipo de desarrollo de un producto de software sea dueño de su infraestructura apoyándose por equipos de automatización que apoyan la cultura devops permitiendo que las entregas de valor se agilicen mucho más.

¿TU EQUIPO DE DESARROLLO ES AUTÓNOMO EN EL APROVISIONAMIENTO DE INFRAESTRUCTURA?



La infraestructura como código permite que un equipo de implementación ágil sea dueño de su plataforma de ejecución. Si tenemos el control de nuestra infraestructura podremos automatizar su aprovisionamiento y CREAR LA AUTOPISTA QUE ACELERE NUESTRA ENTREGA DE VALOR

En conclusión, la cultura devops pretende automatizar los mencionados peajes para que la interacción de las actividades se ejecuten pero no detengan las entregas ocasionando desperdicios. Con estas implementaciones los equipos realmente pueden tener autonomía en los despliegues continuos mejorando su velocidad: EQUIPOS MÁS PRODUCTIVOS