¿Trabajas en entornos de la JVM y a menudo tienes que cambiar de versión de los distintos SDKs? ¿Programas en Ceylon, Groovy, Kotlin o Scala?, ¿generas tus builds con Ant, Maven, Gradle o SBT?, ¿eres de Spring Boot, Grails o Vert.x? Entonces SDKMAN! es para ti.
SDKMAN! es una herramienta para manejar múltiples versiones de distintos SDKs en sistemas Unix (aunque también existe una versión alternativa para Windows). Proporciona una interfaz de línea de comandos y un API para instalar, cambiar, eliminar y mostrar la lista de candidatos. Anteriormente se conocía como GVM: Groovy enVironment Manager porque sólo se centraba en herramientas relacionadas con el ecosistema Groovy pero desde hace más de un año sirve para instalar más herramientas, SDKs y lenguajes de la JVM.
En este artículo veremos cómo instalarlo, utilizarlo y sacarle partido y además hablaremos con Marco Vermeulen, su creador, que amablemente nos ha respondido unas preguntas sobre SDKMAN!
Instalando SDKMAN!
La instalación es muy rápida y sencilla, abrimos un terminal y ejecutamos:
$ curl -s "https://get.sdkman.io" | bash
Y a continuación, tal y como indica al terminar la instalación podemos abrir un nuevo terminal para que se carguen las variables de entorno necesarias y esté todo disponible.
Empezamos: Listando los candidatos
Probablemente lo primero que queramos hacer una vez instalado sea ver la lista de todo lo que podemos gestionar.
$ sdk list
Este comando muestra los veinticuatro toolkits, frameworks, lenguajes y herramientas que actualmente se pueden gestionar a través de SDKMAN!
El siguiente paso es decir cual queremos instalar y ver las versiones disponibles. Utilizaremos Groovy:
$ sdk list groovy
================================================================================
Available Groovy Versions
================================================================================
2.4.7 2.3.2 2.1.2 1.8.6
2.4.6 2.3.11 2.1.1 1.8.5
2.4.5 2.3.10 2.1.0 1.8.4
2.4.4 2.3.1 2.0.8 1.8.3
2.4.3 2.3.0 2.0.7 1.8.2
2.4.2 2.2.2 2.0.6 1.8.1
2.4.1 2.2.1 2.0.5 1.8.0
2.4.0 2.2.0 2.0.4 1.7.9
2.3.9 2.1.9 2.0.3 1.7.8
2.3.8 2.1.8 2.0.2 1.7.7
2.3.7 2.1.7 2.0.1 1.7.6
2.3.6 2.1.6 2.0.0 1.7.5
2.3.5 2.1.5 1.8.9 1.7.4
2.3.4 2.1.4 1.8.8 1.7.3
2.3.3 2.1.3 1.8.7 1.7.2
================================================================================
+ - local version
* - installed
> - currently in use
================================================================================
Para instalar la última versión disponible sólo es necesario ejecutar:
$ sdk install groovy
Y listo, ya podemos usar Groovy.
$ groovy -version
Groovy Version: 2.4.7 JVM: 1.8.0_91 Vendor: Oracle Corporation OS: Linux
Gestionando distintas versiones
La verdadera ventaja de SDKMAN! es cuando tenemos que trabajar con distintas versiones y tenemos que cambiar entre ellas.
Partiendo del ejemplo anterior, imaginemos ahora que queremos cambiar a una versión más antigua de Groovy.
$ sdk install groovy 2.4.1
# Cambiamos a esta versión de Groovy
$ sdk use groovy 2.4.1
Using groovy version 2.4.1 in this shell.
$ groovy -version
Groovy Version: 2.4.1 JVM: 1.8.0_91 Vendor: Oracle Corporation OS: Linux
Y así de sencillo, no tenemos que preocuparnos de nada más. No es necesario ir a la web y buscar en enlace de descarga de la versión anterior. Descargarla, descomprimirla, cambiar el classpath para utilizar ésta en lugar de la anterior,... Nada, simplemente instalarla y comenzar a utilizarla.
¿Qué puedo instalar y gestionar con SDKMAN!
Como comentamos al principio del artículo SDKMAN! permite gestionar, instalar y utilizar más de veinte toolkits, frameworks, herramientas y lenguajes:
- Lenguajes: Ceylon, Groovy, Kotlin y Scala.
- Herramientas de Build: Ant, Gradle, JBoss Forge, Kobalt, Maven y SBT.
- Documentación: AsciidoctorJ y Gaiden.
- Frameworks y tookits de desarrollo: Activator, Grails, Glide, Griffon, SpringBoot y Vert.x.
- Varios: CRaSH, GroovyServ, JBake, JBakery, Lazybones y Sshoogr.
Involucrando a la comunidad
Probablemente estás pensando que todo esto está muy bien pero seguro que te haces la siguiente pregunta ¿y cuánto tarda en actualizarse SDKMAN! con la nueva versión de Grails, Groovy, SpringBoot o Kotlin? La respuesta es muy sencilla: Nada, es instantáneo. Esta es una de las razones por las que SDKMAN! se ha convertido en el estándar de facto para la gestión de las distintas versiones. ¿Y cómo es eso posible? Marco ha creado un API para que los distintos vendors puedan notificar automáticamente a SDKMAN! de las nuevas releases.
Si nos fijamos en la hora de los tweets vemos que ambos son de las 17:40 del día 4 de Julio. En el mismo momento que el equipo de Pivotal publica y anuncia la nueva release de Spring Boot notifica a SDKMAN! para que haga lo propio. A partir de ese momento, la nueva versión de SpringBoot está lista para su descarga desde SDKMAN!
Incluso ocurren situaciones curiosas como que la nueva versión de Grails es anunciada dos horas antes en SDKMAN! que por el equipo de Grails.
Bonus track: Entrevista con su creador, Marco Vermeulen
Como parte final a este artículo hemos aprovechado para hacerle unas cuantas preguntas a Marco que amablemente nos ha contestado:
¿Por qué y cómo decidiste desarrollar SDKMAN!?
El proyecto nació debido a la frustración de tener que trabajar con SDKs en mi entorno de desarrollo local. Por aquel entonces estaba trabajando mucho con Grails y, cuando desarrollaba plugins tenía que cambiar continuamente de versión de Grails para probar la compatibilidad. Decidí que tenía que haber una manera más fácil así que me embarqué en construir un SDK manager.
Decidí escribir la aplicación siguiendo totalmente BDD así que empecé escribiendo un montón de especificaciones que subí a github para que la comunidad me diera feedback. Cuando todos estuvimos contentos con las especificaciones empecé a desarrollar las funcionalidades.
¿Puedes explicar el stack tecnológico de SDKMAN!? La arquitectura, lenguajes de programación utilizados, frameworks, toolkits,...
El stack tecnológico es diverso y al final he terminando utilizando la tecnología adecuada según las necesidades. Básicamente se trata de una aplicación cliente/servidor aunque no en la manera tradicional. El cliente es una interfaz de línea de comando (CLI) y necesita funcionar en cualquier plataforma, así que elegí Bash. No sólo está disponible en cualquier sistema Unix sino que el tiempo de arranque es instantáneo. El cliente Bash utiliza curl, zip awk y sed como dependencias y éstas se encuentran disponibles en cualquier plataforma.
La parte servidora tiene una arquitectura de microservicios. Aquí tomé la decisión pragmática de exponer los endpoints del API como REST CSV en lugar de utilizar JSON. Esto es así porque un CSV es muy fácil de manejar con bash.
El API que sirve las peticiones del CLI consiste básicamente en tres servicios: Candidates, Broadcast y Download Broker. Están escritos con diferentes tecnologías y lenguajes (Vert.x, Spring Boot y Ratpack, utilizando Groovy y Java como lenguajes). La persistencia está en MongoDB.
Además de esto tenemos unas APIs de vendors que utilizan los distintos equipos tecnológicos para publicar sus versiones en SDKMAN. También estan escritas en una variedad de tecnologías como Spring Boot, Play, Scala y Groovy.
¿Cómo se testea todo?
El CLI y todos los componentes del servidor tiene una suite de tests de Cucumber con definiciones escritas en Groovy. También usamos Spock y Scalatest para los test unitarios. Todo está escrito desde una estricta aproximación test-first.
¿Dónde está alojado?
Todos los servicios se construyen cuando se hace push a Github utilizando Travis CI. Cada build produce una imagen de Docker que finalmente se publica en Docker Hub. El deploy se hace utilizando Docker Compose en Digital Ocean.
El proyecto ha sido open source desde el principio. ¿Hay alguna mejora o feature que te gustaría que alguien de la comunidad desarrollara y te enviara un pull request?
Sí, me encanta desarrollar y contribuir al open source. Es una forma de devolver algo a las comunidades de las que recibimos tanto cada día. Actualmente tenemos un tablón de ZenHub (se necesita plugin del navegador para verlo) para el proyecto y tiene un backlog con todas las issues y nuevas funcionalidades pendientes. Nos encanta recibir pull requests pero estate preparado primero para tener una conversación con nosotros antes de empezar a desarrollar. Además, la mayoría de los pull requests requieren una amplia batería de tests acompañando al código.
¿Cuáles son los planes de futuro? ¿Veremos los JDK publicados en SDKMAN!?
Actualmente estoy trabajando en la infraestructura que nos permitirá soportar binarios multiplataforma (¡como los JDKs!). Espero terminar esta funcionalidad en uno o dos meses. ¡Sí, definitivamente tendremos los JDKs disponibles pronto! Después de eso tengo planes para re-escribir y mejorar algunas de las APIs actuales de los servicios de backend.
Más información | SDKMan
Ver todos los comentarios en https://www.genbeta.com
VER 0 Comentario