Esta decisión puede ser muy compleja, sobre todo por la gran cantidad de herramientas que existen en cada una de las verticales. Esta complejidad logra incluso atentar, en algunos casos, contra la adopción de esta cultura.
En este artículo pretendemos mostrar según nuestra experiencia algunas herramientas ya probadas con el fin de servir de aceleradores en esta adopción. En cada categoría, la idea es resumir y presentar las que consideramos se encuentran en el top tres.
COLABORACIÓN Y GESTIÓN DE PROYECTOS
Es importante en todo proyecto ágil contar con herramientas de colaboración. La realidad es que existen muchísimas herramientas de este tipo y es importante lograr un justo equilibrio entre funcionalidades que proveen y la complejidad de uso. Esta ecuación puede ayudar a definir la herramienta correcta y deberá ser acordada por todos los integrantes del equipo de proyecto.
En nuestra experiencia la combinación de Jira & Confluence es muy completa tanto para la gestión total del proyecto como para la documentación de requerimientos y gestión del conocimiento, integrando incluso con varias de las otras herramientas que dan soporte al resto de los procesos de DevOps.
Slack es una plataforma de mensajería con esteroides. Muy útil por la cantidad de plugins que soporta y que permiten por ejemplo integrarlo con pipelines de CI/CD y sistemas de monitoreo para recibir notificaciones en tiempo real.
Trello es una herramienta de gestión de proyectos que se asemeja mucho a una pizarra de Kanban. Si la cantidad de funcionalidades de Jira resulta abrumadora, Trello es una buena alternativa.
ENTORNOS DE DESARROLLO (IDES)
Normalmente esta definición depende de cada persona, es más que nada un tema de gustos y costumbre. De hecho, en nuestro equipo usamos las tres indistintamente. Son multi-plataforma (MacOS/Linux/Windows) y tienen una gran cantidad de plugins que permiten adaptarlas a las particularidades de cada lenguaje (control de sintaxis, CLIs, snippets).
Atom y VS Code son gratuitas y de código abierto, mientras que Sublime puede usarse gratis durante un período de evaluación pero luego debe comprarse una licencia (~ U$S 80).
SOURCE CODE MANAGEMENT (SCM)
Es imprescindible en este camino definir una herramienta para la gestión del código fuente. Es normal en un equipo de desarrollo que este tipo de definiciones se tomen desde el día uno, pero no tan normal que un equipo de infraestructura lo tenga en cuenta al iniciar un proyecto.
Git como sistema descentralizado de gestión de código, se volvió un estándar de facto en la industria. Es por esto que todas las herramientas que proponemos lo soportan. Las tres opciones cuentan con versiones gratuitas y pagas, así como posibilidad de usarlo como SaaS o con instalaciones on-premise.
El equipo de DevOps deberá seleccionar una herramienta de SCM pensando en incluir todo tipo de código fuente que se genere durante el proyecto, como por ejemplo, la definición y configuración de la infraestructura.
Tener en cuenta la capacidad de integración de la herramienta SCM elegida con otras usadas durante el ciclo de vida de la aplicación. Por ejemplo, es importante poder llevar la trazabilidad entre el código que desarrollamos y el requerimiento que lo genera, así como poder comunicar fácilmente al resto del equipo cuando hacemos algún cambio. Por otro lado, el SCM debe poder comunicar a las herramientas de CI cuando hay eventos que modifican el código, para así poder disparar tareas de compilación de forma automática (una posibilidad para esto es el uso de WebHooks).
GESTIÓN DE LA CONFIGURACIÓN
Uno de los cambios de paradigma en el mundo de DevOps es que las configuraciones de los servidores se gestionan como código (CaC – Configuration as Code). Es decir, todo cambio sobre la configuración inicial de los sistemas operativos se debe hacer mediante scripts idempotentes. Estos tienen dos funciones: impactan la configuración que queremos y a la vez previenen que se hagan cambios que se desvíen de ésta.
Las herramientas propuestas logran todas ese objetivo, pero difieren mucho en como implementan el comportamiento. Un concepto clave a considerar es cómo la configuración es obtenida por los servidores controlados. Una opción es que un agente local corriendo en cada uno de los clientes, obtenga la configuración desde un repositorio maestro (en inglés, pull configuration). La otra opción es que un servidor central que hace de controlador se encargue de impactar la configuración en cada cliente (en inglés, push configuration). Cada opción tiene ventajas y desventajas, que deben ser examinadas de antemano. Este artículo muestra una comparativa de funcionalidades entre las herramientas propuestas y además describe otros conceptos de CaC.
COMPUTACIÓN EN LA NUBE
Las plataformas de computación en la nube o cloud computing, además de proveer una inmensidad de herramientas interesantes y funcionalidades, puede actuar como acelerador para desarrollar soluciones de IT. No solo para procesos de desarrollo, sino también para diseñar topologías de red y servidores. Cuando nuestros sitios on-premise tienen pocos recursos computacionales disponibles, apuntar hacia plataformas cloud para prototipar y probar, nos permite saltear estos cuellos de botella que ponen en riesgo a los proyectos.
Además, los proveedores de nube exponen APIs de administración sumamente expresivas que nos permiten controlas y monitorear los recursos. Esto va de la mano con otro concepto de DevOps que es el de mantener toda nuestra infraestructura definida mediante código (IaC – Infrastructure as Code).
A la hora de elegir una plataforma cloud, lo primero es evaluar la oferta de productos de cada uno. A pesar de ser muy similares, están en cambio constante y tal vez solo hay uno que provea un servicio que se ajusta a lo que necesitamos. También, considerar revisar la gobernanza y conformidad en cuanto a la gestión de nuestros datos, en especial si nuestra aplicación puede verse afectada por marcos regulatorios como PCI o SOX.
Por último, aunque no menos importante, revisar los costos. Los modelos de precio de los servicios cambian casi a diario y en muchos casos dependen de hasta la región geográfica donde se implementen.
INTEGRACIÓN CONTINUA / DESPLIEGUE CONTINUO
Las metodologías ágiles de desarrollo demandan que se maximice la cadencia de liberaciones al cliente, que se reduzca el time-to-market y que se minimice el tiempo de indisponibilidad de nuestra aplicación. DevOps enfrenta esto potenciando la automatización de la compilación del código y la liberación de artefactos a producción, conocido como pipeline de CI/CD.
Jenkins es una plataforma altamente personalizable y de código abierto, que permite implementar (entre otras cosas) nuestro pipeline de CI/CD. Es muy usado en la industria y tiene una gran comunidad que contribuye constantemente con nuevos plugins que hacen que Jenkins pueda integrarse fácilmente con otras herramientas. Existe una versión paga, con soporte oficial de CloudBees.
Visual Studio Team Services de Microsoft es una plataforma SaaS basada en el conocido Team Foundation Server, un gestor de código muy usado para .NET. En los últimos años, VSTS sufrió una gran cantidad de cambios que lo transformó en una plataforma multi-lenguaje, no solo para CI/CD sino también para la gestión de proyectos. Tiene una capa gratuita totalmente funcional, para pequeños proyectos. Luego hay un licenciamiento mensual por el uso de la plataforma.
TeamCity de Jetbrains es un poderoso sistema de CI/CD. Se integra muy bien con distintos SCM; permite comunicación nativa con proveedores de nube; contiene un sistema de gestión de la calidad del código que puede usarse como parte del proceso de compilación. Tiene una versión Professional que es gratuita y muy buena para comenzar, siendo su única limitante importante la cantidad de configuraciones de compilación que podemos crear.
ORQUESTADORES DE CONTENEDORES
Los contenedores proveen un ambiente autocontenido para la ejecución de aplicaciones, que ha probado ser muy valioso para simplificar el ciclo de vida del desarrollo, particularmente en etapas de integración y despliegue.
Un componente de software fundamental que aparece cuando usamos contenedores en producción son los orquestadores, encargados de la gestión de clústeres de alta disponibilidad donde se ejecutan nuestros contenedores.
Cada una de las opciones define un paradigma particular para la administración de los contenedores. Antes de elegir una plataforma, investigar sobre las características de cada una ya que definitivamente van a afectar la definición de otros de los procesos de DevOps del equipo. Este artículo provee una discusión interesante entre administradores de soluciones en cada una de las plataformas.
APPLICATION MONITORING
Tenemos nuestra aplicación en producción y tenemos un buen pipeline de CI/CD que lo soporta…es suficiente? Por supuesto que no. Luego de salir en producción necesitamos métricas para controlar el estado de la aplicación y para poder actuar rápidamente cuando surgen problemas. En realidad, queremos saber de los problemas antes de que sucedan, y para esto necesitamos una gran cantidad de información que nos ayude a predecir futuras fallas.
Los Application Performance Monitors (APM) son sistemas que nos permitirán tener un conocimiento profundo y en tiempo real del estado de nuestra aplicación. Para lograr una mayor percepción, elegir una herramienta que se pueda integrar con el lenguaje y el framework de desarrollo usados.
Esperamos que este resumen de herramientas sirva a ti y a tu equipo en el camino de DevOps!
