Te va a interesar!

6/recent/ticker-posts

El desafío de implementar DevOps cuando trabajas con distintos vendors.

Ohh si amigos. Levantarse temprano, leer una frase motivacional sobre una foto de un cachorrito, escuchar a los pájaros cantar e intentar implementar DevOps en un cliente con una fauna variopinta de vendors que trabajan en los mismos proyectos.

Es la imagen misma de la inocencia, no creen? Sobre todo porque creemos que todos vamos a estar remando para el mismo lado...pero a veces, queridos lectores, no es así. Preparen un café y pónganse cómodos en esta fría mañana de Invierno, porque les voy a contar una historia sobre cómo una gran idea no pudo ser concretada debido a ésto y la conclusión a la que llegué.

La(s) idea(s): Mejorar el SDLC introduciendo procesos DevOpsianos para mejorar la toma de decisiones.

Se que puede sonar un poco técnico, pero la explicación es en realidad sencilla. Noté que en la empresa se usaba una herramienta (digo "noté" porque fui yo el que configuró la herramienta) en sus equipos de desarrollo. La herramienta en cuestión es Sonarqube, la cual sirve para, a grandes rasgos, hacer un análisis estático en el código y levanta advertencias, vulnerabilidades, bugs, falta de Unit Tests, bloques duplicados y un montón de data muy interesante en un dashboard muy sencillo de usar.

Originalmente, esta herramienta la configuré para mantener un estándar en los proyectos de Automation, para revisar el código y dar coscorrones a los que no estén haciendo las cosas bien. Se ve que algunos equipos dev gustaron de lo que vieron y decidieron usarla también, lo cuál me vino como anillo al dedo para mis planes de conquista mundial, los cuales eran muy muy inocentes.

La primer idea que tuve fue decir "bueno, ya que tenemos todas esta información servida en bandeja de plata, usemos esto en beneficio de Testing! Agarro las métricas de los proyectos Dev, miro cuáles son los repos con menos estabilidad, con más riesgo y de ahí tomo para planificar según eso y los intereses del business las próximas suites de Automation". La idea enseguida encantó a los Managers y me dieron luz verde para seguir desarrollándola. 

La segunda idea fue decir "bueno...ya que voy a empezar a tener una colaboración con los devs, aunque sea a través de Sonarqube porque todavía no me consideren su amigo, voy a intentar también hacer que las builds de Jenkins sean ejecutadas de una forma más eficiente que la actual. Y para eso, voy a añadir WebHooks en sus repositorios que, al detectar cambios mandados al Master, disparen las suites de jobs en Jenkins que yo especifico". De nuevo, Management me aplaudía como una foca en Seaworld. 

El problema: buscando construir la columna de Babel...

El problema apareció por un lado que no esperaba. Cuando salí a hablar con los equipos de desarrollo para poner en marcha pruebas de concepto...resultó que la gran mayoría del código de las aplicaciones NO EXISTIA EN LA EMPRESA. Así es...todo estaba en la nube, bajo la celosa mirada de diferentes vendors que eran los creadores y que no tenían ningún interés en dejar que otros metan sus narices en sus asuntos. 

Entonces de repente no se iba a poder incluir el 80% de proyectos en la idea de Sonarqube porque simplemente no teníamos control ni manera de pedirles que hagan eso. La segunda idea que se fue por la borda fue, de forma similar, la que les mencioné de los Webhooks y la ejecución "inteligente" de jobs en Jenkins. Ya no había control sobre los repos de los devs. 

Supongo que entiendo el por qué. Es introducir algo que "no te beneficia a vos", al decir todo lo que está mal con el código que escribiste. Por qué alguien querría meterse en semejante embrollo sin ningún beneficio? Y es esa mentalidad lo que me llevó a la...

Conclusión: De nada sirve hablar de calidad si no es un enfoque holístico.

DevOps es acerca de la cultura de la empresa o del proyecto. Es sobre el concepto de que "todos somos responsables de la calidad del producto". A veces, cuando se trabaja en una empresa grande, con muchísimos contractors, vendors y otras yerbas haciendo buena parte del trabajo, esa comunicación y loop de feedback se hacen más pequeño o incluso se pierde. DevOps es sobre amplificar el feedback en cada etapa del desarrollo de software para mejorar las decisiones todo el tiempo. 

Dado que hoy en día es muy común que las empresas grandes tengan mucho tercerizado, creo que acá radica el principal problema de DevOps y el cuál, en mi opinión, se puede resolver mediante el uso de herramientas con un enfoque objetivo sobre el cuál trabajar. Vean el caso de Sonarqube sino. No soy yo apuntando con el dedo y diciendo a los desarrolladores de esa otra empresa "competencia" de la mía que su código es una bazofia, es la colección de hechos arrojados por el análisis de una aplicación. 

En ese sentido, se evitan las asperezas que puedan surgir de tener que interactuar para comunicar esas cosas y se trabaja sobre los fríos hechos y datos arrojados por el monitoreo de una herramienta.

Creo que es, pienso yo, cuestión de establecer esas herramientas como algo mandatorio para incluso aquellos que tengan su código en la Luna. De esa manera no hay misterios, ni lagunas, ni cosas libradas a la imaginación y todos estamos trabajando en una misma dirección. 

Y ustedes? Qué opinan? Les pasa algo parecido en sus lugares de trabajo? Dejen sus comentarios que los leo!




Publicar un comentario

0 Comentarios