Despliegue remoto instantáneo con Jrebel [Deprecated]

Necesitaba una forma de sincronizar rápidamente cambios en el código JAVA sobre el servidor Glassfish en entorno de pruebas en remoto, el proceso que conocía era que desde Eclipse IDE exporte el proyecto empaquetándolo en un .war, y luego hacer "deploy" en el administrador de Glassfish 4.1, el cual era una solución válida para nosotros, pero siempre tuve en la cabeza el termino "Entrega Continua", intentamos usar Jenkins (en algun momento veré esta herramienta fenomenal), pero la solución que pronto describo fue la más certera para este caso, por ello lo comparto en esta mi primera entrada. ☝

Para los que van directo a la solución, resumo que la idea es que estando codificando en Eclipse IDE Neon 2.0 y con los avances de mis requisitos listos y probados en mi servidor local, puedo sincronizar inmediatamente con el servidor remoto de prueba Glassfish 4.1, y los avances estan en ese instante publicado en dicho servidor remoto, dame un G+ por eso. 😀

 Entonces, a lo que vinimos!.

Infraestructura  en desarrollo:
+ MacOS Sierra 10 con Eclipse IDE Neon 2.0.
+ Java 8.
+ Plugin Glassfish Tools.
+ Glassfish 4.1.
+ Plugin JRebel 7.0.

Infraestructura en servidor remoto de pruebas:
+ Ubuntu 16.04.
+ Java 8.
+ Glassfish 4.1.

El asunto empieza en lo siguiente (asumo que ya conocen y usan JRebel en local):

1. Descargar el archivo "Standalone Jrebel" para el soporte de servidor remoto de JRebel para Eclipse, a la fecha ubicada en https://manuals.zeroturnaround.com/jrebel/remoteserver/eclipse.html.

2. Este archivo es  jrebel.7.0.4-nosetup.zip que debes subir a tu servidor y ubicarlo en la ruta que quieras (cuidado con los permisos del archivo), en mi caso esta en /home/ubuntu; luego debes descomprimirlo, generando ahora una carpeta jrebel.

3.  La clave en el servidor es insertar parametros de inicio al servidor Glassfish, en la carpeta descomprimida existe un un directorio llamado legacy en el que se encuentra el archivo jrebel.jar. Son 2 los parametros a agregar, para ello Glassfish debe estar encendido.

$ sudo /opt/glassfish4.1/glassfish/bin/asadmin create-jvm-options "-javaagent\:/home/ubuntu/jrebel/legacy/jrebel.jar"

$ sudo /opt/glassfish4.1/glassfish/bin/asadmin create-jvm-options "-Drebel.remoting_plugin=true"

4. Solo queda reiniciar el Glassfish.

$ sudo /opt/glassfish4.1/glassfish/bin/asadmin restart-domain

5. Ahora debemos configurar nuestro Eclipse IDE, primero, el workspace del server, para ello debemos estar en la perspectiva JRebel.

6. Agregar nuestro servidor remoto, es importante indicar el puerto si es que estas usando un puerto distinto al 80 (por ejemplo http://54.68.98.53:8080). El "Test Connection" debe ser satisfactorio, es importante tenerlo correcto hasta aquí.

7.  Una vez probado y grabado, se debe configurar el proyecto que sincronizará desde local hacia remoto tan solo dando click en icono  del proyecto; verá que en los archivos de configuración del proyecto se ha creado el archivo jrebel-remote.xml indicando el nombre del proyecto con el que sincronizará, es decir que si nuestro .war se llama Calculadora.war, Jrebel buscará sincronizar con la aplicación desplegada en el server con el nombre de Calculadora.

8. Bien!, aunque no lo crea hemos terminado, en teoría deberia funcionar 👍. En Eclipse damos click derecho al proyecto y luego Jrebel->Syncronize. No olvide que la primera vez debe desplegar el .war manualmente en el servidor Glassfish remoto. Si no lo hace JRebel mostrara un mensaje de error diciendo que el ID del proyecto no existe.

9. Es todo!, la consola de Glassfish en Eclipse deberia sincronizar inmediatamente, o cada vez que guarde sus cambios, verá un mensaje en la consola de JRebel que se ha conectado al server y a actualizado la aplicación.

10. Extraordinariamente despues de esto, mi vida ha cambiado 😀.

Es importante saber que probablemente no le funcione a la primera, pero revise detenidamente cual es el error, recuerde que al final de todo verá la luz!. Aun tengo varias preguntas por resolver.

¿Funciona con otros servidores? ¿Tomcat? ¿Jboss? ¿otro?.

¿Reducirá el  rendimiento de la aplicación en el servidor remoto?.

Ya lo veremos!