Esta entrada muestra nuestra cultura devops Lab Digital BdB junto a los principales retos que hemos tenido. Involucra las prácticas que hemos implementado para acelera las entregas de valor de las soluciones digitales.
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 implementarlo. 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.
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 nuestra cultura Devops busca eliminar peajes acelerando su pago evitando desperdicios. Esto, teniendo en cuenta que cualquier entrega de valor implica un viaje desde que se define una funcionalidad hasta que 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 por la automatización de los cobros evitando los tiempos de espera reduciendo desperdicios.
Lo anterior se logra implementando flujos automatizados de verificación en cada peaje. Esto se implementa 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 como Bamboo, Travis, CircleCi, Jenkins, Git Actions, entre otras. 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ñadas (por lo general por áreas de arquitecturas de solución) y revisadas 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 la implementación de marcos ágiles como Scrum o Kanban. Esto reduce 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 generando 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 otras. Esto crea 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.
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 los pipelines 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.
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?
En conclusión, nuestra cultura devops Lab Digital BdB pretende automatizar los peajes para que la interacción de las actividades se ejecuten evitando desperdicios. Con estas implementaciones los equipos realmente pueden tener autonomía en los despliegues continuos mejorando su velocidad:EQUIPOS MÁS PRODUCTIVOS