Las herramientas constituyen uno de los aspectos más conflictivos de las Tecnologías de la Información modernas. En tiempos del abuelo Cebolleta no había tantas como hoy en día y cuando alguien necesitaba automatizar o gestionar una actividad tenía que construir por sí mismo la herramienta que lo permitiese. Era obviamente complicado porque implicaba disponer del tiempo y la capacidad necesarios para hacerlo cada vez que surgía un nuevo requerimiento.
En la actualidad existen herramientas para cualquier tipo de función que necesitemos cubrir, ofrecidas por decenas de proveedores, algunos convencionales y otros open source. La complejidad viene ahora de que corremos el riesgo de centrarnos en las particularidades propias de la herramienta y olvidarnos del proceso. Desgraciadamente, todas las grandes organizaciones tienen experiencia con este tipo de situaciones y cuentan con herramientas que se han implantado de manera extensiva para terminar arrinconadas o con un uso muy limitado.
En la película “El pistolero” (Henry King, 1950), Gregory Peck interpreta a un pistolero maduro que intenta abandonar su vida violenta para iniciar una nueva etapa junto a su mujer y su hijo. Pero su fama le precede y siempre encuentra algún inconsciente bravucón que quiere ganarse la fama como “el hombre que mató a Jimmy Ringo”. De modo que su mayor virtud, la habilidad en el manejo del revólver, se ha convertido también en su maldición…
En esta película, como en casi todo el cine western, la herramienta por excelencia es el revólver, esa pistola con un tambor de cinco o seis balas que gira alrededor de un cañón y con las cachas de hueso, madera o metal. Incluso todos conocemos cuál fue el fabricante y modelo más exitoso del oeste: el Colt 45. Un arma versátil y tremendamente eficaz en las manos de un experto adecuadamente entrenado, aunque con riesgos enormes en manos temerarias.
Pues bien, algo parecido ocurre con las herramientas para automatizar el ciclo de vida del software, en lo que se ha denominado continuous delivery (entrega continua) y es uno de los elementos fundamentales de un modelo de trabajo DevOps. En este escenario también hay un “colt”, que no es una herramienta, sino un conjunto de ellas.
¿Qué necesidades hay que cubrir para realizar la entrega continua de manera eficaz? Éstas son las diferentes categorías con algunos ejemplos, sobre todo de fuente abierta:
- Primero y fundamental, una herramienta de gestión de la configuración del código. Comúnmente se conocen como repositorios, pero su función principal no es tan solo albergar ficheros de código fuente, sino el control de versiones. Aunque las herramientas modernas permiten la concurrencia de varios desarrolladores sobre el mismo código, esta necesidad se minimiza en DevOps ya que, como he comentado en un artículo anterior, las piezas de código deberán ser pequeñas. Tenemos importantes herramientas en esta categoría, pero destacan dos productos open source: GIT y Subversion.
- Ya tenemos el código. Ahora hay que construir los ejecutables, básicamente compilar y enlazar. Ésta es una tarea que normalmente se ejecuta desde el entorno de desarrollo -típicamente Microsoft Visual Studio para entornos Windows y Eclipse para entornos Linux-, aunque han aparecido herramientas como Maven o Ant (ambas de la fundación Apache) que, con lenguaje Java, complementan estas actividades y resuelven las dependencias. La buena noticia es que la integración de Eclipse con Maven o Ant, al igual que con GIT o Subversion es muy sencilla.
- La automatización de las pruebas, sean de código, de sistema, de servicio, regresivas, etc. va a permitir que los cambios que se realicen en el software sean verificados, lo que garantiza la calidad. Incluso permiten la ejecución de juegos de pruebas diarios y/o semanales durante la noche que permiten tener un informe de resultados a primera hora de la mañana. Aquí la variedad de herramientas es casi infinita en lo que se refiere a proveedores convencionales. En el mundo open source hay productos muy interesantes como Selenium o Windmill para funcionalidad web, JMeter para pruebas de carga e incluso Taurus que funciona como framework por encima de las demás.
- Y qué estupendo sería contar con una herramienta de orquestación, de forma que cuando surja un evento, como que un desarrollador haga cambios de su código, empiecen a suceder cosas como la promoción del código a los entornos de integración, la notificación a los siguientes “jugadores” de la cadena, o el lanzamiento a ejecución de pruebas. Pues esta herramienta maravillosa existe y es el verdadero corazón de la entrega continua. El auténtico rey de esta categoría, entre multitud de alternativas privadas y de fuente abierta, es Jenkins.
- En la parte del despliegue también hay una legión de herramientas disponibles. Pero, si me permitís que continúe aferrado al open source, ahora toca un dilema: ¿Queremos manejar las aplicaciones (y sistemas) como lo hemos hecho toda la vida, sea en físico o en virtual, o estamos dispuestos a transformar esa forma de hacerlo por una serie de capas de cebolla que se pueden desplegar con relativa independencia? Si optamos por lo primero, están Puppet o Chef (aunque tambien hay otras). Pero si nos atrevemos con la posibilidad de que las pequeñas piezas de código no solo se puedan desarrollar y probar con independencia del resto, sino que su despliegue se haga como una “pieza de lego” separada, entonces, queridos amigos, tenemos todo lo necesario para empezar a trabajar en Linux con Docker. Aunque, os lo advierto, el modelo es adictivo (Docker cuenta con su propia familia de software como interfaces de usuario, monitorización, gestión de bibliotecas…) y, una vez que os acostumbréis a trabajar con él os resultará difícil salir.
- Y, aunque son absolutamente imprescindibles, solo voy a mencionar las herramientas de operación, monitorización y planificación, porque no son propias de este modelo de trabajo.
Y, para terminar, dos herramientas complementarias:
- El repositorio de artefactos: muchas organizaciones implantan también un repositorio de lo que en mis tiempos se llamaban los ejecutables. Aunque más que un repositorio sin más, deberíamos hablar de un catálogo de componentes. Aquí, el rey en el mundo open source es Nexus. He preferido no incluirlo en la lista anterior porque no lo considero un elemento fundamental en un ciclo de vida del software. Aunque para gustos hay colores…
- Gestión de proyectos: a este respecto quiero proponeros una herramienta tan adictiva como comentaba que era Docker. Se trata de un invento de Toyota: el tablero Kanban. Lo único necesario para empezar es una pared y un taco de postits. Pero también encontraréis otras herramientas disponibles como Jira o, de fuente abierta, Kanboard.
En este post os he expuesto un conjunto de herramientas con las que es importante que cuente un equipo DevOps porque ayudan a automatizar el ciclo de vida del software, pero lo más importante es el criterio, que tenga libertad para escoger el juego de herramientas que le resulte más valioso. Evidentemente, habrá que coordinar el catálogo de herramientas entre todos los equipos DevOps de una compañía, para evitar una enorme dispersión, pero esa libertad para escogerlas siempre dará resultados positivos.
Durante el transcurso de la película “El pistolero” vamos siendo conscientes de que un mal uso de una herramienta bien construida puede terminar con resultados dramáticos. La clave para minimizar el riesgo está en no dejarnos cegar por la herramienta en sí misma y sus maravillosas posibilidades y centrarnos en el proceso: se trata de tener claros los objetivos y las métricas que los soportan, construir una operativa acertada y, ahora sí, administrarla y automatizarla con las herramientas que veíamos.
Imagen: Paul Reynolds
Soluciones y Sectores
Te puede interesar
-
Kanto integra una nueva forma de pago en su Living App de Movistar Plus+
La Living App de Kanto es una de las experiencias digitales disponible en la sección "Apps" de Movistar Plus+. ...
-
"La transformación digital va de personas, no de algoritmos”
El “70 por ciento de los procesos de transformación digital fracasan” porque “el arte de transformar, inherente al ser ...
-
Futures Thinking: pensar futuros para transformar el presente
Aún recuerdo mi primera cámara fotográfica. Era una Kodak compacta, de bolsillo, que trajo mi tía de Alemania. Yo ...
