Siendo permeable al mundo DevOps

Este post no se trata de descubrir nada nuevo sobre DevOps. Es más bien, como developer freelance principalmente, comenzar a documentar algunas pequeñas prácticas que, posiblemente, puedan encuadrarse dentro de ésta nueva categoría en el blog.

Lo primero que uno trata al acercarse a este tema es intentar buscar una definición. Como no podía ser de otra manera, vamos a encontrar infinidad de sabores.

Posiblemente no todos se pongan de acuerdo en cómo definir hasta dónde si y hasta dónde no se trate de DevOps. (Incluso se sabe de discusiones sobre si DevOps, Devops o devops)

De todo lo que he leído (algunos libros específicos y mucha discusión), decido quedarme con algunas partes de varias definiciones.

Por un lado, DevOps es más que una metodología de desarrollo de software. Al mismo tiempo, no es una cultura; aunque si necesitará de cambios en todo el equipo u organización (técnica y no técnica) para poder llevar adelante la metodología.

Algunas de las características que me gusta resaltar por fuera de las obvias, son:

  • Garantizar la estabilidad del código.
  • Es tan importante el agregar valor como la reducción de costos.
  • Implica, también, la necesidad y el desarrollo de software que usaremos nosotros mismos para llevar adelante la práctica.
  • Primero manual, luego automático.
  • Todo se debería de poder medir y usarse para mejorar.

Hay varios detalles más, sin dudas. No lo mencioné aún pero, claro está, se da por sentado un ciclo de desarrollo de unos 6 a 8 pasos.

Si le hago caso a la imagen inicial del post, veríamos (más o menos) que:

  1. Planificamos el desarrollo (tomamos requerimientos, definimos, etc)
  2. Desarrollamos.
  3. Testeamos (de forma automatizada y manual)
  4. Deployamos código.
  5. Se pone en funcionamiento.
  6. Se monitorea y mide.

Y luego se vuelve a empezar.

En el caso de la imagen del comienzo, los pasos de Build y Release suelen suceder. Depende a veces del tamaño del proyecto y/o de la tecnología. Pero no me interesa concentrarme en la discusión tan específica.

Toda esta introducción tiene que ver con un enfoque más específico, relacionado con el título. Desde hace un tiempo (no tanto como hubiera debido) hacia acá he ido intentando incorporar ciertas prácticas, herramientas y aprendizajes; incluso en los proyectos que no tienen rentabilidad alguna.

Siguiendo esa idea y tomando principalmente las características que resalté antes, es que algunos procesos de desarrollo y gestión los he ido cambiando. En algunos casos la mejora es inmediata, en otros todavía no estoy seguro (y en algunos sigo buscando nuevas opciones).

Uno de los cambios más claros ha sido la adopción de Docker para entornos locales (aún no estoy en condiciones de llevarlo a producción). Pero también hay otras herramientas que he estado usando y sobre las cuales voy a ir escribiendo, describiendo por qué, qué cambio introduce, qué mejora tuvo y cómo lo terminé implementando.

Estoy lejos… lejísimos de ser un perfil DevOps, pero apuesto a que en la interacción que siempre se genera, pueda seguir aprendiendo.