Analizando la toolchain de DevOps

Seguramente a estas alturas habrás oído hablar sobre DevOps, pero el objetivo de este post no es centrarnos en esta maravillosa cultura, aunque probablemente podríamos escribir unas cuantas páginas sobre ello.

Hoy me gustaría centrarme en la parte tecnológica de este movimiento, la toolchain de DevOps. No obstante, no estamos aquí para evaluar tecnologías ni sugerir herramientas, así que concretamente me centraré en qué metas nos podemos fijar a la hora de madurar en este proceso.

Quizás en alguna ocasión hayas encontrado una o dos imágenes similares a esta, donde se especifica cuáles son las diferentes fases de la toolchain de DevOps. Si es así, probablemente eches de menos (o de más) algún punto en la cadena. En cualquier caso, vamos a hablar un poco sobre ella.

Code

El código es una de las partes que es común a todas las soluciones informáticas. No es imperativo que sigas DevOps para tener código, pero sí que hay ciertas cosas a tener en cuenta desde el punto de vista de DevOps a la hora de tratarlo.

Al ser uno de los puntos críticos de un proyecto tecnológico no querrás correr el riesgo de perderlo y, por supuesto, estarás usando un sistema de control de versiones. En cierto modo, no es importante que tecnología se esté usando pero sí cómo.

¿Qué podemos hacer para mejorar en este punto?

Utilizar una estrategia de versionado y una estrategia de ramificación no solo aporta agilidad y elimina dependencias entre los desarrolladores, también permite automatizar algunos comportamientos dependiendo de la versión o incluso probar partes aisladas del programa en entornos controlados.

Una vez establecidas estas estrategias está el problema de unir las diferentes piezas de código. Esto en algunos desarrolladores provoca pavor, pero otros deciden automatizar el merge con herramientas que en ocasiones incluso aportan sistemas de revisión de código.

Build

Si trabajas en el mundo del desarrollo no en pocas ocasiones te habrás encontrado en la situación de tener que empaquetar la solución en local, para desplegar una nueva versión. Si eres un poco “vago”, como yo :), seguro que has llegado a automatizar el proceso para ahorrarte hacer los mismos pasos una y otra vez.

No nos quedemos ahí, pues hoy en día contamos con herramientas que nos permiten realizar este proceso automático cada vez que realizamos un cambio en el código, dándonos la posibilidad de detectar fallos a la hora de realizar la build. Sí, lo has adivinado: estoy hablando de la integración continua.

Test & Quality

Hay diferentes opiniones sobre si realizar pruebas del código realmente reduce los tiempos de desarrollo a la larga. No obstante, (lo siento pero tengo que admitirlo) soy un fuerte defensor no solo de las pruebas sobre el código, también de la calidad del mismo.

Hay similitudes entre los estados de madurez entre la fase de build y las fases de pruebas y calidad. No es por azar, son las mismas porque el objetivo es el mismo, que es llegar a automatizar el proceso de forma que se logre una revisión constante tanto del funcionamiento del código como de su calidad. Aún teniendo en cuenta esto, ambas fases merecen su propia categoría, pues hay una gran cantidad de herramientas que nos pueden ayudar en el proceso y nos aportan valor específicamente en estos campos.

Deploy & Provision

¿Cuál es la diferencia entre el despliegue y la provisión? En este punto me gustaría especificar que por despliegue me refiero a la parte del software y por provisión me refiero a la parte de infraestructura. Cuando se trabaja en la nube hay un componente tan importante como el código, los diferentes servicios, aplicaciones e infraestructuras que permiten que tu código se convierta en una solución.

Está claro que hay cierta diferencia entre un código y la infraestructura donde corre. Al menos, eso puede parecer porque hoy por hoy (y por eso hice antes hincapié en la nube) contamos con herramientas y servicios que nos permiten desplegar y configurar esta infraestructura como código.

En estos puntos, no solo aporta mucho “automatizar” como primera fase de mejora o incluso llegar a realizar “despliegue continuo”. Lo digo entre comillas porque en entornos productivos quizás no resulte interesante subir un código de forma automática que, aunque a primera vista no tenga fallos, pueda llegar a generar errores en alguno de los componentes en medio del despliegue.

¿Cómo actuamos si algo falla?

Pues del mismo modo que si algo no funcionase y no estuviese automatizado el proceso: re-desplegando una versión anterior que funcione. Si se consigue realizar un rollback cuando algo falla, de forma proactiva, se asegurará una ventana de recuperación estable, pudiendo llegar a reducir a cero el tiempo en el cual estamos sin servicio si utilizamos técnicas como blue-green deployment.

Monitor & Operate

Por último, pero no por ello menos importante, nos centramos en cómo monitorizamos y operamos la plataforma. Es cierto que cada vez más se escucha que la finalidad misma de DevOps es llegar a NoOps, pero dependiendo del tipo de proyecto esto puede llegar a convertirse en una utopía.

Por esto mismo es por lo que en este punto lo importante es automatizar la operativa de la plataforma, e incluso llegar a utilizar los diferentes puntos de información que nos provee la monitorización para dirigir esta operativa en base a eventos, llegando a ser cada vez más proactivosy aportando valor continuamente.

Cómo hacer madurar la cultura DevOps en la organización

Conclusión

Llegados a este punto, lo más probable es que tengas la cabeza llena de términos e incluso eches de menos la mención de alguna tecnología que provea todo esto, pero lo cierto es que ninguna herramienta lo da todo hecho y que lo importante es que realmente cuentes con un punto de partida desde el que empezar.

Dicho esto, me gustaría dejar claro que una cultura y una pipeline de DevOps madura requiere mucho tiempo y trabajo, y que es aconsejable centrar los esfuerzos en madurar aquellas partes que más valor le aporten a tu negocio. ¿Cómo sabemos cuáles son esos puntos? Utilizando diferentes medidas para analizarlo, como por ejemplo la frecuencia de despliegue o el número de funcionalidades por día. No obstante, y como suele decirse, de esto hablaremos en otro momento. ¡Feliz viaje por el mundo DevOps!