En artículos previos, mis compañeros os han introducido al concepto de Infraestructura como Código, a la creación de infraestructura en MS Azure por medio de Terraform, la creación de un entorno en AWS también por medio de Terraform y el uso de Ansible para testeo continuo.

En este post, me gustaría extender sus introducciones más allá del uso de determinadas herramientas como Terraform (TF), Ansible y productos Atlassian (Jira y Confluence) en entornos colaborativos; y lanzar algunas ideas que puedan ser útiles para todos aquellos que empiezan ahora a dar sus primeros pasos en DevOps, tecnologías Cloud y transformación digital.

El uso de herramientas como Terraform y Ansible, permiten tanto a un analista del equipo de sistemas, o de infraestructura y redes, o a un programador desplegar los componentes necesarios en cuestión de minutos, bien sea para hacer pruebas de código, para una demostración, o para comprobar efectos colaterales de un parche. Despliegues, hoy en día, bien en un entorno cerrado (sandpit) o en cuentas propias en Cloud, están al alcance de todos en cualquier segmento del ciclo de vida de una aplicación.

A fin de cuentas, es un hecho demostrado que la democratización de la infraestructura crea nuevas oportunidades y favorece la innovación, ya que el coste del "fracaso" se reduce dramáticamente. Uno de los lemas de DevOps es "Falla rápido, falla seguro". Es de esos errores de donde se aprende. Asimismo, uno de los principios de DevOps es el trabajo colaborativo en equipos multi-funcionales.

Entonces, si unimos estos conceptos: colaboración, multi-funcionalidad, democratización y les añadimos las herramientas mencionadas anteriormente, ¿cómo trabajamos en equipo? Y sobre todo ¿cómo trabajamos BIEN en equipo?.

Los ejemplos de mis compañeros responden al título de este blog: "En Mi Local Funciona". ¿Cómo lo hacemos para que no sea así? Otro compañero creó un artículo muy interesante acerca de diferentes técnicas y estrategias de mantenimiento de código en Git en el que se indican pautas a seguir para un correcto funcionamiento en equipo. ¿Son estas pautas también aplicables a IaC? Sí, claro que lo son, pero todos sabemos que a veces, en un ambiente multi-disciplinar, es difícil coordinar código y mantener una disciplina de equipo; con lo cual se acaba adquiriendo deuda técnica. Esto se experimenta en mayor medida en todas aquellas organizaciones en las cuales no se adopta el modelo Spotify. En estos casos, el equipo de desarrollo no se encarga del mantenimiento del producto y se produce una disociación entre las prácticas del equipo de desarrollo (en el caso de DevOps, desarrollo de plataformas y automatización de despliegues) y el equipo de operaciones. Nos encontramos de nuevo ante una situación en la que la integración DevOps es necesaria.

Así que, sin más preámbulos, aquí van unas sugerencias adquiridas en unos cuantos años de trabajo DevOps en entornos puramente Agile (sin ningún orden en particular).

Radar Tecnológico y clasificación de herramientas.

Si bien un enfoque ágil e innovador que use nuevas tecnologías favorece la investigación y el desarrollo, desde el punto de vista operativo siempre habrá reticencia a aceptar todo tipo de cambio para mantener la estabilidad de plataformas y sistemas. El aumento del número de herramientas a utilizar implica un periodo de formación y adaptación que puede crear incertidumbre y tensión interna entre equipos (Dev vs Ops). El uso de un radar tecnológico (como el del ejemplo básico mostrado en la figura 1) es importante para demostrar de un modo visual el tipo de tecnologías contempladas por el equipo de arquitectura. Pero es también conveniente el consenso entre equipos en cuanto al uso de las herramientas (no sólo visto como marcan las tendencias de mercado, sino como dictan las necesidades del negocio). El uso de TF para el aprovisionamiento de elementos semi-estáticos de plataformas y el uso de Ansible como herramienta de administración de configuración debe ser establecido sin ambigüedad.  Se debe dejar claro el rol de cada herramienta sin excepciones para evitar la acumulación de deuda técnica como mencioné previamente.

Fig 1 - Radar tecnológico

Mantener la versión correcta en las herramientas

En un equipo distribuido geográficamente (bien sea regional, nacional, internacional o global dependiendo de la política de empresa) en el cual puede haber asignaciones directas a proyectos externos, así como contribuciones a proyectos internos, puede llegar a ser posible trabajar con tres o cuatro versiones de la misma herramienta. Una opción es lanzar una VM (Vagrant / Virtualbox / VMWare Workstation) o un contenedor Docker y mantener separación estricta de versiones siempre y cuando miembros del mismo equipo trabajando en el mismo proyecto usen las misma VM. Siempre que sea posible, una opción más segura es el trabajo desde un servidor bastión. Pruebas locales se mantienen completamente aparte de la infraestructura sobre la que todo el equipo trabaja. El acceso remoto se cifra y se registra. Hay una traza de auditoría y las actualizaciones de versiones de la herramienta se hacen de modo uniforme cuando sea necesario y/o conveniente.

En otro párrafo mencionaré las áreas de trabajo desde el bastión.

El arranque de trabajos desde un servidor de IC (bien sean puntuales o un pipeline completo) se pueden crear con controles que se integran con ITSM (y/o metodologías ITIL). Para que esto suceda, es aconsejable tener un cierto grado de armonización en el proyecto ya que ayuda a la creación de un catálogo estándar y facilita la toma de decisiones por el equipo de gerencia. La carencia de estándares favorece la confusión y la obtención de resultados erráticos que minan la confianza en el equipo técnico, con lo cual se imponen más controles de implantación (precisamente para eliminar la incertidumbre).

Ansible Roles

Como mencionaba mi compañero en el artículo que cité al principio, Galaxy roles cambian de continuo. Algunos cambios son bienvenidos, otros puede que no lo sean tanto e introduzcan modificaciones que no sean del todo compatibles con versiones anteriores. Una solución es el clonado a un repositorio de empresa para mantener un repositorio Master "inmutable" del cual cada proyecto pueda clonar (por medio de forks) o del cual se pueda crear una rama con retoques específicos. Hay que asegurarse, si se adopta esta técnica, que el listado de roles sea común, y especificar la rama a usar en tu proyecto. En Ansible se pude crear un archivo de requisitos en el cual se especifique la rama o versión del código que se va a aplicar.

Código abstraído y reusable

Cada programador tiene su estilo particular y en un entorno cerrado es fácil saber quién fue el autor de un segmento determinado. Además del registro de Git, comentarios, estructura y discurso nos indican quién escribió qué. Aún así, el código debe seguir una pauta común. La estructura de Ansible nos permite parametrizar los playbooks y reunir las variables bajo el inventario, donde será más fácil seguir cada valor, y actualizarlo en un sólo punto, en lugar de hacer búsquedas globales e intentar discernir qué fue lo que llevó a esa decisión basado en comentarios de código que a veces no existen, o no están documentados ni en Ansible, ni en la bitácora de Jira ni en una página técnica de Confluence relativa al proyecto.
Al mismo tiempo hace el código reusable.

Fig2 Inventory tree.

Fig3 La parametrización de los playbooks los hace reusables en otros entornos.

En Terraform, crea un repositorio común para módulos compartidos y llámalo desde tus scripts. Define el tipo de las variables y a ser posible no declares valores por defecto a menos que haya buena razón o sean estándar en toda la empresa. Deja que sea el "back end" quien imponga sus parámetros por defecto y si necesitas valores distintos decláralos de manera explícita utilizando el tfvars para cada proyecto y entorno. Haz que tu código sea exportable y sea fácil de mantener y actualizar.

Fig4 Módulos compartidos evitan repetición y aseguran consistencia

En resumen: No reinventes la rueda en cada proyecto. Reusa, reusa, reusa.

Configura tu área de trabajo de un modo similar a tus compañeros

Cuando hablamos de servidores, cada usuario tiene su entorno como a él le gusta o mejor le parece. En ciertos casos, sin embargo, es más fácil hablar el mismo idioma, Por ejemplo, que Q: sea un directorio común (si es que trabajas en entorno Windows) o que el árbol de carpetas tenga la misma estructura si trabajas en Linux.
Estos casos se prestan a un "envoltorio".  El envoltorio nos crea el entorno de trabajo y nos permite trabajar de un mismo modo y hablar un mismo "idioma". El script de envoltorio puede ser tan sencillo o tan complejo como se requiera, y ofrece la posibilidad de combinar entornos, scripts y variables de repositorios múltiples. Ansible es una herramienta perfecta para esta labor. Crear un playbook para definir tu entorno y asegurarse de que cada ingeniero en el proyecto usa la misma estructura facilita la cohesión.

Usa con TF archivos de planificación y estado modulares y almacénalos remotamente.

Para evitar confusión, antes de empezar a ejecutar comandos y scripts de TF, es útil declarar el tipo de repositorio remoto para el output de los planes y los archivos de estado por medio de un archivo "backend.tf". Asegúrate que todo el mundo tiene acceso para leer y escribir en el directorio de destino y si es posible habilita el versionado de archivos. De este modo, incluso si los miembros del equipo se olvidan o posponen el push al repositorio, habrá un registro que coteje el plan y el estado de la infraestructura (incluso si es tan sólo por medio del fechado de los archivos).
El directorio remoto debe contener carpetas / subdirectorios para distintos componentes como se mencionó en el párrafo anterior. Hacer cambios modulares permite el cambio de ciertos elementos de la plataforma independientemente del resto (siempre que sea adecuado).

Bitácora de Jira

Ya sea Jira como panel Kanban o como herramienta de Service Desk, esta aplicación se ha vuelto un estándar de industria (o al menos de todos aquellos que han iniciado una transformación digital). Si el trabajo a realizar en equipo es modular, habrá un número de tareas que forme parte de una misma historia de usuario. Es posible que más de una persona esté colaborando en una misma tarea de modo asíncrono. Además de usar Git (en cualquiera de sus distribuciones "GitHub", "GitLab", "Bitbucket" etc.) y añadir comentarios en cada commit, es necesario mantener una bitácora. En Git explicamos el porqué de un cambio que hacemos al código (hago este cambio porque necesito esta funcionalidad). Generalmente no se registra en ningún lado "el por qué no". La bitácora de Jira es perfecta para esta tarea, bien por medio del "Work Log" y/o los "Comments", es posible capturar las pruebas que se han hecho y fracasado y la razón por la que fallaron. "Falla rápido, falla seguro" no se trata de intentar algo descabellado que sabes que va a fallar, sino de aprender de fallos occurridos explorando y evolucionar.

Si no se capturan las pruebas y las razones por las que no funcionaron, es posible que alguien más vaya a realizarlas y a fallar de nuevo, con la consiguiente pérdida de tiempo (y dinero). La comunicación es esencial en este aspecto. No uses las herramientas tan sólo como método de captura de tiempos de tarea. Comparte, explica, ten opinión. Cuando otro compañero se una a la tarea, en lugar de llamarte para ponerse al día, se podrá leer tus entradas de registro y si acaso, rematará con esa llamada de teléfono para que le expliques algo que será más corto e irá más al grano.

Si trabajas en un equipo en el que estás de mentor de compañeros menos experimentados, ofréceles la oportunidad de entender la dinámica del equipo, aprender de ti y de tu trabajo. Sé abierto y transparente. Lo mismo ocurre si eres un miembro junior de tu equipo. Aprende y cuestiona. Utiliza tu punto de vista fresco para cuestionar prácticas que no entiendes o te parezcan complicadas. ¿Hay un modo más sencillo para alcanzar lo mismo? Parte de la cultura de DevOps incluye un enfoque "sin culpa". No se trata de "echar la bronca" o "desafiar", sino de crecer como profesionales y como equipo, con colaboración y sobre todo con comunicación. Por medio de registros claros y detallados entendemos y mejoramos.

Confluence

Una vez que una pieza de trabajo (reusable) está acabada, funciona y cumple las expectativas, reflexiona en tu retrospectiva y captura lo que has aprendido en una página de Confluence (o Wiki). Si has documentado tu trabajo bien, te será fácil recopilar todas tus actualizaciones, registros y comentarios y darles forma. No caigas en la trampa de pensar "Documentar es lo que se hacía en proyectos de cascada". Lo que es obsoleto es documentar por documentar con páginas y páginas de texto tedioso que hay que rellenar para formalizar una entrega del producto A, o el servicio B. "Readmes" en Git, o páginas en Confluence / Wiki ofrecen documentos vivos y dinámicos. La oportunidad de escribir un resumen técnico para que lo lea un equipo técnico. Un documento adecuado a su propósito.

Cuando el término DevOps comenzó a oírse en los equipos de TI, muchos profesionales pensaron que era una moda, que todas las herramientas eran muy nuevas y relucientes pero que perderían su brillo y que los administradores de sistemas volverían a ser administradores de sistemas y los desarrolladores, seguirían siendo desarrolladores.

Lo que nunca llegaron a imaginar los "sysadmins" de la vieja escuela, es que DevOps es, sobre todo, un cambio cultural, y que las herramientas, al ser usadas con un nuevo enfoque, facilitan el ciclo de mejoras continuas. Mejoras no sólo en un entorno o para un cliente, sino para el equipo de DevOps en sí. Ser colaborativo no es tan sólo dejar tu escritorio para hablar con el equipo de redes, o decirle a un desarrollador que el entorno está listo.  Ser colaborativo es un enfoque en el que ser abierto y transparente, con unos medios de comunicación establecidos que faciliten el respeto, la confianza, el aprendizaje y la experimentación sin miedo son una ventaja y una apuesta de futuro. Y que el uso de herramientas en esta dinámica transforma un grupo de individuos usando "herramientas" en un equipo.

Si te ha gustado, ¡síguenos en Twitter!