Esta semana conversaba con un amigo sobre cómo el mercado ha transformado un gran concepto en un aspecto netamente comercial que a su vez ha generado nuevos roles, herramientas y cosas que de alguna u otra forma, estamos agregando a nuestro CV.

Si bien es cierto el título del post es algo pretencioso, es lo que pienso y digo cada vez que converso sobre este tema.

Las pocas veces que he conversado con expertos en la materia (quienes por “extrañas” razones, no lo mencionan como la clave de su hoja de vida), además de notar cierta molestia en ellos, me encuentro con dos cosas que pueden parecer obvias:

1. DevOps no es un conjunto de herramientas.
2. DevOps es una cultura, una filosofía.

Ahora que lo pienso, es gracioso recordar que hace años noté lo mismo cuando conversaba sobre Metodologías Agiles y/o de Scrum (Por cierto ¿Es un framework o una metodología?). Y es que, el mercado termina confundiendo las cosas y a veces uno por necesidad o desconocimiento, confunde a alguien, se confunde por su cuenta o es confundido por otra persona (¡Pues el mercado lo hizo una vez más!)

Sin animo de quejarme sobre como vemos o usamos Scrum (¡es una metodología!), regreso a DevOps y concuerdo en que no debemos confundir herramientas con aquel espíritu filosófico que, desde mi punto de vista, involucra tres principios:

1. Compartir
2. Automatizar
3. Medir (y mejorar)

Estos principios ganan sentido si es que, buscando llegar a un caso práctico, notamos que nuestros despliegues internos o incluso nuestros pases a producción, son manuales y/o toman mucho tiempo.

Teniendo esto, lo que podríamos hacer sería lo siguiente:

1. Tenemos que medir el tiempo efectivo que demora un despliegue. Este debe incluir lo que toma la ejecución del pase (no importando si de trata del clásico copiar y pegar) y la configuración que se hace posterior a este (por ejemplo, entrar al entorno y ejecutar algunos pasos para que el sistema funcione adecuadamente)
2. Ya que conocemos los pasos del despliegue, debemos automatizarlos. Lo normal es que empecemos con la automatización de la ejecución principal, pero no debemos olvidar las configuraciones posteriores. Estas se pueden convertir en scripts que trabajen por su cuenta.
3. No debemos perder el foco en el nuevo tiempo de pase, pues este debe ser menor al que se tenía antes de empezar los cambios. Si no se ha logrado este objetivo, tenemos que revisar cada automatización y optimizar aquellos puntos que necesiten ser afinados.
4. Para culminar, debemos compartir:
   • El resultado de la medición, el cual –a futuro– se podría transformar en un reporte a demanda.
   • Explicar ¿Cómo diablos hicimos esto? pues se busca que el equipo tenga la confianza de implementar soluciones similares o de mejorar las que acabamos de crear.

Con el paso del tiempo encontraremos que algunos puntos tienen requisitos más importantes que otros. De todos ellos, creo que el principal es la gestión de versiones del código fuente.

Llegando a este punto, yo creo que no importa si hablamos de una herramienta de primera generación (como por ejemplo SourceSafe, qepd) o de una herramienta de tercera generación (gracias Linus por crear Git). Pues nada importa si es que no hay una cultura sana de gestión de versiones.

Una buena cultura indica que por lo menos debemos seguir estándares y buenas prácticas que, si no tenemos a la mano, podemos encontrar fácilmente (creo).

Luego de implementar una correcta gestión de versiones, hay muchas ramas que podemos seguir (¿se entiende la broma?), pero creo que el próximo paso debe ser automatizar la integración del código. No importa de qué forma (por línea de comandos sería una exageración) ¡pero debemos comenzar a hacerlo!

Personalmente no recomiendo que se hagan compilaciones por línea de comandos por más rápidas que estas sean ¡por dios! Estamos en el 2017 y para estos casos, comprar memoria y un producto de integración continua sale muy barato. Incluso hay herramientas muy buenas que te pueden salir gratis!

Si el equipo es consciente de los beneficios de la integración continua, comprenderá la necesidad de ir incluyendo filtros a este proceso. De estos, los más conocidos son implementaciones como:

• La automatización de pruebas unitarias
• La automatización de analizadores estáticos de código

Analizando lo que hemos logrado…

Hasta este punto, el equipo de desarrollo (Development) ha encontrado una salida automatizada al trabajo realizado por el equipo de Infraestructura o de Operaciones (Operations), el cual muchas veces depende de las secuencia de pasos detallada en un manual de instalación.

Muchas veces, por necesidad del  equipo de desarrollo, es que se llegan a cumplir estos objetivos y es genial tener cosas así, pero lo adecuado es que se forme un equipo multifuncional (de ahí el nombre DevOps que invita al mix) que se enfoque en este tipo de bondades, con las cuales se debería permitir que el equipo de proyecto (ya no solo el desarrollador) acceda a servicios como:

1. Integración continua (periódica o a demanda)
2. Despliegue continuo (periódico o a demanda)
3. Automatización de configuraciones post-despliegue
4. Ejecución de backups (a demanda)
5. Depuración de logs (a demanda)

Si no he logrado explicarme bien, lo que quiero decir es que el equipo de DevOps tiene que ser visto como la evolución del equipo de operaciones. Equipo que a pesar de (inicialmente) brindar los mismos servicios que el viejo equipo de operaciones, estos servicios deben cumplir con lo siguiente:

1. Toda ejecución rutinaria debe ser automatizada
2. Toda ejecución rutinaria se debe brindar como un autoservicio: El equipo de proyecto puede acceder a ella sin necesidad de acudir al equipo de DevOps
3. Se debe brindar soporte y mejora continua a los dos puntos anteriores.

Por mi parte…

Cuando empecé a automatizar compilaciones, fue por la necesidad de evitar esos tres o cuatro (¡o cinco!) días que gastaba un equipo para integrar su código. Siempre tuve mis dudas pero respeté su técnica hasta que pude compartir (principio #1) un experimento que hice una vez en casa. La integración continua había nacido en el trabajo (principio #2) y poco a poco íbamos notando que en el horario de almuerzo muchos publicaban código sin revisar algún break del build por lo que definimos reglas internas (principio #3)

Con ese equipo no logramos implementar el despliegue continuo pero era claro que un bicho había nacido. Confirmé una vez más que la automatización es amiga de aquellos flojos que se toman las cosas en serio (flojos entre los cuales me incluyo)

En otras experiencias logramos implementar el despliegue continuo y también agregamos la ejecución de pruebas unitarias y el análisis de código.

Cuando se llega a ese punto, las cosas se ponen serias pues los indicadores son números vivos que si no manejas bien, pueden absorber el tiempo del proyecto y se tiene que decidir entre mejorar o avanzar con las funcionalidades.

Ya saben, todo es relativo.

¿Qué recomiendo?

Ok, no soy un experto en el tema pero creo que se deben considerar los siguientes criterios:

1. El equipo de DevOps tiene que ser un equipo paralelo al de desarrollo.
2. Este nuevo equipo debe ser visto y actuar como una mesa de atención de servicios a demanda.
3. Los servicios pueden ser utilizados por el equipo de proyecto. Con esto, fácilmente un Jefe de Proyectos podría ejecutar un despliegue al ambiente de pruebas o verificar si la integración del código no presenta problemas.
4. Luego de automatizar las funciones primordiales del “viejo equipo de operaciones”, se debe continuar con aquellas no tan “tradicionales”, como por ejemplo:
   1. Implementación de un nuevo ambiente de desarrollo
   2. Creación de un ambiente temporal de pruebas
   3. Configuración de la integración sobre una rama de código para que el despliegue se haga sobre un ambiente temporal
   4. Transporte de configuraciones: De desarrollo a pruebas y de pruebas al ambiente de producción.

Como habrán notado, no he mencionado los principios de la filosofía (pues son inherentes a todo lo que hemos conversado) y si me preguntan cual es el paso más complicado, mi respuesta es, que primero debemos empezar y (como siempre) luego debemos ir viendo lo que necesitamos.

Con respecto a la implementación, la verdad es que no todos necesitamos todo lo recomendado. Como ejemplo, he mencionado entre líneas conceptos de Infraestructura como código y sería genial implementarlo, pero a veces no es necesario. Recuerden, no hay que perder foco en el tiempo que tomen las automatizaciones, a veces hay casos en los que es más rápido copiar y pegar porque quizá se necesite muy raras veces.

Habiendo dicho eso, es posible que algún dios DevOps haya muerto o haya cerrado el post o me esté enviando alguna maldición automatizada. Pero me mantengo en lo que dije, es la verdad. Todo a su tiempo 🙂

Un abrazo
JD