¿Por qué se habla tanto de la cultura DevOps en testing?

DevOps está revolucionando el desarrollo de software: ¿qué significa para los testers?

DevOps es una simple palabra que se ha convertido en tendencia. Surge de unir las palabras Desarrollo y Operaciones, con la idea de unir dos mundos entre los que suele haber mucha fricción.

Se habla de cultura DevOps quizás porque es algo que está más relacionado con las personas y sus formas de trabajar, y no solo con las tecnologías. Consiste en unir dos cosas históricamente separadas: la construcción (desarrollo) de software y la operación del mismo. También se trata de unir más partes de los diferentes mundos involucrados en la creación y operación de software.

¿En qué consiste la Cultura DevOps?

Una cultura DevOps propone generar una cultura de ciclos de aprendizaje, comunicación y feedback en diferentes niveles. No es solo una cuestión técnica, mucho menos un rol, aunque a menudo se suele escuchar “Soy un DevOps” o “Busco un DevOps para una empresa genial”.

Típicamente sucede algo así: hay una idea, cambio, requerimiento, etc., los desarrolladores trabajan en escribir código, arman un paquete que se pasa a operaciones y ellos son los que se encargan de ponerlo en producción, y de ahí va a manos del usuario. Después de eso, es la gente de operaciones la que sigue administrándolo y es responsable de todo lo que sucede en el lado de la producción.

Existe un conflicto típico de intereses entre el área de desarrollo y el área de operaciones que usualmente causa dificultades y retrasos:

Los desarrolladores quieren darle al usuario el producto lo antes posible (más aún dentro de metodologías ágiles, posiblemente con el objetivo de poner cambios en producción al menos una vez por semana).
Operaciones no quiere poner algo en producción que pueda causar problemas, luego tener que retroceder, recuperar copias de seguridad porque el último cambio rompió la base de datos o el sistema falla, Para luego recibir reclamos por parte de los usuarios, ya que son la primera línea de soporte.

Esto demuestra una enorme fuente de fricción entre desarrollo y operaciones, que inevitablemente afecta al negocio. Y esto no sucede por las herramientas que utilizamos, como establece la segunda ley de consultoría de Jerry Weinberg (en su libro, “ Los secretos de la consultoría: una guía para dar y recibir consejos”).

DevOps es una cultura. No solo se ocupa de las áreas técnicas, sino que está estrechamente relacionada con los componentes humanos y con los procesos. Para superar los posibles roces, la comunicación es fundamental. La interacción también es esencial y la forma en que se dividen y comparten las responsabilidades implica un enfoque Agile que involucra no solo a los desarrolladores, sino también al equipo de operaciones.

Y es que la cultura DevOps no solo se adopta porque está de moda. Se utiliza para minimizar el tiempo entre el nacimiento de una idea y su lanzamiento.

Según este estudio, los equipos que emplean DevOps entregan 30 veces más, tienen 60 veces menos fallas y se recuperan 160 veces más rápido.

Del mismo artículo que menciona el estudio, tomé la siguiente imagen porque creo que representa muy bien el concepto de cultura DevOps. Muestra todas las etapas del proceso de desarrollo, con retroalimentación continua, integración continua, todo rodeado de comunicación en tiempo real.

Etapas del proceso de Desarrollo de Software: feedback, comunicación, integración y entrega continua — *Fuente: Atlassian*

La evolución a DevOps desde la perspectiva del Testing

Algo que encontré particularmente interesante fue la forma en que Katrina Clokie ve DevOps desde el punto de vista de un tester, de su libro, “A Practical Guide to Testing in DevOps ” (¡Un libro que recomiendo mucho!).

Ella muestra en tres figuras diferentes, cómo las relaciones entre los testers y todos los demás actores involucrados en el desarrollo de software han cambiado a lo largo de la evolución del enfoque de cascada a Agile y a DevOps.

En el enfoque Waterfall (cascada), tenemos al tester interactuando con diferentes roles, pero dado que este es independiente, se encuentra aislado del resto del equipo.

Luego, en Agile hay un solo equipo con una estructura más horizontal, que comparte la responsabilidad de la calidad sin distinguir los diferentes roles involucrados.

Pero como puede ver en Agile, el desarrollo termina cuando el “paquete” se pasa a operaciones para luego lanzarlo a producción. En el Kanban del equipo, veríamos que el concepto de “hecho” implica que el código está listo para producción, pero aún no está en manos del cliente. Agile siempre elogia al “equipo”, pero no incluye a los miembros del equipo de operaciones, soporte, etc.

Creo que las señales son claras, DevOps enfatiza tener las conversaciones correctas, en el momento correcto, entre diferentes equipos para maximizar los resultados.

¿Está trabajando dentro de una cultura de DevOps? ¿Cree que ha llegado para quedarse? ¡´Hágamelo saber en los comentarios!