Consultores DevOps: entre purismo, pragmatismo, ética profesional y complicidades

La semana pasada comencé a trabajar en la segunda etapa de una iniciativa “DevOps”. Luego de la reunión del kick-off un colega que está trabajando conmigo en este proyecto pero que no había participado de la primera etapa me consulta: “¿qué onda esto de armar pipelines de deployment de aplicaciones sin ningún tests automatizado?”

¿Qué onda? Riesgoso. Lo hablé con el cliente y fui muy explícito:

“Por este camino más que DevOps vamos a hacer DevOoooops!”.

Habiendo hecho la advertencia del caso y siendo conscientes que el término DevOps queda grande para lo que estamos haciendo, mantuve mi ética profesional. Dejé mi purismo de lado y me convertí en complice de la situación con el único objeto de lograr una mejora en el proceso de software delivery. Concretamente lo que estamos haciendo es automatizar el proceso de build y deployment.

Previo a nuestra intervención varios proyectos generaban sus binarios en la máquina de un developer y luego los hacían llegar al área encargada de deployments via un sistema de tickets. Algunos otros equipos tenían un Jenkins, pero solo para compilación. Los encargados del deployment ejecutaban entonces varias tareas manual para desplegar el binario pedido en el ambiente especificado. En este este contexto estamos buscando que:

  • Todo el código esté almacenado en la herramienta oficial de versionado de la organización (GitLab)
  • Todos los binarios se generen en un servidor (GitLab-CI) sin depender de la máquina de ningún developer
  • Los binarios generados sean subidos automáticamente a un repositorio de binarios (Nexus)
  • El proceso de deployment comience descargando el binario a desplegar desde el repositorio de binario y a continuación ejecute un script parametrizado de forma de utilizar el mismo script para despliegue a todo ambiente.
  • El proceso de deployment sea ejecutado por una herramienta de CI/CD (GitLab-CI)

¿Esto es hacer DevOps? Esto solo no lo es. Sin duda una estrategia DevOps debería incluir versionado y automatización, pero también muchas otras cuestiones como colaboración entre negocio-desarrollo-operaciones, entrega frecuente, manejo de infraestructura como código, integración continua y pruebas automatizadas (como bien observaba mi colega).

Personalmente suelo hacer mucho hincapié en todas esta cuestiones y las aplico en todos los proyectos en los que trabajo como team member. Sin embargo, cuando hago trabajo de consultoría, no está en mí decidir qué prácticas aplicar. Claro que sugiero (con mucho énfasis en general) pero la priorización y decisión está en manos del cliente. Lo que suele ocurrir es que dentro de todo el set de prácticas DevOps, una de las que ofrece mayor visibilidad y retorno temprano de inversión es la automatización de deployments. Entonces se suele comenzar automatizando los deployments de una aplicación y a continuación surge el dilema, ¿avanzamos en ancho o en profundidad?. O sea: ¿seguimos trabajando sobre esa aplicación para agregarle pruebas automatizadas (y demás prácticas)? o ¿nos movemos al equipo de al lado para seguir automatizando deployments? En general mis clientes suelen optar por lo segundo, avanzar en ancho y dejar en manos del cada equipo el avance en profundidad (pero esto no siempre ocurre). Obviamente que esto no es lo mismo en todos los clientes, esta descripción corresponde a una organización muy grande con cientos de equipos de equipos de desarrollo y varios cientos de aplicaciones.

En fin, esta es la vida del “consultor responsable”, bailar el fino equilibro entre purismo y pragmatismo honrando siempre la ética profesional.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.